<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>开发 on 两点之间</title><link>https://yuehei.37net.com/tag/%E5%BC%80%E5%8F%91/</link><description>Recent content in 开发 on 两点之间</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Thu, 06 May 2010 12:38:42 +0000</lastBuildDate><atom:link href="https://yuehei.37net.com/tag/%E5%BC%80%E5%8F%91/index.xml" rel="self" type="application/rss+xml"/><item><title>WebGame 开发过程与备忘（一）前端基础框架的封装</title><link>https://yuehei.37net.com/2010/05/webgame_development_1/</link><pubDate>Thu, 06 May 2010 12:38:42 +0000</pubDate><guid>https://yuehei.37net.com/2010/05/webgame_development_1/</guid><description>&lt;p&gt;这个webgame虽然还有bug，有一些功能要完善，界面也要重新更换，但基本上告一段落，我会一般修bug，一边做总结，这是这篇总结的第一章，算是一个备忘。&lt;/p&gt;
&lt;p&gt;做这个项目之前，我有2年左右的PHP开发经验，对python有一些了解，javascript一般般，但用起来倒也得心应手。之前对webgame有一些了解，自己也玩过，也debug其中一些认为做的比较好的，这样也就不算陌生。&lt;/p&gt;
&lt;p&gt;我的技术背景决定整个webgame是基于PHP+javascript来完成，为了更好的用户体验，我决定采用OPOA的形式。javascript项目有一个问题，就是连接保持，现在流行的comet方式，我都试了一遍，如果没有一个支持这一特性的web server配合的话，都不理想，最后还是使用了flash的socket，后面我会用专门一章节来讲。&lt;/p&gt;
&lt;p&gt;其次，在做的过程中也走过一些弯路，比如刚开始，我过于强调所谓的性能，而把很多计算放到客户端来做，为了保证客户端时间正确，又把服务器的时间同步过来等等，做了一些无用功。javascript虽然功能很强大，但过于依赖javascript，限于个人的水平，会导致前端不可控，错误不可重现，bug无法排查，最后会被活活急死。&lt;/p&gt;
&lt;p&gt;另一个重要的问题，就是整个后端返回的是数据还是html，我曾经debug一个知名的webgame，发现它整个后端都返回html，当时我不以为然，认为完全没有必要，所以我采用的就是返回json。现在看来其实两个都各有好处，返回html可以避免前端再进行处理（譬如非常烦人的数据组装），只要一个dom就可搞定。返回数据则可以减少数据量，加快响应速度，我现在采用的是数据+javascript模板的方式，javascript模板很少发现有网站在用，模板对于普通网站来说，可能弊大于利，但对于OPOA类的程序，好处显而易见的，配合延迟加载也可以减少一些弊端。&lt;/p&gt;
&lt;p&gt;一般应用的过程是：前端 -&amp;gt; 调用后端 -&amp;gt; 处理结束 -&amp;gt; 返回前端，这个过程webgame也有，但webgame有时候会回调前端，即：&lt;br&gt;
前端 -&amp;gt;  调用后端 -&amp;gt; 处理结束 -&amp;gt; 返回前端 -&amp;gt; 再回调前端。&lt;/p&gt;
&lt;pre lang="javascript"&gt;/*
一个例子：购买一个道具，就更新银两的显示。把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);
 }
};&lt;/pre&gt;
&lt;p&gt;随着要处理的类型的增多，status会越来越多，整个前端会很臃肿，而且会越来越不可控。如何让后端更自由的调用前端？有一些webgame返回的是html，里面内嵌javascript，这种方式并不推荐。可以采用格式化的返回数据来解决这个问题。&lt;/p&gt;
&lt;pre lang="javascript"&gt;// 前端调用
JRun.loadBack('/goods/buy', {goods_id: 1, num: 5});
// goods/buy返回数据格式
{status: 1, data: {tael: 5}, callBack: "JRole.updateTael(data.tael);"}&lt;/pre&gt;
&lt;p&gt;这样就清晰简单多了，前端只需一行代码。服务器处理完成以后，自定义callBack作为返回内容，前端会自动调用并将数据传入。只要对JRun.loadBack进行简单的封闭，让它识别callBack的内容。后端对前端的可控性会降低前端的代码量，同时也可应对复杂的交互。&lt;/p&gt;
&lt;p&gt;这样的前端设计基本上能满足我目前的应用。另外如果我能在开发早期注意到问题，完全可以在实现控制(JRun.loadBack)，模型(后端PHP)，模板(javascript渲染)的分离。&lt;/p&gt;</description></item></channel></rss>