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的方法使得不同的使用者可以选择不同的风格，体验变得更有趣。
框架新近开始支持热部署，包括框架系统配置部分以及所有发布到框架中的应用软件。同时，框架还支持数据同步，以适应集群服务器部署。
评论
为了 实现 层之间的通信 需要 定义 各种标准 接口。
松耦合不见的好用。
这要看从什么角度来看了，如果开发上了一定规模了，还是清晰比较好，因为，那个
时候管理成本是大头了。
凡事都有个度，看怎么把握了，对于松偶合嘛，眼光要放长远一点，开始可能花费不
菲，可大家公认的真理是：变化才是永恒的，所以，如果需求变化造成的影响能被限
制在一定范围，而不会波及到系统的其他部分，那就值了。
为了 实现 层之间的通信 需要 定义 各种标准 接口。
松耦合不见的好用。
很对呵，我也发现了“大部分的功能都差不多”，呵呵，我现在是用复制加替换变量的方法。
genereator的工作正在考虑中，如果能的话，就放到Eclipse插件里一起做了。
不是纯粹地用XSL，在框架里XSL的地位只相当与CSS，况且，DTD的语法不符合XML定义，
应该使用XSD。
我这么做正是基于自己在多年的开发工作中感受到的痛苦，努力地想简化
开发过程，让开发工作能准确定位，能更精确地预测项目的开发周期，我
知道CMMI的目标是什么，所以，我不能同意各位的说法，当把它进行到底。
再次感谢。
针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。
确实掌握的人不多，因为用这个做项目的本来就少，一般也只有国外个把项目是用这个技术的。
工具你可以考虑Altova XMLSpy，这个足以满足项目的开发。不过是收费的，网上有key，但是注册了还是过期。
谢谢你的建议，当然将来能做出Eclipse的插件来做开发是最好的了。
上学的时候写小论文就是写XSLT+XML做web层的适用性研究，虽然论文是那样写的，但是我感觉不太实际，至少目前，说这些并没有打击楼主的意思，只是就技术论技术
XSLT+XML做Web层用过一次，做国外的一个在线优惠券兑现系统，真的很痛苦，其实我写几个模块没有什么，就是把读出来的数据生成规定的XML，但是我觉得在很多国内系统中不太现实，代价或者周期有点高，估计国内用这种技术的公司寥寥无几，这个是现实问题。
我想问楼主一下，你们对于大于1M的XML文件如何处理的？是分解？
PS：我觉得有点奇怪，这个帖子为什么投隐藏呢？技术嘛，终究是讨论讨论嘛
不会有大于1M的文件，XML内容只是页面上的动态数据，而不是描述整个页面及其布局的，
举个例子就是数据库结果集，且这个内容会采用分页。而对于需要文件上传和下载时使用
单独的文件服务器，XML只提供文件地址。
有人投隐藏，那在那个人看来就有一定的道理。
当然这个隐藏是我投的，光明正大，我来说道理：
这个帖子 1)犯了标题党，2)这里是海阔天空，不是Java版。
转到Java版，我投隐藏的机率会很低，但不排除因为“标题”原因也来一次。
(我是很懒很懒投隐藏、入门的)
看不惯，那就互相扯皮或只好忍者。这就是网络!
这样的结构的失败项目就摆在我面前，可以说是后患无穷。不过话说回来，没有切肤之痛，实难有感触的。
再多说一句，以这样的结构做复杂业务系统，可是说是没事找抽，做做简单网站兴许。
原因嘛，前面人都说完了。对楼主不撞南腔不回头的执着表示佩服。
针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。
确实掌握的人不多，因为用这个做项目的本来就少，一般也只有国外个把项目是用这个技术的。
工具你可以考虑Altova XMLSpy，这个足以满足项目的开发。不过是收费的，网上有key，但是注册了还是过期。
上学的时候写小论文就是写XSLT+XML做web层的适用性研究，虽然论文是那样写的，但是我感觉不太实际，至少目前，说这些并没有打击楼主的意思，只是就技术论技术
XSLT+XML做Web层用过一次，做国外的一个在线优惠券兑现系统，真的很痛苦，其实我写几个模块没有什么，就是把读出来的数据生成规定的XML，但是我觉得在很多国内系统中不太现实，代价或者周期有点高，估计国内用这种技术的公司寥寥无几，这个是现实问题。
我想问楼主一下，你们对于大于1M的XML文件如何处理的？是分解？
PS：我觉得有点奇怪，这个帖子为什么投隐藏呢？技术嘛，终究是讨论讨论嘛
流程和框架的价值在于QCD（质量、成本、交付期）指标的改善。
说得很好，谢谢你，这就是我做这个框架的出发点。
下一步是，找到合适的项目，将项目做成插件发布到框架中。
计划就这么简单。
流程和框架的价值在于QCD（质量、成本、交付期）指标的改善。
发表评论
提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则
- 浏览: 4171 次
- 来自: 成都
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
JSP is no longer require ...
stevenwang 写道个人愚见，越清晰的 架构，复杂度 越高，时间 成本 越 ...
-- by triu -
JSP is no longer require ...
个人愚见，越清晰的 架构，复杂度 越高，时间 成本 越高。为了 实现 层之间的通 ...
-- by stevenwang -
JSP is no longer require ...
Transformers 写道建议做一些code generator，我现在的项 ...
-- by triu -
JSP is no longer require ...
建议做一些code generator，我现在的项目也是基于XML+XSLT，在 ...
-- by Transformers -
JSP is no longer require ...
ray_linn 写道XSL一下类似docbook这样复杂的DTD就知道爽了. ...
-- by triu
评论排行榜