Return-Path: 
 <cocoon-dev-return-12602-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 68558 invoked by uid 500); 18 Apr 2001 20:16:05 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 68466 invoked from network); 18 Apr 2001 20:15:53 -0000
Date: Wed, 18 Apr 2001 22:05:29 +0200 (CEST)
From: giacomo <giacomo@apache.org>
X-X-Sender: <giacomo@lap1.otego.com>
To: <cocoon-dev@xml.apache.org>
Subject: Re: [c2] simple sitemap question
In-Reply-To: <3ADDD100.B3438103@apache.org>
Message-ID: <Pine.LNX.4.31.0104182149450.1375-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N



On Wed, 18 Apr 2001, Berin Loritsch wrote:

> giacomo wrote:
> >
> > On Wed, 18 Apr 2001, Berin Loritsch wrote:
> >
> > > giacomo wrote:
> > > >
> > > > On Tue, 17 Apr 2001, Donald Ball wrote:
> > > >
> > > > > On Mon, 16 Apr 2001, Berin Loritsch wrote:
> > > > >
> > > > > > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > > > > > is used when you have a Configuration file that you want to load separately
> > > > > > from the Sitemap.  The Sitemap configuration is not flexible enough for
> > > > > > some Actions that need structured configurations like the {xxx}DatabaseActions
> > > > > > and the convenience of the Parameters.  Since Cocoon doesn't pass Configuration
> > > > > > objects,
> > > >
> > > > If I look into the sitemap.xsl Actions where configured like all other
> > > > sitemap components. Why do you say Actions don't get passed
> > > > Configuration objects?
> > >
> > > I am refering to <map:act> sections in the pipeline or action sets.
> > > Once the thing is originally configured, it can't have context dependant
> > > configurations.  Example:
> > >
> > > One action acts the same no matter where you use it.
> > > You have context dependant mapping info that can't be expressed in Parameters.
> > > Now you have to do one of two things:
> > >
> > > 1) Create a new instance of the action for all cases--not very flexible,
> > >    and it forces the sitemap to explicitly add 20 different declarations
> > >    for the same component.
> > > 2) Use this action, and specify an ancilliary configuration class that adds
> > >    the context dependant information.
> > >
> > >
> > > Basically what I am saying is that Actions are not passed Configuration objects
> > > at _run_time_.
> >
> > I think I've really missed something. None of the sitemap components
> > gets passed Configuration objects at _run_time_. It's the same for all.
> > But you can pass Parameters as with all other SitemapComponents. So
> > Actions are (at least I thought I have implemented them that way)
> > treaded as any other SitemapComponent. It's adifferent case with
> > action-sets. Well, for them we haven't really specified how they should
> > be handeled by the sitemap engine.
>
> You are correct.  The Action is a sitemap component that gets a Parameters
> object during runtime.  Sometimes the runtime context information can't
> be easily or properly stated with simple name/value pairs.  For instance,
> the DatabaseActions (that's why they have the complementary configuration).
> There is a three way mapping:
>
> Form Name, Type, Table Column Name
>
> The configuration file can also be further augmented so that you can easily
> put constraints on the form params:
>
> <advertisement>
>   <keys>
>     <key parameter="id" type="int" column="adId" mode="auto"/>
>   </keys>
>   <values>
>     <value parameter="name" type="string" column="title">
>       <constraint nullable="false" min-length="3" max-length="32"/>
>     </value>
>   </values>
> </advertisement>

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?

Giacomo

>
> This allows a number of different Actions act on the same configuration
> information (not included in the sitemap):
>
> Add/Update/Delete actions worry about the mapping
> Validator actions worry about the constraints
>
> When you have a complimentary configuration, then it makes this approach
> easier than repeating the configuration information for each Action
> involved in the system.
>
> Really, the AbstractComplimentaryConfiguration object has a definite need
> and roll--though not all Actions require this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org