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]
