Thanks for your response, Ted. I (or another developer on my team) will be driving a spike on this in the next few days but I wanted to parrot back what I understood for confirmation.
Assume that I cleanly separate the intent of my actions into RequestAction and ViewAction. The mappings for RequestActions may specify ActionForms because they are the targets of HTTP posts and I want a form to be created, auto-populated, and validated. The ActionForm instance is automatically stored in either the request or session scope by the ActionServlet. The RequestAction's perform method is called and it goes about doing whatever it needs to do to satisfy the request. When finished, the RequestAction uses ActionMapping to find an ActionForward by name and returns that to the ActionServlet. This ActionForward actually specifies a "ViewAction" which ActionServlet forwards to. Since the ActionServlet is also the target for the ViewAction URI, it intercepts the request and processes it just like any other Action. Now my intent would be that ViewActions are not typically the direct targets of posts. They are only ever forward targets from other Actions. As a consequence, I would not specify an ActionForm in the mapping for a ViewAction. If I understand your comments correctly, that means that the ActionForm instance constructed by the RequestAction is still in the specified servlet collection from where it can be directly retrieved by the ViewAction and used to generate the response. If there is no ActionForm, the ViewAction could choose to "balk" or go ahead and generate the HTML with form elements blank. That way it _could_ be the target of a post to generate an initial blank form. If I may, I'd like to take a moment to explain my reasoning here. I know that a large part of Struts is the taglibs that can be used to get the Java code out of JSPs. I think that is an admirable step. However, in the organization that I consult with, there is a very clear delineation between site designers (the graphical types that also write the HTML) and Java developers (who write the business logic and hook the HTML pages into it). The delivery timeframes are short and these two groups work in parallel. Site designers don't understand and don't like seeing JSP tags littered throughout their HTML. Nor do many of the tools they use as inclusion of JSP tags in the HTML results in "invalid markup". Finally, JSP (and similar technologies) force different groups to collaborate on a common document. Since the contents of the document, at least here, are in continuous revision until just before delivery there is a significant collision between the groups. Casting about for an alternative that would solve these problems and still offer decent performance is what finally led me to XMLC. http://xmlc.enhydra.org/project/aboutProject/index.html I think this ability to incorporate alternate presentation generation strategies into the Struts framework will be an increasing concern. I've seen mention on the mail lists about the ability to incorporate Velocity as a JSP alternative. And, while not yet ready for prime time as far as I can tell, the XML/XSL strategy will be maturing. Regardless of which presentation generation strategy is used, a mature, robust, tested, and open-source MVC framework (ie, Struts) will be needed to solve all the _other_ problems relevant to best practice construction of web applications. An effective solution, clearly elucidated, will go a long way to attracting the JSP-opponents and the JSP-wary to Struts. Thanks again, Ted, for your attention and guidance. Best regards, Jim Cakalic > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 06, 2001 6:52 PM > To: Struts Users Mailing List > Subject: Re: action chaining without resetting action forms > > > When you forward to a JSP, the original ActionForm and > ActionMapping are > left alone. > > As it stands, when you forward to another Action, the > ActionServlet uses > the same processing cycle it used for the first Action. If an > ActionForm > is specified by the mapping, the ActionServlet will try to > populate it. > It will also put the mapping for the second Action into the request, > obliterating any trace of the original Action. As far as your > "ViewAction" knows, it is the one and only Action that has > been called. > > If your response-Action is using its own data structures, and is not > looking for the Struts ActionForm or ActionMapping in the > request, or is > hiding them in delegates, then you are all set. > > Of course, if it is not using the ActionForm or ActionMapping, why not > make it a standalone servlet? At which point it would be exactly the > same as forwarding to a JSP. > > A current DEV idea is to provide for invoking the Action > directly. This > would work better for you, and is an easy change to the ActionServlet. > This would also allow you to share ActionForms and ActionMappings > between Action objects. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ > > > "Cakalic, James P." wrote: > > Upshot is, if there are any problems forwarding between > Actions that are > > essentially different than the semantics of forwarding from > an Action to a > > JSP, I really need to know what they are and how they can > be addressed. > > > > Best regards, > > Jim Cakalic > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
