On 02.Oct.2002 -- 01:23 PM, Piroumian Konstantin wrote:
> > 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)}
BTW is there an easy way to add functions? (too lazy to read jxpath
docs :-)
> > 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
+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">
<!-- how about this: -->
<input type="request-attr" priority="2"/>
<input type="session-attr" priority="1"/>
<input type="xmlconfig" priority="0"/>
> > <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.
The idea of meta modules was to provide functions that may apply to
different sources. Like read a string and convert it to a
java.util.Date or access a java.util.Map entry (easily replacable with
the jxpath support in attributes)
This is the same discussion as with the jxpath. Should it be inherited
or composed. Since I belive this should be configurable by the user
(no reason not to have a number of different configurations for a
site!) I would vote for composition.
In addition I believe that it stays simpler to write custom
modules. Which should be a design goal.
> > 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 <input-module/> build-in handling.
+1 for doing chaining in the DefaultsMetaModule
> +1 for attribute mapping (maybe rename it to 'map-attribute'?)
+1 for attribute mapping ("map-attribute" confuses because of "map:attribute"?)
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]
