You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/12/20 09:06:24 UTC
[RT]: PropertyContainer (aka InputModule)
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?)
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>
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>
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?
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
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Vadim Gritsenko wrote:
> > Sylvain Wallez wrote:
> >
[...]
>
> I see the need for the property provider functionality in the sitemap.
> Can someone give some examples for the use of a writeable property
> provider in the sitemap etc?
I've been thinking about making an LocaleModule to allow {locale:locale},
{locale:country}, etc. to be used in sitemap, so we could get rid of the
LocaleAction, but LocaleAction also handles situations when user chooses
another locale or revisits the site after a long period and locale is
retrieved from a cookie and saved in his session. Having writeable
properties could solve this problem and allow to create a LocaleModule (or
Locale[*]Property[*]).
>
> My suggestion was to make the components that are used in the sitemap
> as simple as possible and keep most parts that we already have intact.
> So I still think for the use in the sitemap, the PropertyContainer
> (PropertyProvider) approach is the simplest approach that fulfills
> all requirements (for the use in the sitemap).
IMO, Input modules are simple enough and at the same time they are quite
flexible and could be used also in transformers or actions.
Konstantin
>
> Carsten
>
> ---------------------------------------------------------------------
> 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
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>
...
>>>Someone (Chris I think) made a parallel between Modules and Sources :
>>>a source acesses (potentially) large data sets, while a module
>>>accesses smaller and discrete data.
>>>
>>>So, since we have Source, WriteableSource, TraversableSource, etc, why
>>>couldn't we have :
>>>- PropertyProvider (I like it more than "PropertyContainer")
>>>- WriteablePropertyProvider (i.e. an input/output provider)
>>>- ListablePropertyProvider (i.e. the current Module, that can list the
>>>values it provides)
>>>- ListableWriteablePropertyProvider (extends ListablePropertyProvider
>>>and WriteablePropertyProvider)
>>>
>>>And require classes used by the sitemap to implement the root
>>>PropertyProvider interface.
>>>
>>>Thoughts ?
>>>
>>>
>>Good idea. I like the shorter name of _PropertySet_ more though.
>>
>>
>>
>Ok, we already have *released* the InputModules/OutputModules. With this
>proposal from above we have to deprecate this newly introduced concept
>again.
>
>I see the need for the property provider functionality in the sitemap.
>
Could you clarify why there is a need in separate (from InputModule)
interface specifically for the sitemap?
>Can someone give some examples for the use of a writeable property
>provider in the sitemap etc?
>
Konstantin have an example with LocaleModule, same could be done with
[Request|Session]AttributeModule.
>My suggestion was to make the components that are used in the sitemap
>as simple as possible and keep most parts that we already have intact.
>
Then the best thing whould be to introduce another interface, name it
InputModule, and existing InputModule rename to ListableInputModule, or
something like this...
>So I still think for the use in the sitemap, the PropertyContainer
>(PropertyProvider) approach is the simplest approach that fulfills
>all requirements (for the use in the sitemap).
>
>
... but I still don't get why [do you think that] getAttributeNames or
getAttributeValues hurt so much.
Vadim
>Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: PropertyContainer (aka InputModule)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Sylvain Wallez wrote:
>
> [good ol' snip]
>
> > I don't see a real problem of having InputModule (or whatever their
> > names) being not fully used by the sitemap engine, and I'd like to
> > avoid the conceptual overlap between InputModules and
> PropertyContainers.
>
>
> I share this sentiment.
>
>
> > Someone (Chris I think) made a parallel between Modules and Sources :
> > a source acesses (potentially) large data sets, while a module
> > accesses smaller and discrete data.
> >
> > So, since we have Source, WriteableSource, TraversableSource, etc, why
> > couldn't we have :
> > - PropertyProvider (I like it more than "PropertyContainer")
> > - WriteablePropertyProvider (i.e. an input/output provider)
> > - ListablePropertyProvider (i.e. the current Module, that can list the
> > values it provides)
> > - ListableWriteablePropertyProvider (extends ListablePropertyProvider
> > and WriteablePropertyProvider)
> >
> > And require classes used by the sitemap to implement the root
> > PropertyProvider interface.
> >
> > Thoughts ?
>
>
> Good idea. I like the shorter name of _PropertySet_ more though.
>
Ok, we already have *released* the InputModules/OutputModules. With this
proposal from above we have to deprecate this newly introduced concept
again.
I see the need for the property provider functionality in the sitemap.
Can someone give some examples for the use of a writeable property
provider in the sitemap etc?
My suggestion was to make the components that are used in the sitemap
as simple as possible and keep most parts that we already have intact.
So I still think for the use in the sitemap, the PropertyContainer
(PropertyProvider) approach is the simplest approach that fulfills
all requirements (for the use in the sitemap).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
[good ol' snip]
> I don't see a real problem of having InputModule (or whatever their
> names) being not fully used by the sitemap engine, and I'd like to
> avoid the conceptual overlap between InputModules and PropertyContainers.
I share this sentiment.
> Someone (Chris I think) made a parallel between Modules and Sources :
> a source acesses (potentially) large data sets, while a module
> accesses smaller and discrete data.
>
> So, since we have Source, WriteableSource, TraversableSource, etc, why
> couldn't we have :
> - PropertyProvider (I like it more than "PropertyContainer")
> - WriteablePropertyProvider (i.e. an input/output provider)
> - ListablePropertyProvider (i.e. the current Module, that can list the
> values it provides)
> - ListableWriteablePropertyProvider (extends ListablePropertyProvider
> and WriteablePropertyProvider)
>
> And require classes used by the sitemap to implement the root
> PropertyProvider interface.
>
> Thoughts ?
Good idea. I like the shorter name of _PropertySet_ more though.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez 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?)
>>>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>
>>>
>>>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>
>>>
>>>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?
>>>
>>>
>>>
>>>
>>What's the real need for PropertyContainer, which looks like a
>>stripped-down version of InputModule ? Is it just a naming issue ?
>>
>>
>>
>It's both :)
>
>Ok, let's recap:
>The InputModules were not originally invented for use in the sitemap
>but as general components that could be used everywhere. Then after
>a time of being in the repository someone had the idea to add the
>access possibility to the sitemap.
>Therefore the InputModule interface is bigger than it has to be
>for the simple sitemap usage. So, I stripped it down to the really
>necessary functions (which is only one).
>
>Second, the name InputModule is not the best choice. First, of course
>it contains our favorite name part "module" which is not so good.
>And second, "Input" is in my eyes not the best description, because
>usually (in GUI libs, Operating systems etc.) an InputModule is
>something that receives events (keyboard, mouse) from the "outer world"
>and does something with this event. Our InputModule is more less
>working the other way round, it provides information.
>Therefore I thought of a better name and came across the ant properties
>which are similar to our sitemap substitution. So, I just named
>the component delivering properties, PropertyContainer.
>
>This approach has one advantage, we don't have any name collision
>with the already existing InputModules. They can still be used for the
>purpose they were originally defined for.
>
>
I don't see a real problem of having InputModule (or whatever their
names) being not fully used by the sitemap engine, and I'd like to avoid
the conceptual overlap between InputModules and PropertyContainers.
Someone (Chris I think) made a parallel between Modules and Sources : a
source acesses (potentially) large data sets, while a module accesses
smaller and discrete data.
So, since we have Source, WriteableSource, TraversableSource, etc, why
couldn't we have :
- PropertyProvider (I like it more than "PropertyContainer")
- WriteablePropertyProvider (i.e. an input/output provider)
- ListablePropertyProvider (i.e. the current Module, that can list the
values it provides)
- ListableWriteablePropertyProvider (extends ListablePropertyProvider
and WriteablePropertyProvider)
And require classes used by the sitemap to implement the root
PropertyProvider interface.
Thoughts ?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: PropertyContainer (aka InputModule)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez 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?)
> >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>
> >
> >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>
> >
> >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?
> >
> >
>
> What's the real need for PropertyContainer, which looks like a
> stripped-down version of InputModule ? Is it just a naming issue ?
>
It's both :)
Ok, let's recap:
The InputModules were not originally invented for use in the sitemap
but as general components that could be used everywhere. Then after
a time of being in the repository someone had the idea to add the
access possibility to the sitemap.
Therefore the InputModule interface is bigger than it has to be
for the simple sitemap usage. So, I stripped it down to the really
necessary functions (which is only one).
Second, the name InputModule is not the best choice. First, of course
it contains our favorite name part "module" which is not so good.
And second, "Input" is in my eyes not the best description, because
usually (in GUI libs, Operating systems etc.) an InputModule is
something that receives events (keyboard, mouse) from the "outer world"
and does something with this event. Our InputModule is more less
working the other way round, it provides information.
Therefore I thought of a better name and came across the ant properties
which are similar to our sitemap substitution. So, I just named
the component delivering properties, PropertyContainer.
This approach has one advantage, we don't have any name collision
with the already existing InputModules. They can still be used for the
purpose they were originally defined for.
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
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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?)
>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>
>
>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>
>
>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?
>
>
What's the real need for PropertyContainer, which looks like a
stripped-down version of InputModule ? Is it just a naming issue ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
<large-snip/>
>To sum up my position:
>*) InputModule is trivial enough to code to
>*) InputModule is a concept that can be used throughout the entire
> framework while the PropertyContainer is limited to the sitemap.
>*) InputModule allows to easily build a complex multiple stage
> composition of modules
>*) PropertyContainer differs not enough from InputModule to justify a
> separate interface
>*) PropertyContainer makes it difficult to compose complex PropertyContainers
>*) Adding such a similar interface only increases overall complexity
> without enough benefits
>*) All-in-all I believe we don't need it
>
>
Good analysis and nice conclusion, especially the last item ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 20.Dec.2002 -- 09:06 AM, Carsten Ziegeler wrote:
> 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.
<snip/>
Let's see how this new interface differs from InputModule, it contains
just one method:
String getProperty( String name, Map objectModel );
while InputModule contains three:
Object getAttribute( String name, Configuration modeConf, Map objectModel ) throws ConfigurationException;
Object[] getAttributeValues( String name, Configuration modeConf, Map objectModel ) throws ConfigurationException;
Iterator getAttributeNames( Configuration modeConf, Map objectModel ) throws ConfigurationException;
Actually, the PropertyContainer is a generalization of the InputModule
interface. Right, Object is not a sub type of String but since every
Object can be cast to String we could say that Object is a
specialization here.
In addition, the getProperty() method is exactly what is currently
used from the sitemap. A syntax for feeding configuration data to the
module directly from the sitemap is highly unlikely because it would
need some obscure syntax.
Retrieving multiple values getAttributeValues() is unlikely to be
needed as well. An enumeration of available properties is more
sensible: Currently, the sitemap prints out all available variables
after each change which IMO has a great educational value. OTOH this
is a loose contract since not every module actually does return a
complete set: The jxpath based modules would need to traverse the
complete object lattice which is non-trivial (not that hard, still).
The actual contract for this method is that any attribute name
obtained through this method can be fed into the getAttribute*()
methods and will return some sensible value, but there might be other
attribute names that would work as well.
It is good to remove unnecessary cruft from interfaces. Thus
PropertyContainer is a good idea.
InputModule provides these methods because I see them as a general
replacement for directly accessing the request, session &c. thus they
mimic the original interface to provide a painless migration path.
Still, the InputModule interface is IMO simple enough: it is trivial
to create any functionality that the underlying source lacks with the
one exception of the getAttributeNames() method. Since the contract is
not strict, even that is trivial most of the time.
Now, let's look at the additional Configuration object passed to the
methods of the InputModule. It is set to null when the getAttribute
method is invoked from sitemap. Or is it?
Indeed, for simple modules it is not needed. However, as soon as a
module is composed of other modules this Configuration can be
important. See this example from the PropertyContainer:
> 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>
"my-container" is composed of "session", "request", and
"global". Incidently, all three are simple containers and don't need
much configuration. Only the global container needs to be bassed
global values. If this is simple key-value, fine.
What if the global value space is organized hierarchically and in this
subsitemap we'd like to refer to only the values in this scope?
"global" could implement some mapping. Since this mapping is different
from the mapping in the parent sitemap, a new "gloabal" container
needs to be created:
<map:property-containers>
<map:property-container name="sub-global" src="......">
<file>../globals.xml</file>
<prefix>/context-name/</prefix>
</map:property-container>
<map:property-container name="my-new-container" src="o.a.c.sitemap.properties.ChainingPropertyContainer">
<property-container>session</property-container/>
<property-container>request</property-container/>
<property-container>new-global</property-container/>
</map:property-container>
<!-- the following may well be in a central place -->
<map:property-container name="session" src="......"/>
<map:property-container name="request" src="......"/>
<map:property-containers>
This is extremely verbose IMO and complexity will kill this
concept. What if it involves more than one level?
Enter Configuration.
Optionally passing a Configuration to the method allows to merge this
into one declaration:
<input-modules>
<component-instance name="my-container" src="...">
<input name="session"/>
<input name="request"/>
<input name="simple-map">
<input name="xmlfile"/>
<prefix>/context-name/</prefix>
</input>
</component-instance>
<!-- the following may well be in a central place -->
<component-instance name="session" src="..."/>
<component-instance name="request" src="..."/>
<component-instance name="simple-map" src="..."/>
<component-instance name="xmlfile" src="...">
<file>globals.xml</file>
</component-instance>
</input-modules>
This is possible, since "my-container" passes
<input name="simple-map">
<input name="xmlfile"/>
<prefix>/context-name/</prefix>
</input>
as Configuration to the "simple-map" module hoping that it will know
how to deal with this data.
This does have a drawback, however: "simple-map" needs to parse the
Configuration every time it is invoked in this context. OTOH it is not
mandatory to do it this way and tuning can be done by using the more
complex setup shown for the PropertyContainer.
To sum up my position:
*) InputModule is trivial enough to code to
*) InputModule is a concept that can be used throughout the entire
framework while the PropertyContainer is limited to the sitemap.
*) InputModule allows to easily build a complex multiple stage
composition of modules
*) PropertyContainer differs not enough from InputModule to justify a
separate interface
*) PropertyContainer makes it difficult to compose complex PropertyContainers
*) Adding such a similar interface only increases overall complexity
without enough benefits
*) All-in-all I believe we don't need it
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> 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.
PropertyAccessor is not bad. Any of the Property* names are ok for me,
but Container IMHO doesn't make it.
Just remember that they could also write values, no?
>>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.
It's logical and sensible, I'll leave to others to eventually confute
this, based on experience and need.
Personally I've worked a lot with jxpath variables in Ant files (an Ant
extension to get ptoperties via jxpath) and it works like a charm.
[...]
>>I'm definately for it, let's define the details :-)
>>
>
> What do you think is missing?
The output part, ie OutputModules.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: PropertyContainer (aka InputModule)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
Re: [RT]: PropertyContainer (aka InputModule)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
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.
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 :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org