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?). <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? If this is all correct or not, this is reallly confusing. If there is an application logic application being built that has nothing really to do with Struts, that is cool. How do people intend to discuss these things so that a reader on the lists can tell what you are talking about without having been involved in the "inner sanctum"? Thanks. (Please refrain from flames on this. I really would like to tell what is happening and am tired of the "wrestling".) 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]
