"Cakalic, James P." wrote: > 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.
Yes, if it knew what the ActionForm was called. This information would be in the mapping for the original request, which would not be available in the normal course. If conventional forwarding it to be used, it would be my suggestion that the ActionForm, or equivalent, be forwarded under a predetermined name. One way to go would be to use the "attribute" property of ActionMapping to give all the ActionForms the same name in the request. > 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 Enhydra and Barracuda seem like solid endeavors. Also a good choice. > 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. Personally, I'd think in terms of putting whatever you have in mind for an Action into a servlet, so that it is not coupled directly with Struts. I have been working with the Velocity team on finishing the work Geir started last spring. We should have an improved VelServlet available for testing next week. The approach here is to forward to a Velocity servlet to render the page, so that they are drop-in replacement for JSPs. Again, you should really think about doing the same approach for your project. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
