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的方法使得不同的使用者可以选择不同的风格，体验变得更有趣。

 

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

XSL＋XML难到就比jsp好吗？
我个人非常讨厌XSL

跟那个 cocoon 有什么区别

是的，从2003年开始研究Cocoon，只不过sitemap让我望而却步，一直不敢在项目里使用Cocoon。
直到前段时间完成了异构资源共享和业务流程管理，才想到了不使用sitemap的方法，所以，区别
就在管理上，用功能目录的定义代替了sitemap，这样容易配置，也才能实现热部署。

对了，框架还支持多语言。

重要的不是哪个好，而是哪个对项目更有帮助，分工更明确就会利于管理，
开发效率自然就相对高一点，呵呵，这才是重点。

另外，XSL和XML在语法上基本上相同，所以，讨厌它没什么道理呐。

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

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的人不多，但相信经过培训这个技术不难掌握。

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


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

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


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

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

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

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