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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
