[原创]OpenSocial开发模式 TDM

上周参加了 google hackthon. 才了解到这个opensocial战略.我曾经开发过国内各大SNS APP 都是基于的F8标准.所以 第一反应是,OPS(opensocial)和F8 (facebook的开放平台,目前很多SNS公司都采用)各自的优势和特点是什么.

这里很明显的区别是它们提供容器环境的方式不同.OPS是通过Javascript API,而F8是通过一个HTTP请求一个固定的URL.

应用程序展示

我的开发项目是一个igoogle的gadget.

有兴趣的朋友可以添加  http://hosting.gmodules.com/ig/gadgets/file/112371510181608062554/easywrite.xml

或者在blog下方的easywrite的widget进行测试.

Opensocial doc 中有这样一句话: All OpenSocial applications are gadgets. 所以Opensocial App和gadget的开发是完全一样的----- 用固定格式的XML包装.然后把相应的前端代码装进去.

开发框架Django/Python,服务器是Google Appengine, 所以我的开发模式是基于MVC而拓展的.

我先来展示我的应用:EasyWrite.我用它来嵌入到IGOOGLE或者BLOG中. 这样当发现有好的内容时,就可以及时在当中记录,然后发送到自己的E-mail中作为收藏.

OPS首先要定义一个XML文件.它有固定的格式.然后把前端代码嵌入到其中.
我把前端代码分成了2部分------A:html. B:Javascript.

A部分代码就是一个id="show"的div标签.

B部分代码如下:

function mail() {
var url     = "http://testbyfree.appspot.com/gadget/mail/";
var action  = "POST";
var param   = {};
param['addr']    = $('#addr').attr("value");
param['content'] = $('#content').attr("value");
request(url,param,action);
}

function response(data) {
$("#show").empty();
if (data.text.length>=5) { document.getElementById('show').innerHTML = data.text; }
else { request("http://testbyfree.appspot.com/gadget/mail/"); }
}                                                                 

function request(url,cgidata,action) {
var params = {};
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT;
params[gadgets.io.RequestParameters.POST_DATA]    = gadgets.io.encodeValues(cgidata);
params[gadgets.io.RequestParameters.METHOD]       = gadgets.io.MethodType.GET;
if (action == 'POST') { params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST; }
gadgets.io.makeRequest(url, response, params);
}

var initurl = "http://testbyfree.appspot.com/gadget/mail/";
request(initurl);

这里我简单介绍js逻辑---

用户在提交后触发mail(),然后通过request()向APP SERVER发出请求,最后response()接到响应并输出到show的div中.

而UI的html代码(点击此处查看,GOOGLE BLOG不会转义html,所以我没列出来) 并没有写在XML中,而是放在服务器端.其实就是3个input button textarea标签.

App服务器端的python代码

# running as Django App on Google App Enging
def mail_page(request):
""" the BLL handle for  Http://testbyfree.appspot.com/gadget/mail/ """
if  request.POST.has_key('content'):
# this Mail API supported by GAE.
    from google.appengine.api import mail
    content,addr = request.POST['content'], request.POST['addr']
    # the sender master be the admin of GAE APP.
    message      = mail.EmailMessage(
             sender="freefis@gmail.com",
             subject="deliver from easywrite"
             )
    message.to , message.body  = addr , content
    message.send()
    return render_to_response('debug.html',{'info':"ok!","mail":"mail"})
else:
    return render_to_response("mail.html")

设计模式 (Two District Mode):

以上就是这次开发的全部代码. 对于刚接触OPS的开发者来说,更关心的是javascript部分和XML部分.所以我针对这个问题,最后归纳出了这样一个开发模式：

虚线代表应答，实现代表请求。流程图有2种方式
显示区 -> JS逻辑 -> API 服务器 -> JS逻辑 -> 显示区
显示区 -> JS逻辑 -> APP服务器 -> JS逻辑 -> 显示区

橙色部分 代表XML文件包含的内容.
蓝色部分 代表服务器端.
绿色部分 代表API服务器.

我来解释一下我的设计思想:

XML文件的代码部分我分成了2个代码区:javascript区和html区. 前者包含了这个APP程序的所有javascript代码.后者就是一个简单的div标签 id="show".

一.html区.
1.服务器端显示层的HTML代码的BOBY部分可以完全原封不动的被response到div中.所以相关的设计者可以完全专注在现实层中的UI开发,不必考虑在XML中要如何设计.
2.javascript区从api-server中取得的数据,可以完全在本区中组织成相应的HTML然后返回到div中.
这样1和2的HTML设计就各自独立.不用考虑相互之间的影响.

二.javascript区

1.OPS的主要问题是对javascript的依赖,这么做可以不至于使相关代码在前端开发中过于混乱.更为关键的是集中javascript代码,使得不同代码之间的耦合松散.
2.统一了同APP服务器和API服务器的通信.明显区分了代码的功能性部分和非功能性部分.

这样一个模式的设计和F8应用程序设计的区别仅仅在于,当各开发者在后者的相关代码只需要2步:

1.把JS分离到XML文件上,2.修改相应API接口(这步对于任何开发模式都无法避免) 就可以迁移到OPS上.

这样可以旧代码迁移的成本, 而对于新的代码,可以显得思路更加清晰,分工度明细.

这就是这个相关设计模式的雏形.希望有很多朋友能够交流自己的想法.共同改进 : )