On Wed, 15 Sep 2004 17:49:21 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote: <snip /> > >You could even easily create a command that, instead of executing an > >Action's execute method, calls a custom method on a POJO like JSF > >(I've done some experimenting here: > >http://www.jroller.com/page/mrdon/20040706#zero_configuration_with_struts). > > The POJO's setter methods could even be called using request data, > >removing the need for action forms. > > > I thought about this but I wonder how easy it will be to drop the use of > ActionForms. They currently provide some nice functionality that would > be missed. > My point is you have the option to go either way. Recent code by Niall allows you to take a POJO and wrap it with an ActionForm, having the advantages of both.
> >Of course much of this is possible with the current Struts by > >extending RequestProcessor, but that approach had a number of > >disadvantages: > > 1. Extra work (two extensions) to support regular and tiles RequestProcessors > > 2. Couldn't co-exist with any other extensions > > 3. Hard to test > > > > > > > Yes this will be sweet! So you can easily pick and choose your > extensions and add new ones. Will there be subtle issues (like the > order of the command chain) for tiles and validator to work properly? Yes, that there will. Commands generally work by pulling things out of the context, doing stuff to them, then putting them back in. If a command that depends on a certain object is before the command that adds that object, the first command should code for that and throw a warning. Ideally, commands will be quite short and well-documented to mitigate that issue. > >Furthermore, and perhaps most importantly, Struts-chain brings with it > >the potential to remove the Servlet dependency, making it easy to run > >your Struts app in a portlet or any other container. > > > If you remove ActionForms, Actions and the Servlet dependency, is it > really Struts anymore? Most of my logic is currently already outside of > the Actions (I use the facade pattern.) Wouldn't it make more sense > for me to chain my business logic behind the facade? Ultimately I'm > still writing a web application, so how do I get away from the "Servlet > dependency?" I think I see where you are going with that statement but > I'm not sure about some of the details. Can you help me to understand > how you see this working? Think of what Struts is all about - processing request/response flows (the C in MVC). To assist in the processing, it provides form support, validation, some flow control, action invocation. Struts-chain helps break up these request processing features into their own individual, composable, replacable commands. It isn't about replacing ActionForms or Actions, but exploring different and perhaps better ways to provide these capabilities. The need for form processing is key to web applications, but whether that need is met by an ActionForm or some clever handling of a POJO (ala JSF, WebWork, etc), should be optional and easy for the developer to change/customize/improve. As for the Servlet independency issue, the obvious reasson is to support portlets (JSR 168). Portlets, just like standalone web applications, have forms and actions that need to be performed. Instead of requiring your actions to depend on HttpServletRequest, struts-chain provides a WebContext that provides Maps of most information you want to interact with from the ServletRequest. This way you can write actions/commands that use work simultaneously in Servlet and portlet environments. Furthermore, for special cases, you can still access the underlying ServletRequest, but just be aware that capability might not be available in other contexts like a portlet container. Don > > > > Thanks, > sean > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
