commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hale Boyes, Kevin " <Kevin.HaleBo...@encana.com>
Subject RE: [Chain] Parametizing commands?
Date Wed, 10 Sep 2008 14:22:18 GMT
I would be interested in seeing the source.  I'm just finishing a
project
where I used commons-chain so I might not use it immediately but it is
such a powerful library that I'm sure I'll be back to it.

K.

-----Original Message-----
From: Peter_Ford@blm.gov [mailto:Peter_Ford@blm.gov] 
Sent: Tuesday, September 09, 2008 2:20 PM
To: Commons Users List
Cc: Commons Users List
Subject: Re: [Chain] Parametizing commands?

It turns out that (as you probably know) it is possible to parametize
commands in the catalog XML file. (I should point out that the
documentation of the format of the XML file is either missing or in a
hard-to-find place; I couldn't find it and had to resort to pulling the
Digester rules apart to figure this out).

In any case, this means that it's possible to do what I was asking - but
it's not necessarily easy, so I've written a package to make this kind
of
thing a whole lot simpler. The core class is an abstract class that
allows
you to initialize mappings from the key names used in the code, to the
actual names used to access the context. In this way you can write
easily-reusable commands and provide the mappings in the XML.

In addition it supports hierarchies of contexts to make it easier to
keep
complex structures organized, and like the keys the contexts can be
mapped
to simple names.

I've been testing it and it shows a lot of promise; I'd like to submit
the
code for consideration for inclusion in a future release of
Commons-Chain
but I have no idea how to go about that; however I can email a source
JAR
if anyone's interested.

--Pete

"Niall Pemberton" <niall.pemberton@gmail.com> wrote on 09/05/2008
06:57:31
PM:

> On Fri, Sep 5, 2008 at 5:49 PM,  <Peter_Ford@blm.gov> wrote:
> >
> > I'm looking for a way to decouple the context keys used in a command
from
> > the actual context keys used at runtime. Here's an example:
> >
> > Here's a really simple command  that just concatenates two strings
from
the
> > context - the keys are A and B and the concatenated output goes in
C:
> >
> > public class Concat implements Command
> > {
> >    @Override
> >    public boolean execute(Context context) throws Exception
> >    {
> >        context.put("C", (String) context.get("A") + (String)
> > context.get("B"));
> >        return false;
> >    }
> > }
> >
> > Let's say I need to create a chain that uses this command, but the
other
> > commands leading up to this one leave the two strings that need to
be
> > joined the context under the keys FIRST_NAME and LAST_NAME, and the
result
> > is expected to be in FULL_NAME for the next step in processing. So
now
I
> > have to create two more commands: one to move FIRST_NAME to A and
LAST_NAME
> > to B, so that the strings are in the right places for my Concat
command,
> > and then another to follow that moves C to LAST_NAME.
> >
> > That's not very nice - I now have three commands to do the job of
one.
If I
> > need to use Concat somewhere else but using different keys again
(combining
> > DIRECTORY and FILE to create PATH, say) I have to create yet more
commands
> > just to move things around so that I can re-use the command that
does
the
> > actual work. And in fact in the application I've been developing
something
> > like a third of the commands in the app are just to do this kind of
> > data-shuffling, and I have command chains that are twice as long as
they
> > really should be.
> >
> > What I'd like to be able to do is provide some kind of mapping from
the
> > "label" keys used by my command code, to the "real" keys that get
used
at
> > runtime. As an example, I might want to represent my chain something
like
> > this in XML:
> >
> >  <command name="Concat">
> >    <map label="A" to="FIRST_NAME" />
> >    <map label="B" to="LAST_NAME" />
> >    <map label="C" to="FULL_NAME" />
> >  </command>
> >  <command name="Concat">
> >    <map label="A" to="DIRECTORY" />
> >    <map label="B" to="FILE" />
> >    <map label="C" to="PATH" />
> >  </command>
> >
> > I could do this myself *if* there was a way to parametize individual
> > command references in a chain something like this, but as far as I
can
tell
> > there is no such option in Chain as it is right now.
>
> The sample webapp(s) has an example of exactly this - theres an
> example "forward" command where the actual forward is specified as a
> property:
>
> http://svn.apache.
>
org/repos/asf/commons/proper/chain/trunk/apps/example1/src/main/java/org
/apache/commons/chain/apps/example/ForwardCommand.

> java
>
> Then in the chain config you specify the fowards property:
>
> http://svn.apache.
>
org/repos/asf/commons/proper/chain/trunk/apps/example1/src/main/webapp/W
EB-
> INF/chain-config.xml
>
> Niall
>
> > It strikes me, having used Chain for a while, that I am probably not
the
> > only one to have come across the general problem of having "fixed"
keys
in
> > Commands referring to "movable" data in Contexts. What I've
described
here
> > is a potential solution but I don't think it'll work because Chain
doesn't
> > support being able to attach parameter sets to Command references.
Is
there
> > another solution out there?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


This email communication and any files transmitted with it may contain confidential and or
proprietary information and is provided for the use of the intended recipient only. Any review,
retransmission or dissemination of this information by anyone other than the intended recipient
is prohibited.  If you receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you. 
http://www.encana.com



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message