JSP is no longer required.

历经一个半月的努力，框架终于在2007年12月上旬完成了改造，目前框架已支持热部署。

 

框架采用XSLT格式化XML为XHTML的方式来展现所有内容，内容管理采用入口参数来控制，浏览器请求的地址会被引擎转换到相应入口，引擎根据入口定义调用方法获得特定格式的XML内容，然后根据入口定义找到对应的XSTL文件，使用XSLT文件将XML内容格式化成XHTML。

 

这样做的目的就是要把管理、逻辑、内容、风格分离，使得任务可分配给擅长某方面技术的人员，他们不再需要熟悉其它方面，使得开发工作可同步进行。

 

内容根据系统设计时定义的数据库或XML来制作，入门了的Java工程师即可胜任此工作。

 

逻辑根据入口定义从内容中获取数据并生成特定格式的XML内容，只要有一定基础的Java工程师即可胜任此工作。

 

风格根据UI设计时定义的界面来制作，需要具有XSL、JavaScript、CSS、HTML技术特点的Web工程师来完成这部分工作，明显的，这里多了一个XSL。

 

管理根据入口定义配置逻辑与风格的关联，这部分需要有相当功底的架构工程师来完成。

 

此外，UI工程师和测试工程师肯定也少不了。

 

开发流程可以这样控制：

 

UI工程师制作格式为HTML的效果页面，并将制作好的文件提交到CVS；

 

架构工程师根据效果页面定义格式为XSD的页面数据，并将制作好的文件提交到CVS；

 

Web工程师根据效果页面和页面数据制作格式为XSL的数据格式，以及相应的格式为JS的JavaScript脚本和格式为CSS样式，经过测试将制作好的文件提交到CVS；

 

Java工程师根据页面数据制作生成数据的业务逻辑和数据存储，经过测试将制作好的文件提交到CVS；

 

架构工程师定义功能目录入口，把Web工程师和Java工程师制作的文件整合起来；

 

架构工程师把完整的应用软件打包并发布到网络中；

 

测试工程师对应用软件进行功能测试，并填写测试报告；

 

修改BUG后重新发布应用软件；

 

如此将不再需要再嵌入Java代码，JSP在HTML中嵌入代码，XSP在XML中嵌入代码，这样做意味着样式的修改不会影响到逻辑和内容，逻辑或内容的修改不会影响到风格，前提是只要定义XML内容的XSD不改变，因此，系统的开发效率、稳定性将得到很大提升。

 

此外，使用入口匹配XSLT和XML的方法使得不同的使用者可以选择不同的风格，体验变得更有趣。

 

框架新近开始支持热部署，包括框架系统配置部分以及所有发布到框架中的应用软件。同时，框架还支持数据同步，以适应集群服务器部署。

评论

24 楼 myreligion 2008-01-10  

xslt具难用无比，比jsp效率低多了。而且浏览器解析xslt也靠不住，firefox都不支持xslt里面out出来的html标签！

23 楼 mathgl 2008-01-10  

曾经看到过一个PHP用的 模板 作者据称是cross-language
其实也是用 XML+XSLT 这种咚咚。当年看了一下觉得有些复杂
故此一直没用.
不知道现在流行没

22 楼 triu 2008-01-10  

ray_linn 写道

呵呵，写一份XSL需要美工和程序员一起协同是人员分工？。。。俺就不去细查XSL里头是不是会混合商业逻辑的事呢。

美工和程序员不需要协同，他们都通过架构工程师实现协同。

XSL里不需要商业逻辑，它的工作很简单，就是把XML内容格式化成HTML（或其它格式）就可以。

21 楼 ray_linn 2008-01-10  

呵呵，写一份XSL需要美工和程序员一起协同是人员分工？。。。俺就不去细查XSL里头是不是会混合商业逻辑的事呢。

20 楼 triu 2008-01-10  

标记应该由什么角色来使用？混合在一起角色如何区分？

生成HTML是框架的一个输出格式，其他还包括XML、WML、JPEN、PNG、PDF、SVG等。

19 楼 triu 2008-01-10  

ray_linn 写道

triu 写道

如你所说，XSLT的开发效率体现在两个方面：1。掌握的人不多；2。缺乏相应的工具。

针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。

俺只需要一个美工，你却需要两个人，这要花钱吧？ 培训也要花钱吧？IE和FF对XLST支持不同要考虑吧？

从工程的角度来考虑，人员分工才是管理追求的目标，专业才能得以发挥，
从长远看，企业发展也需要这样的管理方式，哪个花钱多，就是智者见智了。

