论坛首页 Java企业应用论坛

代码擂台,特别有请buaawhl

浏览 69607 次
该帖已经被评为精华帖
作者 正文
   发表时间:2004-07-20  
jackyz 写道

如果加入一个中间层次,我是说一个配置文件或者ognl等,总之就是尽量达到1.“封装显示逻辑”,2.无需“更改-编译-重启”,这两个目标。

如果这样的话,页面布局被封装在html中,而且仍能被wysiwyg。数据逻辑被封装在java代码中,能保持相对的稳定。显示逻辑被封装在这个新加入的中间层中,能够方便的调整。让这三个层次和谐共存彼此互不影响。

“简化我们的生活”?呵呵,这永远是我们的梦想。


这是一个好主意。我也这么想过。
用ognl定义PO 业务数据和Template DOM之间的映射关系。
fastm根据这个映射关系自动把PO 业务数据设置到VO(ValueSet DOM)。这样用户就不用自己写代码把数据设置到ValueSet DOM了。

我准备在fastm的stable版本加入:
利用reflection把bean的属性一次设置到ValueSet的方便函数。
利用reflection根据bean list一次生成一个ValueSet List的方便函数。
利用Dynamic Proxy实现“显示逻辑”AOP -- 全局格式化、全局风格统一控制。
这些都会大大减少用户的代码量。
比起脚本语言来,逻辑层次更少,语句个数更少。而且JDK1.5引入的新特性(for each)等也会进一步减少代码量。

这些加强特性对实现ognl映射也是一个很好的基础。
fastm项目本身不引入ognl映射这个特性。

但有可能创建一个fastm扩展项目fastmv中支持这些特性:
bean(ognl) --> ValueSet映射,
XML (XPath) --> Value Set 映射,
fastmv项目作为fastm和其它Web Framework的桥梁项目。
利用bean(ognl) --> ValueSet映射,普通MVC的程序可以直接移植到fastm上。
利用XML (XPath) --> Value Set 映射, XML/XSLT程序可以直接移植到fastm上。

这种方案虽然能够解决编译重启的问题,也节省了设置ValueSet的代码,
但配置文件和步骤多了(每个页面需要一个模板文件和一个映射文件),学习成本增加,结构和效率降低。
其实,我从前也很看好Tapestry,就是因为每个页面的配置太复杂,所以放弃了。因为,配置复杂的技术注定不能应用于大项目。

而且映射关系从代码转到了配置文件里,就不能重用了。
很多特性,AOP,Filter Chain, Pipeline等就不容易使用了。

内心里,我还是希望fastm能以最直接、最灵活强大的方法使用。
这样带来的结果是,更小的代码,更好的重用性,更清楚的结构,更统一的控制,更快的开发速度和运行速度。

其实,很多情况下,脚本带来的代价更大。
比如,JSP、Velocity的编译不过,或抛出一个异常,你很难定位到那段语句。对于复杂的页面逻辑,也很难调试。
而写在Java Code里面的代码,可读性,速度,可调试性,可重用性都非常好。
而且需要重启的情况也并不是很多。如果你只是需要修改静态风格,直接修改fastm模板文件,fastm自动会重新装载模板。
通常需要改动显示代码的原因都是因为业务层数据的修改,这种情况下,脚本编写的程序也需要重启。
另外,fastm的编译速度很快,编译结果很小,重启的代价很小。
0 请登录后投票
   发表时间:2004-07-20  
Xiaohanne 写道

其实,我们应该关注真正的问题本身 -- 动态生成页面内容。
Page Scripting在这方面走的太远了,太复杂了,甚至走入了歧途。
该是技术返朴归真,解决真正问题的时候了。


我们无法说为了开发效率采用成熟的框架技术是不对的;我们不能说为了开发效率使用IDE工具是不对的;我们不能因为追求的方向不同而说别的技术不好或不成熟;只是选择不同。
不过还是比较赞同你的一个观点,不要丢了最基本的技术,基础是很重要。
0 请登录后投票
   发表时间:2004-07-20  
