Hi, definitely works. It is the way I recommend to our programmers. Makes it easy to prepopulate all the forms on jsp's.
good luck Alexander -----Original Message----- From: Michael Sabitov [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 12:49 AM To: 'Struts Users Mailing List' Subject: RE: Looking for a clean required-bean handler This is exactly what I'm trying to implement in my current project. Although I want to use a little bit different approach for invoking next "before" action: Every "after" action would have a result (for example "success", "error" etc.) and it would have an action mapping for these results in struts-config.xml. These mappings would forward not to the next .jsp page but to the next "before" action. This "before" action would have a regular action mapping to its corresponding .jsp page. Would it work? I don't know yet. I'll create a proof of concept in next couple of days and see... Thanks, Michael. -----Original Message----- From: Reid Pinchback [mailto:[EMAIL PROTECTED]] Sent: Monday, December 31, 2001 5:26 PM To: Struts Users Mailing List Subject: Re: Looking for a clean required-bean handler Thanks for the pointer, I'll check it out! I also had a few thoughts about a Struts solution on the train home. See if you think this makes sense. 1. Create "before" and "after" actions. 2. "after" actions look like what people are used to for processing forms in Struts, only a bit simpler. The job of an "after" action is to consume any form beans and generate appropriate side-effects *independent* of what the next page might be. So, in an EJB app you would make state changes, and in a login page you might stuff some kind of User javabean into the session context because you know all pages would go looking for it. Once done, the "after" action would look for a magic request parameter; if present that would provide the name of the next action (basically a return path), otherwise transition out in whatever way(s) would be normal for the action. 3. each "before" action only preps for the display of one particular JSP page and inherits from a base class that adds a bit of simple workflow support to the basic Action. All such subclasses provide lists of bean names to look for and the context in which they should be found. The parent class functionality iterates over those lists, and if anything is missing then the magic return parameter is set and an action is invoked to supply the missing bean. The action could be derived by applying a naming convention to the bean name (e.g. "myBean" -> "/before/myBean.do"). Once you have the required beans, you do any other setup work required for the page, and then forward to the JSP page. Now, there is some complexity to that magic return value that I'm glossing over, but aside from that I think this would work. It results in an extra "K" before action classes, where "K" is the number of web pages in your application. It would also end up with another "K" action mapping entries in struts-config.xml. On the other hand, all the after action classes would be simpler and more independent of each other. --------------------------------- Do You Yahoo!? Send your FREE holiday greetings online at Yahoo! Greetings. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>