Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT]: PropertyContainer (aka InputModule)
Date: Fri, 20 Dec 2002 14:38:53 +0100
Message-ID: <LKENJPKDAIKAPKHEOCMMGENMCBAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3E02F8A5.6020109@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"


Nicola Ken Barozzi wrote:
> 
> Carsten Ziegeler wrote:
> > Hi,
> > 
> > to get some basis for discussion about the move of the
> > InputModules from the Cocoon.xconf to the sitemap
> > I checked in a proposal in o.a.c.sitemap.
> > 
> > I named this concept PropertyContainer (great, isn't it?)
> 
> Actually, also given the recent difficulties in naming, it's eally quite 
> good! The "property" part is IMHO to the point, I just don't like the 
> "container" part much.
> 
> What about
> 
>    PropertyAccessor
>    PropertyResolver
> 
> But given that they could also write,
> 
>    PropertyHandler
>    PropertyManager
> 
Hmm, PropertyDeliverer or PropertyProvider? From your list above I like
PropertyAccessor the most.

> 
> The new interface is different from the inputmodule one, and lacks the 
> output module part.
> 
> Why are they different?
> There is no more the capability of getting the names and values of all 
> propertis it seems.
> 
Yupp. It's not always possible to get all the names - so getting the
names does not make so much sense. For example if JXPath is used
it's useless. So instead of defining a method which is only usable in
5% of the use cases, I just left it out.


> Should we combine input and output module interfaces or define two 
> different components?
> 
> I just had a revelation! ;-)
> 
> 
> With inputmodules we finally have the simmetry between the object stuff 
>   in the environment stuff and the pipeline stuff!
> 
>     Environment     Pipeline
> 
>     inputmodule     generator
>     action          transformer
>     outputmodule    serializer
> 
> The sitemap ties them together in a request.
> The flow between requests.
> 
> Cool ;-)
> 
> > The idea is to declare the property containers in the
> > sitemap in the components section:
> > 
> > <map:property-containers>
> >    <map:property-container name="request-param"
> >                            src="o.a.c...."/>
> >    ...
> > </map:property-containers>
> 
> +1
> 
> > Chaining of containers is also customizable:
> > <map:property-containers>
> >    <map:property-container name="my-container"
> > 
> > src="o.a.c.sitemap.properties.ChainingPropertyContainer">
> >        <property-container>session</property-container/>
> >        <property-container>request</property-container/>
> >        <property-container>global</property-container/>
> >    </map:property-container>
> >    ...
> > </map:property-containers>
> 
> :-D
> 
> > The usage works like the "old" InputModules: {my-container:skin}.
> > 
> > I only added the interfaces for discussion, it's not integrated in the
> > sitemap yet.
> > 
> > What do you think?
> 
> I'm definately for it, let's define the details :-)
> 
What do you think is missing?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG


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