buaawhl 写道
其实,我们应该关注真正的问题本身 -- 动态生成页面内容。
Page Scripting在这方面走的太远了,太复杂了,甚至走入了歧途。
该是技术返朴归真,解决真正问题的时候了。


这段话是我说的。不是Xiaohanne说的。
说明一下,免得Xiaohanne被冤枉。:-)

选择成熟的框架技术,和IDE工具是对的。我没有批评这个。

我批评的,是脚本技术(比如JSP)依靠“修补”自身缺陷的发展之路。
Servlet的不足,产生了JSP;JSP的不足,产生了TagLib;TagLib的不足产生了TagLib可视化插件。整个技术越来越复杂。
而IDE也必须跟着这些发展而发展,不得不支持JSP调试,TagLib可视化。
结果造成技术的学习难度提高,程序结构复杂,对某些特有工具的依赖加强。

表面的好处是:
(1)很多技术厂商以此项“修补”业务为生。商业繁荣了。
(2)提高了初学者的技术入门门槛,提高了复杂技术的“熟手”的身价。

但Web开发阵营并不是只有Java。Java的Web开发领域有可能因为技术门槛高,而丧失领地。
特别是当技术的复杂不是为了解决现实世界的问题,而是解决技术自身创造的问题的时候。
你可以认为MVC是解决了真正的问题 -- 开发架构的问题。
但你不能说TagLib解决了真正的问题。TagLib只是解决了JSP的问题。
同样,你也不能说TagLib可视化插件,解决了真正的问题,TagLib可视化插件只是解决了TagLib的问题。
(只有当TagLib成为象HTML, Flash,ActiveX等标准的Web表现格式的时候,你才可以说TagLib可视化插件解决了真正的问题。但我们知道,TagLib只是开发时候用到的。)

更深刻的影响是,甚至整个Webapp开发都会受此影响。
一个技术的发展如果太复杂,很有可能在 寿命还很长的情况下 毁灭自身。
如果Webapp的开发难度比来临的Web Service开发难度高的话,Web Service会迅速夺取Webapp的领地。
那也许是B/S Webapp一个时代,一个行业的终结。

为了避免对这个问题的争论。我说明,这只是个人看法。
我的观点的前提是 Servlet -> JSP -> TagLib 的技术越来越复杂。
(主要是我曾经调试察看过JSP + TagLib产生的Servlet代码,对其混乱冗长的结果惊诧不已)

当然,也许很多人认为这样发展的技术越来越简单,越来越好用。

如果是这样认为,那我承认我前面的观点都是错误的。
毕竟,这只是个人对学习难度和使用难度的观点不同,无伤大碍。和解决真正的问题,没有直接关系。
所以对持“脚本技术越来越简单好用”观点的人来说,我也赞同这样的看法,
并承认我的看法是片面的。
0 请登录后投票
   发表时间:2004-07-20  
goncha 写道
看了大家对fastm, 以及显示控制代码的归属问题的讨论. 感觉fastm应该属于页面显示与业务操作的中间地带, 一个处理页面显示状态和业务操作状态交互的地带. 这似乎也就是MVC中C应该做的一部分工作. 将这份工作彻底地从JSP中独立出来应该就是fastm的目标了;-)  目前还没有什么实践的结果可以证实这样的确可以减少代码量, 增加重用性等. 但也不是不可取. 我还是会关注的.

一个建议: 把模板变量与EL或ognl相结合, 这样可以比较好的利用现有资源.


是的。这也是很多人的建议。你是更早提出来的。多谢。很值得考虑。
0 请登录后投票
   发表时间:2004-07-20  
给buaawhl最后的建议:
好好去研读一下freemarker的文档,特别是第2、3章,你会发现fastm要做的事情人都已经做好了。而且方式方法要比fastm简洁明快,功能也更强大,至于用不用if/else逻辑,随使用者的选择,都可以。
建议你申请加入那个开发团队。
还有一个小建议,下次新的想法付诸实施之前,最好化2星期的时间写一个该方面现状的综述,以免闭门造车。
0 请登录后投票
   发表时间:2004-07-21  
