Mike Cannon-Brookes wrote:
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?
That should be it I think.
Why not use XML entities? That's what they're for, right? And with that in place it becomes trivial to have alternative configuration styles by simply creating a custom entity resolver. E.g.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?
<actions>
&mypackage.xml;
&otherpackage.properties;
</actions>
The resolver could transform the properties file data into XML, so that the main loader only deals with XMl.
You could of course have something like: <component name="mycomponent" file="actions2.xml" /> (to specify the file name explicitly to avoid conflicts)
See above.
Not sure there's any need on the XML level for a "component" notion. Just having actions being defined, and then package it all in one JAR should do the trick. Or?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!
Agree. /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
