Carsten Ziegeler wrote:
Sylvain Wallez wrote: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.
Carsten Ziegeler wrote:It's both :)
Hi,What's the real need for PropertyContainer, which looks like a stripped-down version of InputModule ? Is it just a naming issue ?
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?
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.
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
