cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: Input module chaining (Re: XML input module)
Date Wed, 02 Oct 2002 10:04:23 GMT
On 02.Oct.2002 -- 01:23 PM, Piroumian Konstantin wrote:
> > From: Jeff Turner [mailto:jefft@apache.org] 
> > 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
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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


Mime
View raw message