关于服务端生成js的构思

   研究了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而做的，那也就无所谓了。

不知道各位对这种生成方式有什么不同意见，期待讨论。

你好像把方向搞反了。
为了减轻服务器的负载才选择了rich client技术，
你却要用服务器技术生成客户端代码。
是在匪夷所思

和大量的html代码相比，js代码可谓少之又少了。当然，如果你想采取Ajax方式，服务端的负担是没有办法减轻的。就算用rich client也是不能减少通信次数的，只能增加客户体验而已。

楼主的想法跟我不谋而合，想问一下remove相应的删除js脚本 ，是指删除以前返回的那些js脚本吗？