浏览 6074 次
锁定老帖子 主题:Web AOP?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-02-16
这是我接手的一个web系统的一个设计。我觉得很不爽,但是一时又没有好的解决方法。 情况是这样的。 我们的web app是一个传统的jsp+controller+dao的设计(Controller用的是我们元老自己设计的一个框架)。 这个app我们叫做product。 除此之外,我们还有一个定制版本的app。这个定制版本是给某个客户定制的。功能和product大同小异。但是有些小的地方的业务逻辑或者web页面会有些区别。(比如说某个提示信息不同,或者多出或者少一个text box之类的) 大家知道jsp的复用不是很容易的。而这个定制版本和product的区别完全都是这个特定客户决定的,并没有可以实现预测的比较系统的规则。 现在的解决方法,是在product里面增加一个叫做HtmlManipulator的接口: interface HtmlManipulator { String manipulate(String html); } 然后通过一个ChainManipulator把一个数组里的HtmlManipulator串接起来。在product里面这个manipulator的数组是空的。而在定制版本里面,则是通过写各种HtmlManipulator来实现订制,比如下面的伪代码: class ChangeUserMessageManipulator implements HtmlManipulator { public String manipulate(String html) { range = find range of element("user message"); return replaceRangeWith(html, range, "this is the new user message"); } } 也就是说,所有的定制都是通过拦截并且篡改product生成的html文本来实现的。 是不是看起来非常象基于web页面的aop? 我很不喜欢现在这个方法。 效率是一方面。 这个方法感觉非常原始,而且很多这种manipulator工作都是依赖于html里面的某个特征字符串,理论上如果数据库里面储存了一个“user message”然后被product写入html,那么上面的代码就会失效。 不过,至少在不彻底推翻现有框架的基础上,我想不出什么好方法。 独立维护product/定制两套代码是不可接受的。 感觉也许需要采用基于web组件的技术才行。(不熟悉tapestry,不知道是不是合适)。 这两天发现了一个StringTemplate,看来似乎也是一个可能的方向。 聪明如你,有什么好的方法么? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-02-16
看来,这个产品没有经过良好的框架设计,或者说,没有良好的为可扩展性、可定制性进行设计。
一般来说,比较理想的情况是,一套公共的代码,加上不同的扩展程序、资源文件,即成为客户化的软件版本。 那么产品(即公共代码),应该对上述行为良好的支持。 针对你所提出的情况, 1.不同的提示。 一般将这些提示放在资源文件中,java里是ResourceBundle,一般用在国际化用途上,在这里也完全可以用在多客户版本上。不同客户只需切换不同的资源文件即可,将变化的部分最小化、完全分离出来。 2.少量不同的JSP界面。 我认为应该参考上面的做法,用可以配置的文件来组装不同的资源。比如使用XML。 需要预先(或发现需要后重构)定义好扩展点,比如说什么地方可能加入Textbox的。可考虑使用spring或自定义的机制来完成。 总的来说,就是要清晰的隔离公共部分和客户化部分。 使得产品部分和客户化部分仅通过约定的接口关联,可以相对独立的进行开发,互相影响减到最低。 |
|
返回顶楼 | |
发表时间:2007-02-16
我建议用javascript结合java的方式进行改造。
我们把问题分成2个小问题: 1. 定制提示文本信息 用EL表达式能解决大部分的问题。 2. 页面结构的定制 在xml文件或者数据库中存放页面组件的结构,并提供客户动态定制的界面。java掌控组件结构和属性的初始化动作,将组件结构和属性通过xml或者json传递给页面,页面部分通过javascript来进行渲染。 以上仅供参考 |
|
返回顶楼 | |
发表时间:2007-02-16
Depends on the differences, there are several options.
1. Since the user will drive this difference, we need some kind of flag in the user object, like company name, to identify this case. 2. if the diff is only in web pages, not data, then put the difference in the jsp page where you can set the user as the flag. 3. if the diff is data only, then do it in the controller. 4. if the diff is both, then seperate them using 2 and 3. If you have one client only, then a simple if else is good enough, otherwise, with 3 or most clients, we should refactor things out. For example, for web pages, we may create separate templates and name them with company name for selection. For data difference, we may create separate strategies depending on users/clients. |
|
返回顶楼 | |
发表时间:2007-08-15
似乎你的关键问题是:对于要操纵的Element没有把握,没有边界感,觉得低级的字符串比较太容易出现偏差。
你是不是可以想办法把加边界这个行为内嵌到页面生成里面,以方便后继的修改?什么?本来就没有逻辑上的边界,本来就是随意的选取一部分内容进行修改!哦,那就算了,那样的话,现在这个方法就不赖。 |
|
返回顶楼 | |
发表时间:2007-08-15
这不是不爽,简直是不可理喻。
对于最终结果页面的字符串替换,只能用于解决特殊bug,用来作为一般的customize机制是自掘坟墓。 ajoo同志偶建议你把规则简单并且有明确意义的manipulator,可以提取出来,改成模板方式的。其他的,还是独立成一个单独的代码分支吧。 |
|
返回顶楼 | |
发表时间:2007-08-15
hax 写道 这不是不爽,简直是不可理喻。
对于最终结果页面的字符串替换,只能用于解决特殊bug,用来作为一般的customize机制是自掘坟墓。 ajoo同志偶建议你把规则简单并且有明确意义的manipulator,可以提取出来,改成模板方式的。其他的,还是独立成一个单独的代码分支吧。 多谢,多谢。 俺已经不做擦大便很久了。 |
|
返回顶楼 | |
发表时间:2007-08-15
在我们的系统中可以修改biz文件来控制界面元素的增减, 特别是一般元素都定义了逆元操作, 因此页面差异一般不是什么问题.
|
|
返回顶楼 | |