buaawhl

"我理想中的Web开发架构是这样的：
开发速度快，运行速度快，结构清晰优雅。
具体到每一层。
Web框架层主要追求 开发速度快。
O/R层主要追求 运行速度快。
页面资源层和页面模板层主要追求 结构清晰优雅"
楼主所言正是,关注中

刚认真的看了这篇文章，有好几个地方还是不是很明白，有没有实际的类拟jpetstore的例子让我跑一下，

说得的确很多...

后面有点广告...不过无妨。

有些地方虽然有不同意见，但内容淹没了，好象无处着笔...那就静看楼主怎么玩你的框架了。

这一段时间有空，所以在好好查看JAVAEYES里面的过去的文章，楼主说的真的太精典啦！！先谢啦

如果用SOA服务了
那么简化代码就不是主要工作了
而扩大了代码共享
达到减少代码量的作用

可以啊。
你上面说的，应该都是未来的趋势。
我也想做到这一点。我后来开发了一个domplus，就有这个打算。

不才有个想法：
现有的模板技术如jsp,servlet,标签......都是一种折中方案

1。页面的东西不是由写出来的
而是由一个机器生成的string串

2。作一个动态库放在网上
由程序员上传到网上
形成一个soa服务
反正返回的是string 串
可以用ajax在客户端来作

3。数据方面用[]数组多维数组成

真幽默！

这位兄弟，太让我感动了。
我会一直致力于“运行速度最快、开发速度最快、结构最干净优雅”这个目标，并在上面开发更多的应用。哪怕是跨过千山万水，多种语言，也在所不辞。

愿搂主早日做出自己的框架，我们一直会关注你，支持你。

ajax, web2 和 server side template 有些矛盾。

我的想法主要是
1. no stateful webapp, but stateless web.
不是把 B/S 当作 C/S, 当作desktop, 而是把B/S 当作B/S.

2. REST Web service style, URL centric.

3. migratable mobile script

这些想法不可能是完美的。只是试图向另一个方向走。

当年，Web出现的时候，只有动态页面，大家开发起来轻松愉快。
于是，Web用来开发webapp应用程序，为了适应开发人员的桌面开发的思路，加快开发速度，引入了state control 来克服stateless HTTP.
这其实已经偏离了HTTP的方向。或者说，违背了HTTP的初衷。或者说，是对HTTP的一种修正。把HTTP stateless作为一种弱点来规避。

我试图回到 HTTP 本来的方向上。继续发挥 HTTP Get (url) 的强大优势。HTTP Stateless 的强大优势。（HTTP Post 是 HTTP 的弱点）

你这个想法要解决的问题太多了。
怕解决的都不是最完美，那如果我们要应用，没有合适的切入点了。

例如：你既要满足传统request,response的开发，又要融入ajax的思想。（个人觉得是矛盾的）

还要符合web2标准。现在模板语言不是很符合web2.

不錯，不過看得累了點

精彩！

感谢buaawhl 带来[Java Web开发构想]这篇精彩的文章，给了我思想上一些启示和学习方向。 技术是永远止境的，条条大路通罗马! 我们要在最短的时间内在java Web大千世界中选择最合适自已的平台! 没有最好的，只有最合适的! ^_^

多谢liusong1111的深入分析探讨。
前面的 Ajax, Form Post等意见都很好，是有益的补充。我现在的框架中，主要针对 Stateless Link。

关于Lightor 的那段特殊用法里面，为什么不用Reflection.
因为那段特殊用法是用来处理 Long Transaction的。也许有几十万条记录批量处理。那节省的时间就很多了。



对. 可以这么说。:-)
也可以说，Channel 是 Dispatcher, Controller, Action 是 Service。



Lightweb 主要暴露Service，不暴露Entity. :-)
暴露的最低级别就是WebWork的Action 级别了。
CRUD还是需要自己包装。

前几天开始做某个项目，看到流畅的原型为了编码的需要被改的面目全非，俺真个心疼啊。
于是反思保护web原型的问题，看到buaawhl老大 的讲解，不胜喜悦，俺想要的老大差不多都做好了，还外送了不少好东东。
下面是俺的观感和原先的一些想法，夹杂着独门术语，卖弄一二。
（不知何时得闲开始学习一下fastm呢）



关于作者对于脚本与配置的论述十分认同，附一点对xml的漏述：xml可以反向解析，脚本就十分难了。比如我想做个可视化的配置界面，如果配置信息是脚本实现的，大概只能单向生成配置脚本了（用velocity一类很容易）。


3．页面资源

映射Css、JavaScript文件类型，对于它们的链接，参考zope，即：相对路径下找不到，就到上一级目录，直至context根。实现页面外部资源查找的面向对象方式。
应用场景：
在context根目录放置全局`默认`css，对要定制的子web模块，在相应目录建立同名文件即可实现css定制。

这个是不是我前面的说的？Zope Object Publishing没看过




目标：简单的方案应对简单的需求，完善的方案应对复杂的需求。即遇简则简，遇繁则繁。
方式：方案的`默认`实现应对简单，开放的架构应对复杂。
重在`三态`中`默认`态的实现。

