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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
