cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [c2] Complimentory Configuration (Was: simple sitemap question)
Date Wed, 18 Apr 2001 20:53:49 GMT
giacomo wrote:

> I've taken a deeper look into the Actions for the Employee stuff. I'd
> suggest the following:
> If the complimentary configuration you'd like to offer to an Action is
> static over its lifetime you do:
>   <map:action name="add-employee"
>               src="org.apache.cocoon.acting.DatabaseAddAction">
>     <complimentary-configuration
>         file="context://docs/samples/forms/employee.xml"/>
>   </map:action>
> in the <map:components> <map:actions> section. Then you need to make
> your Action Configurable and you receive the Configuration that way.
> If you need to pass different information to the same Action (because it
> is used in different pipelines or passed values replaced by the sitemap)
> then use the parameter like you've done in the employee samples.
> After all, my comment on the employee samples is that the Actions there
> are best extended with the Configurable interface and the complimentary
> configuration is parsed/read at instantiation time once and not for
> every invocation of the act method.
> Does this makes sense?

It makes sense, but I don't entirely like it.  Let me explain what happens:
You specify one "add-to-database" action for all forms on the system.  The
sitemap will pass the parameter to the action.  The Complimentary Configuration
engine reads the file ONCE, and converts it to a Configuration object.

Any action (extending AbstractComplimentaryConfigurableAction) that
says it needs the file receives the configuration object.  The file is
never reparsed.  There really is no overhead other than a small amount of
memory.  Using that approach, we can have one action where the mapping
file is specified by another action.

<map:act type="form-engine">
  <map:act type="add-to-database">
    <parameter name="map-file" value="{form-process}"/>

The database example isn't the best in this approach, however, specifying the
map file in the initial configuration is messy to me.

I have a process where I need to perform additions in steps.  I would rather
specify one action and pass a different configuration to it than have to specify
20 different actions (same class, different file) and have to remember what
class-type maps to what file.

The approach I used was the most usable to me.

To unsubscribe, e-mail:
For additional commands, email:

View raw message