You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mattias J <mj...@expertsystem.se> on 2005/05/13 14:25:16 UTC
[chain] Pre-conditions
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?
/Mattias J
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [chain] Pre-conditions
Posted by Joe Germuska <Jo...@Germuska.com>.
While I've used an "checkPreconditions" type approach in some of my
Command implementations, I'm not sure I feel like I've got anything
I'd want to codify as "best practices" in formal interfaces in
commons-chain.
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
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [chain] Pre-conditions
Posted by Joe Germuska <Jo...@Germuska.com>.
While I've used an "checkPreconditions" type approach in some of my
Command implementations, I'm not sure I feel like I've got anything
I'd want to codify as "best practices" in formal interfaces in
commons-chain.
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
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org