4．页面模板层


严重同意！

包括三个内容：
1. 模板（页面模板、UI组件装饰器）：sitemesh起作用的地方。
2. UI组件（通用组件、数据敏感组件）：有人称之为macro的东东，服务器端与客户端统一模板，可以注册服务器端事件。

UI组件的服务器端事件激活时，引起一次客户端请求（当然也可以是ajax型请求）。对于UI组件的服务器端初始化事件，考虑无通信消耗的优化。

3. 控制逻辑（分页、循环项、分支）

欣赏的实现方式：
页面`元数据`：页面标签的自定义属性（类tapestry、zope page template），标记数据源名、UI类别，可以包含简单的逻辑代码（Ognl的应用）。

(X)HTML DOM在服务器端解析及改动带来的便利：

not so bad。除却服务器端DOM的执行效率问题，其可带来的价值是可观的（这方面的常见应用还是太少了）。
一般思路是用个FilterServlet解析返回的原始(X)HTML，对可见的DOM注入页面模板、UI组件（及其模板、数据），执行针对DOM的控制逻辑。
可能的应用场景：
1. 避免二次提交：向form标签内自动注入hidden域存放令牌
2. url修饰：有些状态往往需要在用户操作流的连续页面内传递（`page flow`），如公文的ID号，放在session中既占资源，又不符合需要（假想用户登录一次，打开两个浏览器窗口处理不同的公文）
3. model属性值自动注入页面



我们是不是可以称之为页面生成上的AOP和IoC 
如果逻辑比较复杂，可以用服务器端脚本作为datamodel和DOM的粘合剂，保持对复杂的适应。例如：覆写默认行为，复杂表现逻辑。
同样，`默认`是如果存在脚本，则用脚本粘合，否则是默认粘合。
默认行为的制定参考css查找规则。

以上方案试图力保原始(x)html的纯洁性，保证`原型友好`，理想状态是这样的：
在没有应用服务器的情况下，原型是最新的可以展示的版本，对用户和美工都是友好的。
放在应用服务器下，它就是一个跑得很好的完整应用。

达到这个理想虽然很难，但我们可以逼近。
原型页面和普通的应用一点大的不同是link和form action的指向，往往改成了*.jsp,*.do等对原型不友好的形象。是不是可以保留原型中的原始htm链接，用个Servlet映射*.htm，接管客户端请求，并以默认规则确认action名称，构建实例，并自动根据request参数初始化属性（差不多就是XWork）。

这里，`默认`要forward到的view就是用户请求的html。

表单验证也可以用`页面元数据`表达，最终可被server-side DOM(服务器端脚本验证器)转译处理和client-side DOM parser(javascript验证库)处理。如果server-side验证不通过，`默认`forward到原页面。



暗合，呵呵~
后面还有：




十分同意！
称之为`提交form到某html UI`，很爽的样子。

7．O/R


超级不赖的lightweight o/r切入，学习ing！
用反射就行了，性能不会太大吧~（或者两种实现，开发时和布署时两套方案？反正开发时不爽就是不叫俺爽~）

Pager





是不是说：Channel是模块级(module)，Controller是实体级(action instance)，Action是方法级(action method)？

对于WW2的Action，每种请求对应一个Action（的execute方法）。
是不是有面向Entity（pojo）的，像ruby on rails，把Entity类的某些方法暴露出来，作为http请求的目标。（暴露的粒度，模板的适用对象）
是不是也有Entity类的`默认`模板（比如实例属性、对应方法的参数自动转成html form表单或link参数，一个Entity类提供CRUD四个模板页面），可以针对某Entity类定制模板，并提供override模板某部份的能力？

整个就是一片综述，但是内容太多了反而淹没了中心

“模板中能够调用函数，就可以实现计算逻辑的剥离”。
对。具体的计算可以放到函数中。如果主干逻辑部分还是用taglib表示在template里面的话。可能是下面的这种情况。



如果把这个主干部分也移到代码里面，那里面的 HTML 部分，也要跟着进入代码，无法剥离。比如，<a href="jumpto..." title="Next page">...</a> 这些就要在Code里面输出。
所以，fastm的完全“推”模式的优势就体现在 HTML和Code可以完全剥离。其实，JS/Jivan/XMLC等 DOM操作都无法做到这一点，Code至少要知道自己操作的是DOM，甚至是HTML DOM。



这种顺序执行，确实是“拉”模式的优势。
“拉”模式类似于SAX。fastm模式类似于DOM。
SAX时间、空间效率高，但是，代码要散布在各个回调函数中。TagLib的编写也是这种回调的概念。Tapestry Page Component的编写也是。
DOM时间、空间占用大，但编程结构就比较自由，XPath等高级功能也可以使用。
fastm的DOM分为两个部分，Template DOM is Read Only, shared among all theread. Object DOM需要程序员用代码组织。
Object DOM里面放的都是动态数据部分，一般来说，数据量不会很大。当然，如果是CSDN的那种不换页的长篇页面的情况，直接把ResultSet, Iterator等提供给fastm，也可以。这样就不用在内存中直接构造。
ResultSet, Iterator每走一步，计算一步，提供结果，输出。这也能够达到延迟计算的效果。只是要程序员自己提供Iterator，而不象拉模式那样自由。



