On Tue, 12 Aug 2003, Mainguy, Mike wrote: > Date: Tue, 12 Aug 2003 18:03:14 -0400 > From: "Mainguy, Mike" <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: 'Struts Developers List' <[EMAIL PROTECTED]> > Subject: RE: ActionForwards, et al (was SuccessAction) > > 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? >
Doesn't "pulling" something from some application infrastructure imply that somebody else "pushed" it into that infrastructure? For example, if you expect to find the HttpServletRequest object in there, presumably the controller must have seeded that content. It's also perfectly reasonable for one Command in a Chain (in commons-sandbox/chain terms) to push something into the Context that another Command executed later will need. In terms of making the infrastructure available to callers, it's pretty clear how passing a context object around makes the infrastructure available to anyone who needs it. Are there other options for how you'd make the infrastructure available without passing it? I haven't thought of any. Craig > -----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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
