> * Actions and Components, and their resulting views, are ALWAYS called > through a servlet include.
I find this rather unprovoced myself. I see that you don't want to reveal that xwork is being used and that actions shouldn't be directly accessible from a URL, but doing this by demanding a servlet include seems like a very strange way of going about this in my mind. Composition of the portlet style seems to me as a bad way to use includes and a good way to use sitemesh or such technology. Remember simplicity here. If we want one page that only runs one action it seems rather nasty to do a jsp file with only one include line. Not only that, but this doesn't really solve the issue of hiding the implementation since you'd still have the jsp file. I think this idea never to show the implementation is good, but I think it is outside the scope of XW. Furthermore a filter that you configure to map say http://mysite/admin to Admin.action or in your case a admin.jsp that does includes of actions in a portlet style, is what I would consider a good solution. Especially if such a filter can have regular expressions in such a lookup mechanism so that it can actually do the .action mapping we currently have in WW. Thoughts? > * The execution of a Component (and maybe Action's too) needs to be > split into two phases. The actual execution of an action is done at the > *beginning* of a page render, and the rendering is done at the time of > the include. Hmm, this seems to me to be a very good reason not to do servlet includes like you suggested above. Either that or I totally misunderstood what you meant. > * When rendering URL's, the parameters need to be namespace'd in order > to allow several portlets to happily live together on a page. I.e. > instead of having ?foo=bar one could have ?1.foo=bar&2.foo=bar. The > XWork servlet dispatcher would then at execution filter out those > parameters which does not apply to the action/component/portlet being > executed, and only the remaining parameters are applied using the setX() > initialization code. This requires the rendering code to use either a > taglib (in JSP) or some JavaBean (in Velocity) which can do this > encoding. I know that for *some* applications this will be overkill, but > for those of use who are going beyond very simple web apps it is a > definitive must. I have been thinking about something like this myself actually. Say you have getFoo and setFoo in your action. This returns a Foo reference: class Foo { public String bar; public class setBar(String bar){this.bar = bar;} } Now, if I have a URL for my action such as MyAction.action?foo.bar=pirogue then it seems very intuitive to me that xw should look up "foo.bar" in the normal value stack manner and set that value. This handles the issues of namespaces with multiple actions transparantly as long as you require each action to have a different name (or sub-componants at that, we should think about that too). Great ideas Richard, good to see you back, if that's what you are :P Anders Hovm�ller [EMAIL PROTECTED] http://boxed.killingar.net ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
