Lightweb 思路探讨 博客分类： Web WebworkAOP编程StrutsOO
程序员文章站
2024-03-18 21:16:28
...
Lightweb 思路探讨
《Web开发构想》帖子里面，我写了一些关于Web Framework方面的想法。
http://forum.iteye.com/viewtopic.php?t=13432
Lightweb就是这些想法的实现。目前，编码工作初步完成。具体功能方面基本按照自己的思路实现了。这里主要阐述一下lightweb的功能、用法、特性。以此来获取大家的真知灼见，以便lightweb的改进。Thanks for your discussion.
1. Lightweb的目标领域
我感觉，Struts, WebWork, SpringMVC, Tapestry, JSF 等的目标领域一般是 类似Desktop, Rich Client等交互性很强的内部应用系统（URL种类有限，菜单有限）。
Lightweb的目标领域是 大型的内容服务网站（URL种类无限可扩展，无限制的子模块层次和个数）。所以，实现和用法的侧重点都有不同。
Struts 等注重Validation, Population, Taglib, Page Component等。工作基本花在View上。
需要配置站点地图，每个URL类别都要对应一个Action Class，并且每个Action还要配置对应的Page File。Lightweb的第一要务，就是要消除站点地图的手工配置，具体做法是，利用规则匹配代替直接指定。工作基本花在Dispatcher，Controller上面。Lightweb直接支持URL美化，不需要另外的filter, 因为Lightweb主要以URL为中心工作。
2．具体用法
比如，我们有这样一组URL的Pattern。
http://site.com/en/dir/category/area/beijing
http://site.com/cn/dir/category/area/beijing
http://site.com/en/dir/category/business/car
http://site.com/cn/dir/category/business/car
http://site.com/en/dir/index/1001
http://site.com/cn/dir/index/1001
我们可以看到，这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。我们就来分析 dir/category/business/car 这一段吧。4级子模块。
Lightweb是这么定义的。除了最后一级，前面的各级子模块，都对应一个 Channnel （其实就是Dispatcher）；最后一级子模块，可以对应 Channel (Dispatcher), Controller (类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。
这里可能难以理解。Struts等，再怎么分package，一个URL就是直接对应到一个Class。而Lightweb在上述的例子中，却一步步对应了4个Class。前3个是Channel Class，最后一个可能是Channel, Controller, Action等Class。
DirChannel
----CategoryChannel
--------AreaChannel
------------BeijingChannel ( or BeijingAction, BeijingController)
--------BusinessChannel
------------CarChannel ( or CarAction, CarController)
----IndexChannel (or IndexAction, IndexController)
规则匹配可以这样简单定义：
en -> “”
cn -> “”
postfix -> “Channel”
匹配引擎找到了en, cn，都有定义，向下走，然后遇到dir，这个时候，没有找到dir的定义。
匹配引擎这个时候，就把dir -> DirChannel, 并装载DirChannel类。
DirChannel类接着向下走（注意这个时候，DirChannel自己变成了匹配引擎，它有自己的匹配规则，这里的匹配规则只有一条 postfix -> “Channel”），遇到了area，没有发现area的定义，那么就把area-> AreaChannel，并装载AreaChannel类。
AreaChannel类接着向下走（注意这个时候，AreaChannel自己变成了匹配引擎，它有自己的匹配规则，这里的匹配规则只有一条 postfix -> “Action”），遇到了beijing，没有发现beijing的定义，那么就把beijign-> BeijingAction，并装载BeijingAction类。
然后执行BeijingAction，返回结果。
可以看到，程序员可以定制任意级别的Channel。而不需要维护一个统一的庞大的站点地图。在同一个子模块内，增加一个Service，不需要改动任何配置文件。如果需要加入一级子模块，只要定义一个简单的匹配规则即可。找到了Service之后，如果URL还没有用完，那么后面的URL片断，都转化为参数（“/”分隔）。
上面说明了如何根据URL分级别找到 Service Class。下面来看如何寻找View。
Struts等，view, action都是配置在一起。而Lightweb则完全分开独立处理。
比如，http://site.com/cn/dir/category/business/car
模板引擎装载 cn/dir/category/business/car.html 这个文件。（前缀、后缀可以订制）
如果Service返回了一个View Name，比如，edit。那么，模板引擎装载 cn/dir/category/business/car/edit.html 这个文件。
如果Service返回了一个View Name，比如，../carEdit。那么，模板引擎装载 cn/dir/category/business/carEdit.html 这个文件。
《Web开发构想》帖子里面，我写了一些关于Web Framework方面的想法。
http://forum.iteye.com/viewtopic.php?t=13432
Lightweb就是这些想法的实现。目前，编码工作初步完成。具体功能方面基本按照自己的思路实现了。这里主要阐述一下lightweb的功能、用法、特性。以此来获取大家的真知灼见，以便lightweb的改进。Thanks for your discussion.
1. Lightweb的目标领域
我感觉，Struts, WebWork, SpringMVC, Tapestry, JSF 等的目标领域一般是 类似Desktop, Rich Client等交互性很强的内部应用系统（URL种类有限，菜单有限）。
Lightweb的目标领域是 大型的内容服务网站（URL种类无限可扩展，无限制的子模块层次和个数）。所以，实现和用法的侧重点都有不同。
Struts 等注重Validation, Population, Taglib, Page Component等。工作基本花在View上。
需要配置站点地图，每个URL类别都要对应一个Action Class，并且每个Action还要配置对应的Page File。Lightweb的第一要务，就是要消除站点地图的手工配置，具体做法是，利用规则匹配代替直接指定。工作基本花在Dispatcher，Controller上面。Lightweb直接支持URL美化，不需要另外的filter, 因为Lightweb主要以URL为中心工作。
2．具体用法
比如，我们有这样一组URL的Pattern。
http://site.com/en/dir/category/area/beijing
http://site.com/cn/dir/category/area/beijing
http://site.com/en/dir/category/business/car
http://site.com/cn/dir/category/business/car
http://site.com/en/dir/index/1001
http://site.com/cn/dir/index/1001
我们可以看到，这些URL是分段的。每一段代表 一级子模块。后面的段属于前面的段。我们就来分析 dir/category/business/car 这一段吧。4级子模块。
Lightweb是这么定义的。除了最后一级，前面的各级子模块，都对应一个 Channnel （其实就是Dispatcher）；最后一级子模块，可以对应 Channel (Dispatcher), Controller (类似于SpringMVC的Controller), Action(类似于WebWork的Action)等三种编程模型。
这里可能难以理解。Struts等，再怎么分package，一个URL就是直接对应到一个Class。而Lightweb在上述的例子中，却一步步对应了4个Class。前3个是Channel Class，最后一个可能是Channel, Controller, Action等Class。
DirChannel
----CategoryChannel
--------AreaChannel
------------BeijingChannel ( or BeijingAction, BeijingController)
--------BusinessChannel
------------CarChannel ( or CarAction, CarController)
----IndexChannel (or IndexAction, IndexController)
规则匹配可以这样简单定义：
en -> “”
cn -> “”
postfix -> “Channel”
匹配引擎找到了en, cn，都有定义，向下走，然后遇到dir，这个时候，没有找到dir的定义。
匹配引擎这个时候，就把dir -> DirChannel, 并装载DirChannel类。
DirChannel类接着向下走（注意这个时候，DirChannel自己变成了匹配引擎，它有自己的匹配规则，这里的匹配规则只有一条 postfix -> “Channel”），遇到了area，没有发现area的定义，那么就把area-> AreaChannel，并装载AreaChannel类。
AreaChannel类接着向下走（注意这个时候，AreaChannel自己变成了匹配引擎，它有自己的匹配规则，这里的匹配规则只有一条 postfix -> “Action”），遇到了beijing，没有发现beijing的定义，那么就把beijign-> BeijingAction，并装载BeijingAction类。
然后执行BeijingAction，返回结果。
可以看到，程序员可以定制任意级别的Channel。而不需要维护一个统一的庞大的站点地图。在同一个子模块内，增加一个Service，不需要改动任何配置文件。如果需要加入一级子模块，只要定义一个简单的匹配规则即可。找到了Service之后，如果URL还没有用完，那么后面的URL片断，都转化为参数（“/”分隔）。
上面说明了如何根据URL分级别找到 Service Class。下面来看如何寻找View。
Struts等，view, action都是配置在一起。而Lightweb则完全分开独立处理。
比如，http://site.com/cn/dir/category/business/car
模板引擎装载 cn/dir/category/business/car.html 这个文件。（前缀、后缀可以订制）
如果Service返回了一个View Name，比如，edit。那么，模板引擎装载 cn/dir/category/business/car/edit.html 这个文件。
如果Service返回了一个View Name，比如，../carEdit。那么，模板引擎装载 cn/dir/category/business/carEdit.html 这个文件。