研究了 ext 很久了，一直想为 ext 直接封装一个服务端组件。考虑到 ext 组件的构建都是需要使用 js 来完成，那么服务端生成的代码也就是 js 而不是 html。
      如果采取纯 Ajax 的方式，类似于 Echo2的构造，不过这样对于 Session 可能是一个负担，同时可能会造成服务端的拥堵。不过使用纯 Ajax 有个好处，就是js只需要装载一次就行了。而如果使用各个不同的页面方式，则需要多次装载 ext 的 js 文件，这对于网络也是一个压力。
      不过创建的初衷，此框架主要还是使用于内部网，这样对于性能方面的担心可以略过了。
      设计流程如下：
      类似于 Jsf 的请求流程,提供 Lifecycle，基本上也就五个生命周期，apply request,process validators,update model,invokeAction,render ajax。
      先不考虑其他的生命周期，先来处理 render ajax 部分。基本构思还是以 render xml 为主，主要的格式如下：
    
<message xmlns="http://www.esoft.org/servermessage">
  <lib>
    <js url="widgets/ext-component"/>
  </lib>
  <script>Ext.QuickTips.init();</script>
  <content cid="W9"><div id="W39"/></content>
  <remove>Ext.get('W29').remove();</remove>
</message>
      lib 中主要用来装载 ext 的各个组件 js,这样不需要一次装载。
      script，主要的执行 js 脚本
      content 用于创建相应的 html
      remove 相应的删除 js 脚本

      为什么需要增加 remove 而不是把所有的脚本都放在 script 中。这是由于整个处理都在一个页面中，为了能按照顺序执行相应的脚本，remove 的脚本需要优先执行，当两个组件不停的切换的时候。

      client  对于脚本的解析流程如下：

      首先分批装载 js url，当所有的 js 装载完成后，执行 remove 脚本，遍历 content,增加相应的 html node，执行 script 脚本。

      对于页面的生成，基本上没有什么问题。
      只是如果采用这种方式，可能目前来说只能依赖于 ext 这个框架，对于服务端的灵活性也就大打折扣，不过既然是为了ext 而做的，那也就无所谓了。