This conversation seems to be a by-product of looking at the Action classes as children of the servlet and consumers of messages instead of stand-alone entities. One intriguing way of dealing with this (IMHO) would be to consider elements as being able to "Pull" the required components out of some other area (Context?) (much like how the Turbine framework does). Instead of Chaining commands or passing a context to every execute(), you would make available a generic application infrastructure that you could pull your required components from. Really this is probably just a semantic difference as the implementation (in my mind) would probably be much the same, but, to me when you word it as something 'Pulling' something out of the Context it makes more sense (errr, I can visualize it better at least) than trying to guess what should be 'Passed' along. Comments?
-----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 5:37 PM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) Craig R. McClanahan wrote: > One of the potential problems in a Context-based environment is knowing > which keys you are using to store and retrieve stuff -- obviously, the > producer and consumer of a piece of data need to agree. It is also > important that people looking at a Command should be able to determine > what attributes will be used for what by this particular Command. > > The convention of exposing the keys that you're using seems quite helpful > in this regard, for at least two reasons: > > * It's automatically configurable in case you want to > reuse the Command implementation in a different way. > > * The fact that a "fooKey" property exists is automatically > documentation that your Command is going to utilize > a particular attribute for some purpose. And a potential problem in any Strategy-based implementation is that you don't know which of the parameters are actually used by a particular instance. For example, every Action is passed the Response, but very few every actually use it. In a framework like Struts, we can be passing some type of ActionContext that would have JavaBean properties corresponding to the "greatest-denominator" signature. So, given the properties, we'd have the same level of documentation as we do now. In implementing a Strategy-based or Context-based business layer framework, something I'm starting to look at know is the idea of building validation into the Command processing. So just as we can validate ActionForms, you might also want to validate a Context for a particular Command, using the Command's Catalog name (to use the Chain classnames) as the key. Of course, here, I'm talking about that fabled business layer framework that would live below Struts but use the same architectural patterns =:0) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
