> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> 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?
No reason to insist, but no much problems with implementation (except for
the getAttributeNames()).
Maybe it's not needed for the most simple modules, e.g. system properties
(I've implemented it already and will commit as soon as I solve my
Internet/firewall problems), but even for this I can see a usage area for
XPath substring()-like functions, e.g.:
{system-property:concat(substring(user.name, 1, 2), substring(user.name, 2)}
>
> 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.
+1
>
> 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>
I'd better keep all the modules without chaining by default, so the users
could chaing them as they like.
>
> 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 cookie value, 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)
Yes.
>
> 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.
+1 for <input-module/> build-in handling.
+1 for attribute mapping (maybe rename it to 'map-attribute'?)
--
Konstantin
>
>
> --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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
