cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Input module chaining (Re: XML input module)
Date Wed, 02 Oct 2002 09:10:37 GMT
On Tue, Oct 01, 2002 at 08:16:19PM +0200, Christian Haul wrote:
> On 02.Oct.2002 -- 01:32 AM, Jeff Turner wrote:

[snip Jeff raining on Chris's parade]
> OK, I'm almost convined. 


> > > Granted, the simple
> > > ones like NullInput (always returns "null") won't need it.
> > > 
> > > Another point may be that when switching to jxpath, would that impact
> > > the interface? Does getAttributeNames() still return a reasonable
> > > enumeration?
> > 
> > Hmm, probably not. It wouldn't make much sense to iterate through all
> > possible XPaths.
> OTOH this method is AFAIR only used to create a compabitility feature for
> migration between the two DatabaseActions. With the original ones you 
> could say values from "name*" and collapse values of parameters 
> "name1", "name2", and "namesomething" to an array.


> Since InputModules were available only in scratchpad sofar, shall we
> remove this method and agree that all InputModules need to provide an
> XPath interface? I.e. getAttribute() and getAttributeValues() accept an
> XPath expression for the parameter name?

Well there's no reason to insist on XPath, is there?

Currently we have:

public interface InputModule {
  Object getAttribute( String name, ... );
  Enumeration getAttributeNames( ... );
  Object[] getAttributeValues( String name, ... );

If getAttributeNames() is serving a purpose, then might as well keep it.
Perhaps just add a Javadoc comment, "this enumeration is not guaranteed
to contain all possible names". A loose contract is probably better than
no contract.

I think with this interface, we can still have input module chaining. It
would just be attributes that get 'chained', not whole objects. So we
could have:

<component-instance class="...RequestModule" name="request-attr"/>
  <input-module name="session-attr"/>
<component-instance class="...SessionModule" name="session-attr">
  <input-module name="xmlconfig"/>
<component-instance class="...XMLModule" name="xmlconfig">
  <attribute-map from="*" to="/forrestconf/*"/>
  <input-module name="defaults"/>
<component-instance class="...DefaultsMetaModule" name="defaults">

So if you request {request-attr:skin}, then you get:
 - the request attribute, or if not present:
 - the session attribute, or if not present:
 - the /forrestconf/skin node from forrestconf.xml, or if unavailable:
 - the 'default-skin' value.

(Btw, I reversed the defaulting order in that example, as it seems to
make more sense this way)

To implement this, we could have AbstractInputModule handle the
<input-module> tag and all the chaining, and possibly even mapping from
the requested name to the input module's native name format, which is
what <attribute-map from="*" to="/forrestconf/*"/> does.


> We would need to do that before 2.0.4 since I've moved them out of
> scratchpad recently.
> 	Chris.

To unsubscribe, e-mail:
For additional commands, email:

View raw message