IE和FF的支持不同在那里都会碰到，这个。。。。。。

18 楼 daquan198163 2008-01-10  

最重要的 10 几个J2EE 最佳实践第9条：将 JSP 作为表示层的首选。
只有在需要多种表示输出类型，并且输出类型被一个单一的控制器及后端支持时才使用 XML/XSLT。
我们常听到一些争论说，为什么您选择 XML/XSLT 而不是 JSP 作为表示层技术。选择 XML/XSLT 的人的观点是，JSP“ 允许您将模型和视图混合在一起”，而 XML/XSLT 不会有这种问题。遗憾的是，这种观点并不完全正确，或者至少不像白与黑那样分的清楚。实际上，XSL 和 XPath 是编程语言。XSL 是图灵完成的（Turing-complete），尽管它不符合大多数人定义的编程语言，因为它是基于规则的，并且不具备程序员习惯的控制工具。
现在的问题是既然给予了这种灵活性，开发人员就会利用这种灵活性。尽管每个人都认同 JSP 使开发人员容易在视图中加入“类似模型”的行为，而实际上，在 XSL 中也有可能做出一些同样的事情。尽管从 XSL 中进行访问数据库这样的事情会非常困难，但是我们曾经见到过一些异常复杂的 XSLT 样式表执行复杂的转换，这实际上是模型代码。

然而，应该选择 JSP 作为首选的表示技术的最基本的原因是，JSP 是现在支持最广泛的、也是最被广泛理解的 J2EE 视图技术。而随着自定义标记库、JSTL 和 JSP2.0 的新特性的引入，创建 JSP 变得更加容易，并且不需要任何 Java 代码，以及可以将模型和视图清晰的分离开。在一些开发环境中（如 WebSphere Studio）加入了对 JSP（包括对调试的支持）的强大支持，并且许多开发人员发现使用 JSP 进行开发要比使用 XLS 简单，一些支持 JSP 的图形设计工具及其他特征（尤其在 JSF 这样的框架下）使得开发人员可以以所见即所得的方式进行 JSP 的开发，而对于 XSL 有时不容易做到。

最后一个要谨慎考虑使用 JSP 的原因是速度问题。在 IBM 所作的对比 XSL 和 JSP 相对速度的性能测试显示：在大多数情况下，JSP 在生成同样的 HTML 的时候，要比 XSL 快好几倍，甚至使用编译过的 XSL 也是如此。尽管多数情况下这不是问题，但在性能要求很高的情况下，这就会成为问题。

然而，这也不能说，您永远也不要使用 XSL。在一些情况下，XSL 能够表示一组固定的数据，并且可以基于不同的样式表（请参见 [Fowler]）来以不同的方式显示这些数据的能力是显示视图的最佳解决方案。然而，这只是一种例外的情况，而不是通用的规则。如果您只是生成 HTML 来表达每一个页面，那么在大多数情况下，XSL 是一种不必要的技术，并且，它给您的开发人员所带来的问题远比它所能解决的问题多。

引自http://www.ibm.com/developerworks/cn/websphere/techjournal/0405_brown/0405_brown.html

17 楼 heimu 2008-01-10  

三年前做过一个这样的项目，当时对XLS的认识完全是0，但是学习起来似乎也没有太高的难度。不当然由于是企业项目UI相对简单。
用XML存储数据在某些情况可以简化表的设计。

16 楼 ray_linn 2008-01-10  

抛出异常的爱 写道

另一条路而已....这样的探索是 少不了的.

贼个俺同意，探索是另一回事，business又是另一回事，年底了俺对花钱的事敏感。

就这个项目谈jsp is not required，还早。

15 楼 抛出异常的爱 2008-01-10  

ray_linn 写道

triu 写道

如你所说，XSLT的开发效率体现在两个方面：1。掌握的人不多；2。缺乏相应的工具。

针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。

俺只需要一个美工，你却需要两个人，这要花钱吧？ 培训也要花钱吧？IE和FF对XLST支持不同要考虑吧？

另一条路而已....这样的探索是 少不了的.

14 楼 ray_linn 2008-01-10  

triu 写道

如你所说，XSLT的开发效率体现在两个方面：1。掌握的人不多；2。缺乏相应的工具。

针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。

俺只需要一个美工，你却需要两个人，这要花钱吧？ 培训也要花钱吧？IE和FF对XLST支持不同要考虑吧？

13 楼 triu 2008-01-10  

