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. On Fri, 18 Feb 2005 09:30:49 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Thanks, Don. Much appreciated. The problem is that there is no > consistency on this. I tried, for example, to discuss naming and the > Struts chain and got severely stomped on for having the stupidity to > think that Struts and Commons could be considered seperately. I have > a real interest in chain, IF it is intended to make the request > processor pluggable, because I would like to use the standard Struts > with some changes. For example, I would like to get away from the way > the request processor treats multipart form uploads, tying you to an > implemenation I don't care for that much. > > Because business decisions need to be made, whether people care or > not, it would be good if one could tell what is intended for Struts > 1.3 in fact. I hope that this does not once again generate heat > instead of light. Unless someone says something different, I am going > to assume that this is a correct statement of what is happening. > Maybe I am not understanding you correctly, however, since I am not > sure that you are talking about 1.3 essentially changing only the > request processor or something else. I know I don't have any > difficulty in the uptake department and find the whole discussion very > confusing and confused. Do you have a statement somewhere that you > would take to be a bit definitive. (Please don't tell me this is open > source and that anything can happen, etc.) > > <snip> > On Fri, 18 Feb 2005 08:50:02 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > One approach to building applications that is supported by Struts 1.3+ > > is to write a commons-chain based application and plug it into Struts, > > however, that is only one approach while the existing Action class > > approach still exists and will exist for a very long time. > > Personally, I favor using either MappingDispatchAction, Struts Flow, > > or a custom POJO action class ala JSF. > > > > Therefore, Joe's statement is correct. If you never messed with > > RequestProcessor, the chain-based processor implementation will not > > affect you. > </snip> > > So, from the below I understand that you have one sort of "chain" > supplanting the present request processor in order to make that > pluggable (right?) and another "chain" that will be used in the > application (model?) logic (right?). 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> > >It is kinda confusing, but the chain used for Struts is > > not the same chain that Ted was talking about, and in fact, I believe > > we are trying to separate the two to ensure a clean separation between > > Struts and application logic. > </snipo> > > > > Don > </snip> > > So, the present talk about chains vis-a-vis Ted is just some work on > applilcation logic that is essentially unrelated to Struts? Is this > right? And that is to be distinguished from "chain" talk that is > about the logic in the request processor? Is this right? It isn't unrelated to Struts, only highlighting a different approach to per-request processing ala Actions. Ted likes the idea of application logic written using commons-chains, so he and others have improved the Struts action mapping to support a chain being called instead of an Action class. Again, on the dev list, you'll find a lot of ideas and little direction. That's what you get for trying to be on the "cutting edge" :) Don > > 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]
