struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Struts or SpringFramework
Date Fri, 18 Feb 2005 18:11:05 GMT
There was talk during a brainstorming session on the future of
Actions, where the idea was put out that perhaps Action could go away
and everything could be in the same chain catalog.   I believe that
idea was eventually abandoned as Struts chain commands are going to
have the "execute(ActionContext ctx)" signature where the
ActionContext class is specific to Struts, and we do _not_ want user
applications to be tied to Struts.  The application logic should be
independent of Struts and having that tight of coupling would
encourage developers to just code most of their application in those
Struts-specific commands.  As a general rule, we are trying to make
Struts less intrusive, not more.



On Fri, 18 Feb 2005 09:55:41 -0800, Dakota Jack <> wrote:
> Thanks, Don.  This is really, really, helpful.  One last little
> question, given this much, when there is talk that seems to envision
> put action as a part of the chain, what does that relate to?  That
> seemingly could not be the part that has a chain supplanting the
> request processor "in" the action servlet.  However, that really does
> not seem to be appropriate for the "application logic" chain either.
> What is that about?  That is one place where I get confused.
> <snip>
> On Fri, 18 Feb 2005 09:48:19 -0800, Don Brown <> wrote:
> > The inherent problem with following a developer list is you will hear
> > many different opinions, usually with the goal of coming to an agreed
> > solution or direction, but that direction, once agreed upon, usually
> > isn't clearly laid out.  If you want clear direction, look at the user
> > guide, release notes, or one of the many Struts books.  If you want to
> > see all the discussion, debate, and exploration that is required to
> > arrive at those directions, then follow the dev list. :)
> >
> > I felt you described the goal of using chain in the Request Processor
> > very well - a pluggable process that the user can customize to their
> > hearts content.  If you want to handle population through OGNL, then
> > rewrite the PopulateActionForm command.  If you want to add a command
> > that pulls a user profile out of the database and puts it in the
> > request, go ahead and stick it in there.  If you don't want to use
> > Actions at all, write your own Create/ExecuteAction commands.  In your
> > case, if you don't want multi-part support, cut those actions out of
> > your chain.
> >
> ....................
> > Exactly, although I would add that second chain is optional as it
> > might work well for some, but others, like me, would perfer other
> > routes.
> >
> </snip>
> Jack
> --
> "You can lead a horse to water but you cannot make it float on its back."
> "Heaven has changed.  The Sky now goes all the way to our feet.
> ~Dakota Jack~
> "This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message