研究了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而做的,那也就无所谓了。
不知道各位对这种生成方式有什么不同意见,期待讨论。
如果采取纯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而做的,那也就无所谓了。
不知道各位对这种生成方式有什么不同意见,期待讨论。