如你所说，XSLT的开发效率体现在两个方面：1。掌握的人不多；2。缺乏相应的工具。

针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。

12 楼 ray_linn 2008-01-10  

XLST开发效率....

11 楼 triu 2008-01-10  

ray_linn 写道

triu 写道

business的角度应该是怎样的呢？开发效率更高吗？管理更方便吗？系统更可靠吗？

Freemarker（Velocity) VS Pure XLST 三者全是。

但你不能因为是XSLT就认为全否了啊。

10 楼 ray_linn 2008-01-10  

triu 写道

business的角度应该是怎样的呢？开发效率更高吗？管理更方便吗？系统更可靠吗？

Freemarker（Velocity) VS Pure XLST 三者全是。

9 楼 triu 2008-01-10  

ray_linn 写道

XLST里的内容是全程序员的么，我看还是嵌入不少美工的活吧，XSLT又不是所见及所得，甚至目前根本没有什么好的调试开发工具。


成本，费用，进度可以让大家几乎不用去考虑一个pure xlst的框架。（局部使用当然没问题）。哪怕是界面调整，你的方案还是少不了程序员(XSLT)和美工（布局）的一起调整。

比起你的方案，Freemarker或者Veolicty更简单（占位符和最简单的view逻辑控制)，而且能拥有你提到的所有好处。


所以这种框架只是从程序员的角度去考虑问题，而不是从business的角度。

美工的活由UI工程师来完成，Web工程师在掌握了XSLT的语法后当能处理XML内容。
目前，主流浏览器已支持XSLT，只要在样例XML文件中指定XSLT，在浏览器中打开
即可看到设计效果，进一步还会开发Eclipse的插件来支持使用框架开发。

的确，界面调整是少不了程序员(XSLT)和美工（布局），但重点是这两部分都是界
面，管理上会更方便。

business的角度应该是怎样的呢？开发效率更高吗？管理更方便吗？系统更可靠吗？

8 楼 ray_linn 2008-01-10  

XLST里的内容是全程序员的么，我看还是嵌入不少美工的活吧，XSLT又不是所见及所得，甚至目前根本没有什么好的调试开发工具。


成本，费用，进度可以让大家几乎不用去考虑一个pure xlst的框架。（局部使用当然没问题）。哪怕是界面调整，你的方案还是少不了程序员(XSLT)和美工（布局）的一起调整。

比起你的方案，Freemarker或者Veolicty更简单（占位符和最简单的view逻辑控制)，而且能拥有你提到的所有好处。


所以这种框架只是从程序员的角度去考虑问题，而不是从business的角度。

7 楼 triu 2008-01-10  

ray_linn 写道

database --->xml---->html，感觉这中间的xml有意思么？

XSLT对表现来说实在是恶梦，而且导致职责不清楚，开发XSLT的是美工还是程序员，还是大家都参与？一旦需求变更，又是连锁反映.database --->xml---xlst，繁琐而复杂。


把表现和数据分离，template比xlst好用，而且属于纯美工的职责。

你的Web工程师定义很笼统，我不知道有哪几个美工会精通XSL，我看程序员都没几个。

database--->xml---->html中的xml的意义就在于能将不同的工作分离，让开发工作同步进行。

说XSLT是恶梦，你的出发点应该还是掌握的人不多，的确，这是一个推广的难点，也是Cocoon
流行不起来的原因之一。做XSLT的应该是程序员，就使用经验来看，目前普通的Web工程师经过
简单培训即可胜任，美工嘛，还是交给UI工程师来负责比较妥当。

“一旦需求变更”：这要看是什么变更了，如果只是调整界面，是不会引发database--->xml---
xlst的。而传统的开发过程要处理的情况就复杂得多了，且测试工作在每次发生代码嵌入后都必
不可少，维护成本相对较高。

最后需要承认，掌握XSL的人不多，但相信经过培训这个技术不难掌握。

6 楼 ray_linn 2008-01-10  

database --->xml---->html，感觉这中间的xml有意思么？

XSLT对表现来说实在是恶梦，而且导致职责不清楚，开发XSLT的是美工还是程序员，还是大家都参与？一旦需求变更，又是连锁反映.database --->xml---xlst，繁琐而复杂。


把表现和数据分离，template比xlst好用，而且属于纯美工的职责。

你的Web工程师定义很笼统，我不知道有哪几个美工会精通XSL，我看程序员都没几个。

5 楼 taowen 2008-01-10  

C++和Java都可以写在纸上，所以，讨厌它没什么道理呐。