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.
HTH, Don On Fri, 18 Feb 2005 09:55:41 -0800, Dakota Jack <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
