cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
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.

Okay

> 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>
<component-instance class="...SessionModule" name="session-attr">
  <input-module name="xmlconfig"/>
</component-instance>
<component-instance class="...XMLModule" name="xmlconfig">
  <config>context:///forrestconf.xml</config>
  <attribute-map from="*" to="/forrestconf/*"/>
  <input-module name="defaults"/>
</component-instance>
<component-instance class="...DefaultsMetaModule" name="defaults">
  <values>
    <skin>default-skin</skin>
  </values>
</component-instance>

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.


--Jeff

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

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


Mime
View raw message