Webwork自带的TAG界面组件库功能不算强大，也还算实用，但是在做一些通用系统的时候，其组件与其对应的ACTION机制就不能完全满足需求。在很多通用系统中，界面往往采用批量生成的方式，而非手工绘制，这样的话，开发人员就无法确定在Action中该设置哪些字段信息。同时，在webwork现有组件库中，都需要手工设置其值取自ACTION类具体哪个数据或则数据集合。而在通用系统开发中，往往可以通过设定界面组件和后台属性字段的命名规则来达到组件自动取值的目的。
换而言之，在我构想通用系统开发中，后台Action和前台界面中间通过互传数据包来达到通信的目的，这个数据包有那些属性信息是根据具体的页面场景来规划的。那么，在后台，完全可以作到只有一个ACTION类，这个ACTION就只接收一个数据报，然后分析数据包的信息，再传给业务逻辑操作类执行业务逻辑，这个操作类可以是会话BEAN，也可以是其他。那么，要达到这个目的，就要重写写一个拦截器，该拦截器将页面传递过来的值按规定打成数据包，然后将该数据包注射到ACTION类中。由于ACTION类只有一个，那么该ACTION返回的页面就是系统统一的容器页面，容器页面会根据返回数据包的内容去加载其他页面组件。
同时，扩展webworkTAG库的目的就是要让界面组件自动去找寻数据包是否有传给自身的值
换而言之，在我构想通用系统开发中，后台Action和前台界面中间通过互传数据包来达到通信的目的，这个数据包有那些属性信息是根据具体的页面场景来规划的。那么，在后台，完全可以作到只有一个ACTION类，这个ACTION就只接收一个数据报，然后分析数据包的信息，再传给业务逻辑操作类执行业务逻辑，这个操作类可以是会话BEAN，也可以是其他。那么，要达到这个目的，就要重写写一个拦截器，该拦截器将页面传递过来的值按规定打成数据包，然后将该数据包注射到ACTION类中。由于ACTION类只有一个，那么该ACTION返回的页面就是系统统一的容器页面，容器页面会根据返回数据包的内容去加载其他页面组件。
同时，扩展webworkTAG库的目的就是要让界面组件自动去找寻数据包是否有传给自身的值
217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
