You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Reid Pinchback <re...@yahoo.com> on 2001/12/31 21:03:06 UTC

Looking for a clean required-bean handler

Hi all!

The more I did into Struts the more I like it.  I have noticed
something that has me scratching my head a bit, wondered
if anybody else had come up with a clean solution.

Struts has a nice clean approach to organizing code and
behaviour after you click on something.  In other words, if
I have a form then I have a nice way in Struts to associate
the handler with the form.  If I have a URL then there are
decent ways that I can maintain the destinations in the
controller instead of in the html/jsp pages.  All nice.

What I don't see is a straight-forward way of indicating
what I want *before* going to a JSP page.

Ok, I know... that probably sounds a little odd.  My point
is simply this: my JSP pages are maintainable because
they, as view artifacts, don't know much about each other.
If I want may action classes to be just as maintainable
then they can't know much about each other either.

That is the thing I don't like about actions at the moment.
The action figures out how to process the incoming data
from the request *and* prepare the page/session/whatever
context before going to the next page.  An action can only
do that if it *knows* what the next page will require.  That
 means there is less point in having that transition information
explicitly captured in struts-config.xml because I might have
to know the same information implicitly in the action code.

So, here is what I want, and I'm hoping somebody has
already found a clean approach for it.  Instead of only
writing "process-X" actions, I also want to write some 
"prepare-for-Y" actions.  Then any JSP page has
potentially two actions; one executed as I head
into the page (e.g. to prep dynamic content), the other
executed as I head out of the page (e.g. for user response).
The clean way I can think of is to have some kind of
action that iterates over the beans that will be needed
by the next page, i.e.:

- step 1, if I don't have a UserBean, get me a UserBean
- step 2, if I don't have a UserPrefsBean, get me one
  (etc)

Then, you'd need some way of getting a controller-mediated
way of recognizing that some particular action must be
invoked to get a UserBean, etc., and then returning control
back to the "prep" action.  Once the prep action has
everything it needs, it forwards to the next step.

Is this crazy?  Sane but not done before?  Sane and
done already?  

Inquiring minds want to know!

Thanks.... Reid

 

 



---------------------------------
Do You Yahoo!?
Send your FREE holiday greetings online at Yahoo! Greetings.

Re: Looking for a clean required-bean handler

Posted by Reid Pinchback <re...@yahoo.com>.
   Francisco Hernandez <fh...@fhernandez.net> wrote: 
this sounds something like the "Pull" model where the jsps "Pull" the data
they need rather then the "Push" model where the data is "Pushed" into the
jsp.. hrmm..
checkout http://sourceforge.net/projects/webwork
its "Pull HMVC" its worth a shot if i correctly understand what your trying
to accomplish

 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.

Re: Looking for a clean required-bean handler

Posted by Francisco Hernandez <fh...@fhernandez.net>.
this sounds something like the "Pull" model where the jsps "Pull" the data
they need rather then the "Push" model where the data is "Pushed" into the
jsp.. hrmm..
checkout http://sourceforge.net/projects/webwork
its "Pull HMVC" its worth a shot if i correctly understand what your trying
to accomplish
----- Original Message -----
From: "Reid Pinchback" <re...@yahoo.com>
To: <st...@jakarta.apache.org>
Sent: Monday, December 31, 2001 12:03 PM
Subject: Looking for a clean required-bean handler


>
> Hi all!
>
> The more I did into Struts the more I like it.  I have noticed
> something that has me scratching my head a bit, wondered
> if anybody else had come up with a clean solution.
>
> Struts has a nice clean approach to organizing code and
> behaviour after you click on something.  In other words, if
> I have a form then I have a nice way in Struts to associate
> the handler with the form.  If I have a URL then there are
> decent ways that I can maintain the destinations in the
> controller instead of in the html/jsp pages.  All nice.
>
> What I don't see is a straight-forward way of indicating
> what I want *before* going to a JSP page.
>
> Ok, I know... that probably sounds a little odd.  My point
> is simply this: my JSP pages are maintainable because
> they, as view artifacts, don't know much about each other.
> If I want may action classes to be just as maintainable
> then they can't know much about each other either.
>
> That is the thing I don't like about actions at the moment.
> The action figures out how to process the incoming data
> from the request *and* prepare the page/session/whatever
> context before going to the next page.  An action can only
> do that if it *knows* what the next page will require.  That
>  means there is less point in having that transition information
> explicitly captured in struts-config.xml because I might have
> to know the same information implicitly in the action code.
>
> So, here is what I want, and I'm hoping somebody has
> already found a clean approach for it.  Instead of only
> writing "process-X" actions, I also want to write some
> "prepare-for-Y" actions.  Then any JSP page has
> potentially two actions; one executed as I head
> into the page (e.g. to prep dynamic content), the other
> executed as I head out of the page (e.g. for user response).
> The clean way I can think of is to have some kind of
> action that iterates over the beans that will be needed
> by the next page, i.e.:
>
> - step 1, if I don't have a UserBean, get me a UserBean
> - step 2, if I don't have a UserPrefsBean, get me one
>   (etc)
>
> Then, you'd need some way of getting a controller-mediated
> way of recognizing that some particular action must be
> invoked to get a UserBean, etc., and then returning control
> back to the "prep" action.  Once the prep action has
> everything it needs, it forwards to the next step.
>
> Is this crazy?  Sane but not done before?  Sane and
> done already?
>
> Inquiring minds want to know!
>
> Thanks.... Reid
>
>
>
>
>
>
>
> ---------------------------------
> Do You Yahoo!?
> Send your FREE holiday greetings online at Yahoo! Greetings.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>