是的。正如在操作DOM的时候，事先至少要知道这个DOM都有哪些Node。code确实要知道template struture. 但这只是单方面的知道。这里Code只是把template当作资源，如同操作一个数据库、文档结构。

如果是 scripted template, like jsp, velocity, java code也至少要知道template要些什么东西，以便把一些东西放到request等地方。而且template 里面的code，也至少要知道java code传过来的是什么东西。这是一种 双向知道。
这里java code 和 template code之间类似于一种函数调用的关系。只是这个关系不那么直接明显，中间是靠框架粘结起来的。
正如函数调用的时候，调用方需要知道 函数需要什么参数，函数要知道自己需要的参数是什么。



这个map其实相当于构造的view model。
fastm不象tapestry, wicket那样硬性规定了view model like table, list, button, link, label.
但由于fastm不支持template中的逻辑，所有需要显示的view 变量都要在java code里面构造。
如果需要显示的东西，不是现有的POJO，那么只能另外构造，Map就是一个比较方便的选择。
这种地方的处理，确实比较蹩脚。但毕竟比硬性规定DOM, 硬性规定view model like table, list, button, link, label 的情况，好多了。用户的选择余地很大。Map, List，数祖，自定义Java Object，灵活方便。
这个也是衡量得失，为了“剥离code和html”而付出的代价。
这种情况下，我非常羡慕 Ruby, Python, JavaScript等动态解释脚本语言，可以直接添加属性，而不需要另外构造Map等view model。



中间这个度，确实很难掌握。
fastm为了最大限度地支持“所见即所得”，不影响HTML正常显示。不得不放弃所有逻辑。这个也是衡量得失。而且，如果fastm在template中支持逻辑，函数调用，实现难度马上就上了一个台阶。
由于fastm的控制逻辑全部在java code里面，没有script。这就意味着，fastm的功能扩展，不用扩展script语法格式，直接扩展Java API就可以了。
我现在主要在这个方面下功夫。比如，提供了类似于OGNL的支持，为了大数据量情况下节省空间，提供了Iterator，ResultSet的支持，等。
你说的那些功能，都可以在fastm的外围API做。fastm也提供了类似于SAX Callback的机制，是一个IValueInterceptor, 匹配引擎每处理一个fastm template DOM Node的时候，都会调用这个IValueInterceptor。
特殊的需求，可以在这个IValueInterceptor里面实现。
比如，可以专门定义一个 FuncInterceptor处理{call.a.func(c, d)} 这样的东西。可以专门定义一个 FormatInterceptor处理{a.date@yyyy-mm-dd} 这样的格式处理。
其实，fastm的这种格式处理可以非常强大，可以根据 对象属性的名字、类型、值等，进行各种处理。
比如，beginDay, endDay, 就显示 yyyy-mm-dd; beginDay, endDay, 就显示 yyyy-mm; beginYear, endYear就显示 yyyy; beginTime, endTime 就显示 yyyy-mm-dd hh:mi:ss. 等。

这个我称为显示逻辑AOP。



fastm支持对象图。类似于OGNL。POJO可以直接在template中引用。

pager可以提供prev以及not_current变量的计算函数即可，极端一些甚至可以如fastm一样返回link列表。我想只要在模板中能够调用函数，就可以实现计算逻辑的剥离，只是将fastm中的变量存取变成了函数调用而已。例如 prev ==> pager.getPrev()。fastm提倡将复杂逻辑抽象到代码中，其实我是赞同的，一些复杂的页面组件的实现例如布局逻辑，我们也是封装在布局对象中的。
只不过到底是预先把所有变量都计算出来，还是将计算时刻延迟到执行的时刻(采用lazy evaluation其实是function programming最擅长的)。如果预先计算，我们需要在java代码中明确假定布局的结构，然后在模板文件中按照java代码中的结构把页面展现出来。预先计算的时候，我们不可避免的要编写glue代码，例如把所有变量放到一个map中。此时，如果我们希望脱离页面结构独立使用某些变量，例如当前页数，就比较麻烦。当然我们可以为Paginator编写很多独立的函数,例如getCurrentPage()等，但是将所有变量放入Map这一步是只为当前页面布局存在的，它的意义范围显然与getCurrentPage()等函数不同。
其实拉模式与IoC的思想也是相同的，到底是编写一个综合配置函数，传入一个Map，将所有属性都设置一遍，还是只编写getter和setter，具体调用由调用者驱动。
我想fastm强调页面中没有复杂逻辑是正确的方向，但是也不必绝对排斥在页面中调用函数。我不太清楚fastm是否支持对象图, 即 aObject.bProperty.cValue 之类的调用语法。支持对象图或者对象函数调用的一个额外好处是可以需要命名的变量数，即减少需要创造的概念数，在对象数比较多的复杂情况下还是有用的。