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]>

Reply via email to