这个webgame虽然还有bug，有一些功能要完善，界面也要重新更换，但基本上告一段落，我会一般修bug，一边做总结，这是这篇总结的第一章，算是一个备忘。
做这个项目之前，我有2年左右的PHP开发经验，对python有一些了解，javascript一般般，但用起来倒也得心应手。之前对webgame有一些了解，自己也玩过，也debug其中一些认为做的比较好的，这样也就不算陌生。
我的技术背景决定整个webgame是基于PHP+javascript来完成，为了更好的用户体验，我决定采用OPOA的形式。javascript项目有一个问题，就是连接保持，现在流行的comet方式，我都试了一遍，如果没有一个支持这一特性的web server配合的话，都不理想，最后还是使用了flash的socket，后面我会用专门一章节来讲。
其次，在做的过程中也走过一些弯路，比如刚开始，我过于强调所谓的性能，而把很多计算放到客户端来做，为了保证客户端时间正确，又把服务器的时间同步过来等等，做了一些无用功。javascript虽然功能很强大，但过于依赖javascript，限于个人的水平，会导致前端不可控，错误不可重现，bug无法排查，最后会被活活急死。
另一个重要的问题，就是整个后端返回的是数据还是html，我曾经debug一个知名的webgame，发现它整个后端都返回html，当时我不以为然，认为完全没有必要，所以我采用的就是返回json。现在看来其实两个都各有好处，返回html可以避免前端再进行处理（譬如非常烦人的数据组装），只要一个dom就可搞定。返回数据则可以减少数据量，加快响应速度，我现在采用的是数据+javascript模板的方式，javascript模板很少发现有网站在用，模板对于普通网站来说，可能弊大于利，但对于OPOA类的程序，好处显而易见的，配合延迟加载也可以减少一些弊端。
一般应用的过程是：前端 -> 调用后端 -> 处理结束 -> 返回前端，这个过程webgame也有，但webgame有时候会回调前端，即：
前端 -> 调用后端 -> 处理结束 -> 返回前端 -> 再回调前端。
/*
一个例子：购买一个道具，就更新银两的显示。把JRun.loadBack看成是一个ajax的封装。
一般情况下代码会像下面这样写，但这样有一个弊端，不止买道具，其它很多地方(比如卖)也可能要更新银两显示，
难道每一次更新都要这样写吗？
*/
JRun.loadBack('/goods/buy', {goods_id: 1, num: 5}, function(data) {
var status = data.status;
if (status == 1) {
$('#role_tael').html(data.tael);
}
});
/*
下面的代码换了一种写法，所有更新银两的显示都调用了JRole.updateTael。
但是又有一个新的问题，买道具不一定非要银两，有可能是声望，购买成功以后也更新声望的显示，
这时候就需要扩展status，来告诉前端如何处理。
*/
JRun.loadBack('/goods/buy', {goods_id: 1, num: 5}, function(data) {
var status = data.status;
if (status == 1) {
JRole.updateTael(data.tael);
} else if (status == 2) {
JRole.updateRepute(data.repute);
}
});
var JRole = {
updateTael: function(tael) {
$('#role_tael').html(tael);
},
updateRepute: function(repute) {
$('#role_repute').html(repute);
}
};
随着要处理的类型的增多，status会越来越多，整个前端会很臃肿，而且会越来越不可控。如何让后端更自由的调用前端？有一些webgame返回的是html，里面内嵌javascript，这种方式并不推荐。可以采用格式化的返回数据来解决这个问题。
// 前端调用
JRun.loadBack('/goods/buy', {goods_id: 1, num: 5});
// goods/buy返回数据格式
{status: 1, data: {tael: 5}, callBack: "JRole.updateTael(data.tael);"}
这样就清晰简单多了，前端只需一行代码。服务器处理完成以后，自定义callBack作为返回内容，前端会自动调用并将数据传入。只要对JRun.loadBack进行简单的封闭，让它识别callBack的内容。后端对前端的可控性会降低前端的代码量，同时也可应对复杂的交互。
这样的前端设计基本上能满足我目前的应用。另外如果我能在开发早期注意到问题，完全可以在实现控制(JRun.loadBack)，模型(后端PHP)，模板(javascript渲染)的分离。
