However, when you suggest annotations, I think that sounds pretty interesting and like the right general approach, except that I'm not ready to bind commons-chain to Java 5.0 yet. As you describe it, though, one could simply create a deluxe version of a Catalog and/or a Chain which enforced those checks. That seems pretty interesting.
Since we're talking about Chain and futures, here are the two things I'm seeing as most interesting directions for improvement:
1) make sure that there are no dependencies on the Digester-based bootstrapping. The more I use the Spring framework, the more I want my chains to be able to have their dependencies injected. I recently made some commits that rearrange all calls to "CatalogFactory.getInstance()" so that they are only used as a fallback, but that there's always a way to set the CatalogFactory as a bean property (for example, for a LookupCommand). There may not be a whole lot more work to do here, except for one thing -- as much as I like Spring, I find the XML syntax verbose compared to Digester based syntax. I've spent a little time trying to figure out how to make a Spring BeanFactory which could somehow read from Digester but also handle dependency injection, but I haven't had a whole lot of time to get into it. However, verbose or not, it's entirely possible to make commands, chains, and even catalogs in a Spring beans XML file, which is a nice alternative.
2) Figure out a way to decorate chains without copying their configuration. Most of my chain work is in the context of Struts, where there's a "standard" chain included in the distribution for 1.3 (as yet unreleased). However, I am always making a few changes to that chain -- it would be nice to be able to apply commands in the way that you can apply "preGoal" and "postGoal" behavior in Maven. (You could also think of it as an "aspect-oriented" problem.) I haven't spent too much time thinking about this, but partly because I haven't had any ideas that seemed promising to pursue.
Sorry to hijack your thread, but now that Chain is pretty stable, it seems like a decent time to solicit more ideas for the next steps.
Joe
At 2:25 PM +0200 5/13/05, Mattias J wrote:
I have just started using Jakarta Chains to refactor and evolve an existing project. I've had thoughts around this for a long time, and finally got around to it. When actually working with this API/pattern, a few questions come to mind, mostly related to the dependencies between different Commands in a Chain.
The post-conditions of a Command should of course be checked using unit tests. But what is the best practice for handling pre-conditions (i.e. context must be of type MyContext, context must contain value for key "myKey", value for "myKey" must be of type MyClass)?
Naturally pre-conditions should be documented in the JavaDoc of the Command implementation, but this is not always the best for mainainability and debugging.
- Should all possible Chain combinations be unit tested?
- Or would it be an idea to create a sub interface to Command to add, say, checkPreConditions()?
This could of course done using AOP and configuring aspects via annotations, for example
@ContextType(MyContext.class)
@RequiredKey("myKey")
@ValueType("myKey", MyClass.class)
- Or maybe one could elaborate this even further, creating rule object sets returned by Commands as pre-conditions and post-conditions, so that a Chain would be responsible of making sure the different Commands are compatible when added using addCommand()...?
Does anyone else have any thoughts about this?
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
