Rickard, Great ideas all - I think you and Patrick are on the same wavelength with a lot of the Xwork ideas, you're just coming at them from different angles!
As for packaging, I think this is perhaps the coolest feature of Tapestry that WW doesn't have yet - and Xwork will get sooo close. Packaging I would define as the ability to create 'components' consisting of WW actions, configuration for those actions and the views. With Velocity (loaded from classpath) views, abstracted common view code and componentised actions.xml, what else do we need to do? I'm thinking something like this for actions.xml: <actions> <component name="mycomponent" /> </actions> Which looks for mycomponent.xml, which in itself another actions.xml file for just the component itself? You could of course have something like: <component name="mycomponent" file="actions2.xml" /> (to specify the file name explicitly to avoid conflicts) And we might want to not call them 'components' - that is too generic and overused a term these days. I've come across this before with WebWork while Mavenising JIRA. There is some code we've pulled out (for example the user/group management utilities) into other modules so that we can reuse it, but pulling out the user managemnet actions is a pain in the ass (JSPs are not portable!). With Xwork this could get a lot easier! My $0.02 - thoughts? Cheers, Mike On 30/12/02 10:17 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words: > About the design of XWork. > > While WebWork was pretty ok, some of the features that were put in are > not optimally designed. Here are some of the things I'm concerned about: > * Commands. Having two actions on a page both using commands doesn't > work. Generally this feature feels a little weird. > * Validation. Clunky design, and not enough loosely coupled to the action. > * Chaining. IMHO this needs a big rethink, and most of all we need to > check: what are the usecases to be implemented. > * Configuration. The monolithic style of the old configuration doesn't > really work. It needs to be possible to have multiple "sets" of actions > that can play nice together in a webapp. > * Interceptor-style code. The old way was to use base classes to add > pre/post execution code (security/transaction handling/etc.). Bad bad > bad, for obvious reasons. > * View code. The old taglib contained code that was to some extent > duplicated for the Velocity view. This needs to be refactored so that > views can share such implementations. > > These are the major things I think. Any comments on this? Any other part > that needs a rethink? > > /Rickard ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