charon 写道
给buaawhl最后的建议:
好好去研读一下freemarker的文档,特别是第2、3章,你会发现fastm要做的事情人都已经做好了。而且方式方法要比fastm简洁明快,功能也更强大,至于用不用if/else逻辑,随使用者的选择,都可以。
建议你申请加入那个开发团队。
还有一个小建议,下次新的想法付诸实施之前,最好化2星期的时间写一个该方面现状的综述,以免闭门造车。


------
那么请给出一个例子,使用freemarker,不用if/else,
为Table的奇数行和偶数行,赋不同的颜色。
另外,正数用蓝色,负数用红色。
------

这让我怎么说呢?
你如果一开始就拒绝真正理解fastm的思路,总是从Velocity, FreeMarker的思路来理解问题。
当然看到似是而非的 概念提法 就很快的下结论了。

我以前就看过就看过freemarker的文档2-3章。
freemarker是velocity的加强版。和fastm毫无相似之处。
另外,我在blog里面写了一个该方面现状的综述。大概是2年经验的总结。

freemarker支持Data Model Tree。用类似于XPath,ognl等语言(xxx.xxx.xxx),来定位 对象数据层次中的某个数据,然后把它填到模板中的某个变量当中去。和模板本身的结构毫无关系。

fastm现在还不支持Data Model Tree。

fastm只支持模板结构树。和Data Model毫无关系。
fastm只有Template DOM,和ValueSet DOM。
而ValueSet DOM是用来对应Template DOM的。完全是对应文档结构的。

你可以试着用freemarker做这件事。
只有两个文件,page1和page2。不能分出新文件。
Page1里面有一个Table,Page2里面有一个List。
你用freemarker把Page1的Table摘出来,替换到Page2的位置。
你如果能用freemarker做到这一点。那么你说的,完全正确。

fastm能够轻松地做到这一点。
0 请登录后投票
   发表时间:2004-07-21  
你先做,我再做.
我敢确信你根本就没有明白freemarker能干什么。可以那么说,fastm能做的,不管轻松不轻松,freemarker也能以类似的轻松方式实现。
不信你就做个东西出来。
0 请登录后投票
   发表时间:2004-07-21  
至于那个奇数行和偶数行,不就是那个函数吗?如果我也用庄表为那种0,1,2,3方式,也使用那个tableadd函数,在velocity中就不需要用if/else
更何况freemarker了。
我前面好像说过,如果允许使用函数,那么实际上就可以实现if/else。最多把这个逻辑封装到函数里去。问题是velocity,freemarker等成熟的模板技术都支持函数,在这里fastm并没有优势。
0 请登录后投票
   发表时间:2004-07-21  
charon 写道
你先做,我再做.
我敢确信你根本就没有明白freemarker能干什么。可以那么说,fastm能做的,不管轻松不轻松,freemarker也能以类似的轻松方式实现。
不信你就做个东西出来。


这是一个fastm的自由组装页面的例子。需要JDK1.4.
源HMTL文件有两个:
Page1.html  -- 包含一个Table
Page2.html  -- 包含一个List.

生成结果 HTML文件有四个:
table1.page1.html  --  table 在 page1里
list2.page2.html  --  list 在 page2里
table1.page2.html  --  table 在 page2里
list1.page1.html  --  list 在 page1里

源代码说明:
src目录下是fastm的源代码。不用看。
test.src包括了所有这个例子相关的代码。
fastmtest包就是fastm组装页面的所有代码。
testdata包是一个可以独立使用的包。只是用来制造假数据的。
你把testdata包直接放到你的工程中当作数据源。

数据源的数据结构说明:
有几个Office, 每个Office里面有一些Person。
当Person的个数少于4个。那么男的爱好运动,女的爱好香水。
当Person的个数大于等于4个。那么男的女的都爱好Party。

请用freemarker实现这个例子。
注意,就用两份HTML文件,不要另外分出文件。

大家也都来试一下,用你们最擅长的模板技术。实现这个例子。
0 请登录后投票
   发表时间:2004-07-27  
hehe,这里还有一份?
关于这个问题,请参见
http://forum.iteye.com/viewtopic.php?t=6292
这个强大的超级无敌大变换违反了所见即所得的常识,hehe.
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics