You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2002/10/01 10:17:40 UTC
Re: XML input module (was: RE: Nice changes!)
On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> > On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > > I would prefer that module to be a "meta" module that can be
> > > > configured to take input from any source (i.e. another InputModule)
> > > > rather than do the reading itself.
> > >
> > > >From what I gather, Meta modules take in as input, a) another module, b)
> > > a configuration. In this scenario, what object would we feed JXPath?
> > > Where does the DOM come from?
> >
> > As already pointed out in others' replies, jxpath can operate on more
> > than DOM, i.e. uses reflexion to obtain the get and set methods.
> ....
> > > This might already be possible, since I think JXPath can traverse from
> > > the Session object to a DOM.
> >
> > Yes. The current request InputModule uses jxpath and allows this
> > functionality. However, I believe this is a feature that deserves to
> > be universally plugable.
>
> It is universally pluggable, only the plugin mechanism is inheritance,
> not composition. The current model is:
>
> AbstractJXPathModule .
> |---- RequestModule
> |---- SessionModule
> |---- XMLModule
> +---- ....
>
> Where each subclass just chooses what Object to let JXPath use.
>
> If I've understood you, you're proposing to change from inheritance to
> composition. Create a JXPathModule that takes as 'input', *any* other
> module:
>
> <component-instance name="jxpath" class="...JXPathModule">
> <input-module name="SessionModule"/>
> </component-instance>
Right.
>
> The JXPath module then provides XPath access to the input-module's....
> what? This is my question above. A Module's public interface doesn't
> allow access to the raw object model that JXPath needs. It's always
> pre-digested, accessible through tokens that the Module defines. For
> instance, how would the above XML snippet translate to code? How could
> XMLModule functionality be achieved?
The degree, to what they digest the data is not set to
stone. SessionModule could, for instance, just return the session
object.
If we believe that jxpath is the one and only interface that the
InputModules should expose, I'm fine with that. Then it would make
perfectly sense to make all of them inherit from
AbstractJXPathModule. Obviously, all complex ones do currently.
But what about the others. How will they fit in e.g. DateMetaInput
(parses a string and returns a java.util.Date)? 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?
> IMHO, inheritance is the way to go, with more advanced "chaining"
> functionality layered underneath, so that any subclass can automatically
> be chained.
Any automatic lookup or chaining should at least be configurable. Like
extending the DefaultsMetaModule.c
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
Input module chaining (Re: XML input module)
Posted by Jeff Turner <je...@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?
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
Re: XML input module (was: RE: Nice changes!)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 02.Oct.2002 -- 01:32 AM, Jeff Turner wrote:
> On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> > The degree, to what they digest the data is not set to
> > stone. SessionModule could, for instance, just return the session
> > object.
>
> Yes, it would have to, to accommodate the most general 'upstream' module,
> JXPath. but then you've got such a loose contract between modules as to
> be almost useless:
>
> public interface InputModule {
> Object getData();
> }
>
> At least with the current module (attributes and values), we can have
> modules like DefaultsMetaModule which can default *any* 'upstream'
> module's values.
>
> > If we believe that jxpath is the one and only interface that the
> > InputModules should expose, I'm fine with that. Then it would make
> > perfectly sense to make all of them inherit from
> > AbstractJXPathModule. Obviously, all complex ones do currently.
> >
> > But what about the others. How will they fit in e.g. DateMetaInput
> > (parses a string and returns a java.util.Date)?
>
> However it currently works. Putting the question the other way, what sort
> of inter-module data model is sufficiently general to allow JXPath on one
> hand, and DateMetaModule on the other?
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.
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?
We would need to do that before 2.0.4 since I've moved them out of
scratchpad recently.
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
Re: XML input module (was: RE: Nice changes!)
Posted by Jeff Turner <je...@apache.org>.
On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
...
> > It is universally pluggable, only the plugin mechanism is inheritance,
> > not composition. The current model is:
> >
> > AbstractJXPathModule .
> > |---- RequestModule
> > |---- SessionModule
> > |---- XMLModule
> > +---- ....
> >
> > Where each subclass just chooses what Object to let JXPath use.
> >
> > If I've understood you, you're proposing to change from inheritance to
> > composition. Create a JXPathModule that takes as 'input', *any* other
> > module:
> >
> > <component-instance name="jxpath" class="...JXPathModule">
> > <input-module name="SessionModule"/>
> > </component-instance>
>
> Right.
>
> >
> > The JXPath module then provides XPath access to the input-module's....
> > what? This is my question above. A Module's public interface doesn't
> > allow access to the raw object model that JXPath needs. It's always
> > pre-digested, accessible through tokens that the Module defines. For
> > instance, how would the above XML snippet translate to code? How could
> > XMLModule functionality be achieved?
>
> The degree, to what they digest the data is not set to
> stone. SessionModule could, for instance, just return the session
> object.
Yes, it would have to, to accommodate the most general 'upstream' module,
JXPath. but then you've got such a loose contract between modules as to
be almost useless:
public interface InputModule {
Object getData();
}
At least with the current module (attributes and values), we can have
modules like DefaultsMetaModule which can default *any* 'upstream'
module's values.
> If we believe that jxpath is the one and only interface that the
> InputModules should expose, I'm fine with that. Then it would make
> perfectly sense to make all of them inherit from
> AbstractJXPathModule. Obviously, all complex ones do currently.
>
> But what about the others. How will they fit in e.g. DateMetaInput
> (parses a string and returns a java.util.Date)?
However it currently works. Putting the question the other way, what sort
of inter-module data model is sufficiently general to allow JXPath on one
hand, and DateMetaModule on the other?
> 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.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org