struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitc...@telocity.com>
Subject RE: Changes to form lost on forward
Date Wed, 17 Jul 2002 16:43:37 GMT
Where are you editing the input data?

Can you give us a basic use case of what you are doing?


James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta




> -----Original Message-----
> From: Wilinski, Pamela M. [mailto:pwilinski@Kraft.com]
> Sent: Wednesday, July 17, 2002 12:30 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Changes to form lost on forward
>
>
> I agree that our design is ugly.  Being new to struts and not
> being able to
> use javascript I wasn't sure how to handle forwarding based on a
> choice made
> by the client.  Each report they can choose off the menu has it's
> own action
> and form.  Also where is it correct to do editing of inputted data.    I
> really wish to do this correctly.
>
> Thanks!
> Pam
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, July 17, 2002 11:04 AM
> To: Struts Users Mailing List; Struts-Atlanta@open-tools.org
> Subject: RE: Changes to form lost on forward
>
>
>
>
> On Wed, 17 Jul 2002, James Mitchell wrote:
>
> > Date: Wed, 17 Jul 2002 11:38:19 -0400
> > From: James Mitchell <jmitchtx@telocity.com>
> > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>,
> >      Struts-Atlanta@open-tools.org
> > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > Subject: RE: Changes to form lost on forward
> >
> > Struts repopulates the Action's associated ActionForm every
> time an Action
> > is called.
> >
> > There have been a few debates on this subject.  I can't seem to find the
> > (lengthy) thread on this discussion from the archives.
> >
>
> This discussion often happens under a subject line like "chaining
> actions".
>
> > While it doesn't fit everyone's needs, I happen to agree with the way it
> was
> > implemented.
> >
> > In theory, your workflow should be structured so that 'the Action you
> submit
> > to' should use the ActionForm "as-is". The subsequent Action (should you
> > chose to do that) should build (or request from the biz tier) the newest
> > ActionForm and not try to carry it around from action to action with the
> > hope of sending it along to the next view.
> >
>
> I agree with James that the current design is the right one, but perhaps
> feel more strongly than he does about the reason -- IMHO, chaining Actions
> is not a particularly good design choice.  And it should not be necessary
> either.
>
> Consider code where you'd like to do:
>
>   Action A --> Action B --> View C
>
> A simple refactoring of the business logic out of Action A and Action B
> can lead to an
>
>   Action X (calls A' and B' business logic beans) --> View C
>
> where Action X calls the business logic beans that were abstracted from A
> and B in the right order.  Usually, the chaining pattern is considered
> when the logic in Action B needs to be reused -- you get the same reuse
> benefit by abstracting that logic out into a separately callable business
> logic bean, and calling it from all the actions that need it, so that you
> can have in addition:
>
>   Action Y (calls C' and B' business logic beans) --> View whatever
>
> I like to think of an Action instance as a "script" of sorts, that brings
> together into one place calls to *all* of the stuff that needs to be done
> for a single request.  Spreading logic across multiple actions makes it
> much harder to understand all the pieces of that "stuff".  Combining them
> together makes it crystal clear.
>
> > James Mitchell
> > Software Engineer\Struts Evangelist
> > Struts-Atlanta, the "Open Minded Developer Network"
> > http://www.open-tools.org/struts-atlanta
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message