You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/02/16 04:55:10 UTC
[chain] LookupCommand's return value
I just realized that LookupCommand returns the return value of
whatever command it looks up and executes. This was
counter-intuitive to what I was trying to achieve, and, I would
argue, limited if not broken.
public boolean execute(Context context) throws Exception {
Command command = getCommand(context);
if (command != null) {
return (command.execute(context));
} else {
return (false);
}
}
As it is now, there's no way to abort a looked-up chain without
causing the base chain to also abort. It seems like this would not
always be the desired result. Specifically, in Struts, I would like
to implement a command which aborts the chain if the form is invalid
so that we can eliminate three or four repetitive tests for the same
condition in commands which follow validation. It seems like those
commands shouldn't need to know the condition; that leads to too much
coupling between the commands.
I'm sure one could reorganize the overall config so that the first
chain ended without being aborted, and then the commands which would
have come after are instead on a separate chain behind a conditional
Lookup command. This isn't that hard to do, but I'm still not sure
that I believe the class as implemented should *always* return the
value of the looked up command. Could we make a config value out of
it?
Speaking of a conditional Lookup command, I still think it might be
neat to implement that using instead of having to write Java code to
evaluate simple conditions. It could be like this:
<command className="...ConditionalLookup"
command="process-valid-form"
condition="${context.formValid or empty context.formValid}" />
<command className="...ConditionalLookup"
command="process-invalid-form"
condition="${not context.formValid}" />
This could also be used for lookups:
<command className="...ExpressionLookupCommand"
command="${context.commandName}" />
Note that these are run-time expressions, not simply config variables.
I'm just hesitant to add a new dependency on my own whim. JEXL isn't
very heavy (132 K) but I think people are keen on keeping Chain light
too.
Joe
--
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: Fwd: [chain] LookupCommand's return value
Posted by Joe Germuska <Jo...@Germuska.com>.
> > Basically, the JEXL dependency would only be a runtime dependency for
>> people who chose to use those implementations of commands which
>> depended upon it. We could have a subproject for "contrib" or
>> something, but my feeling is that that's more trouble than its worth.
>> If the binary JAR for commons-chain is readily available and the API
>> has no dependencies, then why not include useful implementations in
>> the same JAR with clear instructions on when they require auxiliary
>> libraries? Still, if people would prefer a commons-chain-contrib
>> project, I wouldn't complain; I'd just want some opinions on where
>> exactly to put it.
>
>I think the contrib thing would be overkill. I agree with you there.
>Remind me again of why your use case requires expressions? Wouldn't
>the ignoreReturn value attribute allow you to prevent the termination
>of the larger chain that the LookupCommand is contained in?
I blurred two things together; if one assumed (as I did) that
LookupCommand always returned false, then it seemed reasonable that
you might want to have a flexible way of aborting a chain which was
looked up. Writing a hard-coded class which simply tests the state
of the Context seemed less than elegant.
I have also earlier envisioned a variant of the LookupCommand which
was more dynamic in its lookup because rather than having a command
name hard-coded, it could use an expression to retrieve the command
name from the Context. You can do this to some exent using the
"nameKey" property and the CopyCommand, but I think it would be more
flexible and more elegant with expressions. A specific use case I
had thought of for this before was the idea that you might, in
Struts, define an entire catalog of commands whose names were
potential values for ActionForward.getPath(). You could then use a
lookup command to automatically invoke a command in that catalog if
one matched the path. You couldn't get this without a custom
command, because Copy can only copy an object in the Context, not a
property of an object in the Context.
Joe
--
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
Fwd: [chain] LookupCommand's return value
Posted by Sean Schofield <se...@gmail.com>.
---------- Forwarded message ----------
From: Sean Schofield <se...@gmail.com>
Date: Wed, 16 Feb 2005 09:28:55 -0500
Subject: Re: [chain] LookupCommand's return value
To: Joe Germuska <Jo...@germuska.com>
> Not changing as in breaking, but perhaps extending. What about a
> property "ignoreReturnValue" which would always return "false"
> instead of returning what the looked up command sought.
That's what I figured you meant. I have no objection to adding
another property like this.
> Well, I have zero interest in developing any other expression parser,
> so from there, I think you're limited to very crude things, like a
> bunch of properties on a command that would specify context keys and
> imply handling, like 'abortIfContextValueTrueOrNull'
I will go one further. I have *less than zero* interest in developing
another expression parser. ;-)
> Basically, the JEXL dependency would only be a runtime dependency for
> people who chose to use those implementations of commands which
> depended upon it. We could have a subproject for "contrib" or
> something, but my feeling is that that's more trouble than its worth.
> If the binary JAR for commons-chain is readily available and the API
> has no dependencies, then why not include useful implementations in
> the same JAR with clear instructions on when they require auxiliary
> libraries? Still, if people would prefer a commons-chain-contrib
> project, I wouldn't complain; I'd just want some opinions on where
> exactly to put it.
I think the contrib thing would be overkill. I agree with you there.
Remind me again of why your use case requires expressions? Wouldn't
the ignoreReturn value attribute allow you to prevent the termination
of the larger chain that the LookupCommand is contained in?
> Joe
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [chain] LookupCommand's return value
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:08 AM -0500 2/16/05, Sean Schofield wrote:
> > As it is now, there's no way to abort a looked-up chain without
>> causing the base chain to also abort. It seems like this would not
>> always be the desired result. [snip]
>
>Interesting way of thinking about it. I still think the way
>LookupCommand works now should be the default behavior.
>
>-1 on changing that (which I don't think you are really proposing)
Not changing as in breaking, but perhaps extending. What about a
property "ignoreReturnValue" which would always return "false"
instead of returning what the looked up command sought.
>[snip}
>> I'm just hesitant to add a new dependency on my own whim. JEXL isn't
>> very heavy (132 K) but I think people are keen on keeping Chain light
>> too.
>
>Keeping chain light would be nice. I don't know too much about JEXL
>personally although I will be investigating it shortly as an
>alternative to Velocity for some template stuff I have. How would you
>propose doing it if you didn't use JEXL?
>
Well, I have zero interest in developing any other expression parser,
so from there, I think you're limited to very crude things, like a
bunch of properties on a command that would specify context keys and
imply handling, like 'abortIfContextValueTrueOrNull'
Basically, the JEXL dependency would only be a runtime dependency for
people who chose to use those implementations of commands which
depended upon it. We could have a subproject for "contrib" or
something, but my feeling is that that's more trouble than its worth.
If the binary JAR for commons-chain is readily available and the API
has no dependencies, then why not include useful implementations in
the same JAR with clear instructions on when they require auxiliary
libraries? Still, if people would prefer a commons-chain-contrib
project, I wouldn't complain; I'd just want some opinions on where
exactly to put it.
Joe
--
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] LookupCommand's return value
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:11 AM -0600 2/17/05, Joe Germuska wrote:
>At 11:52 PM -0500 2/16/05, James Mitchell wrote:
>>I'm just now catching up on some of this....but I was
>>wondering.....if you configure "ignoreReturnValue" or
>>"abortIfContextValueTrueOrNull" or "whatchaMaCallit", then how
>>would you (in a looked up chain) tell the calling chain to abort
>>without having to throw an exception?
>When a command returns false, that is intended as a sign to its
>caller that it thinks it has "finished".
Whoops! The above is wrong; when a command returns *true*, that's
the sign. The second sentence (below) got it right...
>ChainBase interprets a "true" return from a command as a sign to
>stop executing the chain. It also
Joe
--
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] LookupCommand's return value
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:52 PM -0500 2/16/05, James Mitchell wrote:
>I'm just now catching up on some of this....but I was
>wondering.....if you configure "ignoreReturnValue" or
>"abortIfContextValueTrueOrNull" or "whatchaMaCallit", then how would
>you (in a looked up chain) tell the calling chain to abort without
>having to throw an exception?
When a command returns false, that is intended as a sign to its
caller that it thinks it has "finished". ChainBase interprets a
"true" return from a command as a sign to stop executing the chain.
It also returns whatever it received from the last command it
executed, so the fundamental design denies the possibility of
autonomous subchains and commands. I can see where this would
sometimes be the way you'd want it, but I think that if it's the only
way, one must configure chains relatively obtusely in order to ensure
that conditional commands never get called, or, as in Struts, one
must burden commands with more contextual knowledge than they should
have -- there's absolutely no reason an "ExecuteAction" command
should care if the form was valid or not; something else should
prevent it from being called in that case. I thought an "abort
chain" command was a good idea, but it doesn't work in the current
design. The alternative is to relegate the
"only-if-validation-passed" commands to their own sub-chain which
only gets executed if validation passed.
So for now, I think the best strategy is a variant of LookupCommand
which branches: perhaps generically implemented with a context key
name to look up a boolean value and then configured with a "true"
command, a "false" command, and perhaps a "null" command.
That one would be a lot tidier with the not-yet-released Chain
functionality to specify a catalog/command pair with a single String.
Is it time to roll a 1.0.1 (or 1.1.) commons-chain release? Is there
anything else which should maybe go in it?
Joe
--
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] LookupCommand's return value
Posted by James Mitchell <jm...@apache.org>.
I'm just now catching up on some of this....but I was wondering.....if you
configure "ignoreReturnValue" or "abortIfContextValueTrueOrNull" or
"whatchaMaCallit", then how would you (in a looked up chain) tell the
calling chain to abort without having to throw an exception?
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Craig McClanahan" <cr...@gmail.com>; "Jakarta Commons Developers
List" <co...@jakarta.apache.org>; "Sean Schofield"
<se...@gmail.com>
Sent: Wednesday, February 16, 2005 12:48 PM
Subject: Re: [chain] LookupCommand's return value
> At 9:23 AM -0800 2/16/05, Craig McClanahan wrote:
>>On Wed, 16 Feb 2005 08:08:14 -0500, Sean Schofield
>><se...@gmail.com> wrote:
>>> > I'm just hesitant to add a new dependency on my own whim. JEXL isn't
>>> > very heavy (132 K) but I think people are keen on keeping Chain light
>>> > too.
>>>
>>> Keeping chain light would be nice. I don't know too much about JEXL
>>> personally although I will be investigating it shortly as an
>>> alternative to Velocity for some template stuff I have. How would you
>>> propose doing it if you didn't use JEXL?
>>>
>>> > Joe
>>
>>Digester has some limited parameter substitution capabilities that
>>could be applied when the chain configuration is being parsed. Is
>>that enough to satisfy the kinds of things you're thinking of that
>>might want expressions?
>
> I don't think so, since I'm specifically interested in runtime state. "Is
> the ActionForm in *this* context valid?" "Look up the command with the
> name matching the value of the 'path' property of the current
> ForwardConfig." "Look up and execute a command only if the current value
> of context property "unitsOrdered" is greater than 1000."
>
> Again, for some or all of these, one could probably manage with judicious
> use of CopyCommand and LookupCommand, possibly augmented by some very
> simple compiled Java commands which might have properties for some
> configurability.
>
> If there's hesitation to formally add any external dependency to the
> project, then when I get around to writing some of these, I'll just put
> them up somewhere and invite people to have a look. If people don't feel
> that a compile-time dependency on JEXL (which is small and which has seen
> a 1.0 release) is too great a burden, then I'll do them directly in the
> repository in a package which clearly separates them from the
> dependency-free classes (org.apache.commons.chain.impl.expr or
> org.apache.commons.chain.impl.jexl).
>
> Joe
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [chain] LookupCommand's return value
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:23 AM -0800 2/16/05, Craig McClanahan wrote:
>On Wed, 16 Feb 2005 08:08:14 -0500, Sean Schofield
><se...@gmail.com> wrote:
>> > I'm just hesitant to add a new dependency on my own whim. JEXL isn't
>> > very heavy (132 K) but I think people are keen on keeping Chain light
>> > too.
>>
>> Keeping chain light would be nice. I don't know too much about JEXL
>> personally although I will be investigating it shortly as an
>> alternative to Velocity for some template stuff I have. How would you
>> propose doing it if you didn't use JEXL?
>>
>> > Joe
>
>Digester has some limited parameter substitution capabilities that
>could be applied when the chain configuration is being parsed. Is
>that enough to satisfy the kinds of things you're thinking of that
>might want expressions?
I don't think so, since I'm specifically interested in runtime state.
"Is the ActionForm in *this* context valid?" "Look up the command
with the name matching the value of the 'path' property of the
current ForwardConfig." "Look up and execute a command only if the
current value of context property "unitsOrdered" is greater than
1000."
Again, for some or all of these, one could probably manage with
judicious use of CopyCommand and LookupCommand, possibly augmented by
some very simple compiled Java commands which might have properties
for some configurability.
If there's hesitation to formally add any external dependency to the
project, then when I get around to writing some of these, I'll just
put them up somewhere and invite people to have a look. If people
don't feel that a compile-time dependency on JEXL (which is small and
which has seen a 1.0 release) is too great a burden, then I'll do
them directly in the repository in a package which clearly separates
them from the dependency-free classes
(org.apache.commons.chain.impl.expr or
org.apache.commons.chain.impl.jexl).
Joe
--
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] LookupCommand's return value
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 16 Feb 2005 08:08:14 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > I'm just hesitant to add a new dependency on my own whim. JEXL isn't
> > very heavy (132 K) but I think people are keen on keeping Chain light
> > too.
>
> Keeping chain light would be nice. I don't know too much about JEXL
> personally although I will be investigating it shortly as an
> alternative to Velocity for some template stuff I have. How would you
> propose doing it if you didn't use JEXL?
>
> > Joe
Digester has some limited parameter substitution capabilities that
could be applied when the chain configuration is being parsed. Is
that enough to satisfy the kinds of things you're thinking of that
might want expressions?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [chain] LookupCommand's return value
Posted by Sean Schofield <se...@gmail.com>.
> As it is now, there's no way to abort a looked-up chain without
> causing the base chain to also abort. It seems like this would not
> always be the desired result. [snip]
Interesting way of thinking about it. I still think the way
LookupCommand works now should be the default behavior.
-1 on changing that (which I don't think you are really proposing)
> I'm sure one could reorganize the overall config so that the first
> chain ended without being aborted, and then the commands which would
> have come after are instead on a separate chain behind a conditional
> Lookup command. This isn't that hard to do, but I'm still not sure
> that I believe the class as implemented should *always* return the
> value of the looked up command. Could we make a config value out of
> it?
Right now I am indifferent but as soon as I encounter a similar use
case in my own programming I am sure I will be +1 ;-)
[snip}
> I'm just hesitant to add a new dependency on my own whim. JEXL isn't
> very heavy (132 K) but I think people are keen on keeping Chain light
> too.
Keeping chain light would be nice. I don't know too much about JEXL
personally although I will be investigating it shortly as an
alternative to Velocity for some template stuff I have. How would you
propose doing it if you didn't use JEXL?
> Joe
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org