You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Piroumian Konstantin <KP...@protek.com> on 2002/09/30 12:06:35 UTC
XML input module (was: RE: Nice changes!)
> From: Jeff Turner [mailto:jefft@apache.org]
> On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote:
> > From: "Jeff Turner" <je...@apache.org>
(cross-posting to cocoon-dev, cause it concerns more Cocoon than Forrest)
> ...
> > > So if, in cocoon.xconf, it is declared with:
> > >
> > > <component-instance
> > > class="org.apache.cocoon.components.modules.input.XMLModule"
> > > logger="core.modules.xml" name="forrestconf">
> > > <config>context://forrestconf.xml</config>
> > > </component-instance>
> > >
> > > Then the XML file's values are accessible through variables like
> > > {forrestconf:/forrestconf/skin}.
> >
> > Cool!
> > I was thinking about XMLModule exactly this way. If it's
> ready then I
> > can commit it to Cocoon on Monday. It can be useful not only for
> > Forrest.
>
> I've submitted this at:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131
Cool!
I've assigned the patch to myself and posted a comment on Ugo's suggestion.
Regarding the caching of sources, it is definitely needed. Maybe XSP
processing part will provide some hints on how to implement it correctly in
Cocoon's way.
>
> > > Also, it is possible to use the XML file as input to the
> > > DefaultsMetaModule:
> ...
> > > It's still a bit buggy though, because if the XML file
> doesn't exist
> > > I get an exception.
> >
> > What do you expect to do if the XML file doesn't exist? I
> think that
> > having an exception in that case is the best handling. Of course if
> > the xception has a meaningful message.
>
> I think the problem is that DefaultsMetaModule assumes every
> variable 'key' can be represented as an XML element name:
>
> <values>
> <skin>defaultSkin</skin>
> <base-url>http://localhost:8080/cocoon</base-url>
> </values>
>
> Here, the keys are 'skin' and 'base-url'. What happens if the
> key is an XPath expression like '/forrestconf/skin'? Might be
> a good idea to support an alternative format:
>
> <values>
> <value key="/forrestconf/skin">forrest-site</value>
> <value key="/forrestconf/base-url">/forrest</value>
> </values>
>
> Hmm. I can code it up if you think it's a good solution.
I'd change it to:
<attributes>
<attribute name="/forrestconf/skin">forrest-site</attribute>
<attribute name="/forrestconf/base-url">/forrest</attribute>
</attributes>
- this will be in accordance with the InputModule interface.
Konstantin
>
> > > Anyway, does this sound like the right road to be following?
> >
> > Definitely.
>
> Good stuff
>
> --Jeff
>
> > Konstantin
> >
> > >
> > >
> > > --Jeff
> > >
> > > > Regards,
> > > > Konstantin
> > > >
> > > > _________________________________________
> > > > Konstantin Piroumian
> > > > ICQ#: 2297575
> > > > * More ways to contact me <http://wwp.icq.com/2297575>
> > > > i See more about me
> > > > <http://web.icq.com/whitepages/about_me?Uin=2297575>
> > > > _________________________________________
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
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
Re: XML input module (was: RE: Nice changes!)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
Re: XML input module (was: RE: Nice changes!)
Posted by Jeff Turner <je...@apache.org>.
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>
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?
IMHO, inheritance is the way to go, with more advanced "chaining"
functionality layered underneath, so that any subclass can automatically
be chained.
--Jeff
> 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 Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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.
> I was thinking it's the other way round; DefaultMetaModule needs
> generalizing, in order to be able to 'default' arbitrary input modules,
> including XMLModule. Currently, it can only 'default' those with keys
> expressible as XML element names. That's what the proposed syntax below
> achieves.
Right, it's actually only a proof-of-concept module, more advanced
mechanics are imagninable and - it appears - desirable.
> > or document stored as session attribute.
>
> 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.
> > > Regarding the caching of sources, it is definitely needed. Maybe XSP
> > > processing part will provide some hints on how to implement it correctly in
> > > Cocoon's way.
> >
> > Wich would then become the task of the module that is used to obtain
> > the data. For a session attribute it would not be needed, for example.
>
> Hmm.. thinking at a tangent...
>
> Often, one wants a variable's value to come from one of a number of
> sources, ordered by preference:
>
> - From a request value, or if not present,
> - From a session value, or if not present,
> - From an XML config file or database.
To this I would suggest to have a module that does exactly this, along
the lines of the current DefaultsMetaModule. Just that it takes a
configurable list of modules to test. I hope that it's still not FS ;-)
> This is the situation in Forrest; we want to specify a skin in an XML
> config file, but allow it to be overridden for a user's session, and
> optionally overridden by a request param.
>
> Perhaps the idea of "meta" modules can be generalized to that of
> "chained" modules? Each module type just worries about resolving what it
> knows about, and lets some underlying machinery do the defaulting to
> whatever's next in the chain.
Yes. That's the idea of the prototype DefaultsMetaModule. Just that it
stops with one alternative.
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 Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> On 30.Sep.2002 -- 02:06 PM, Piroumian Konstantin wrote:
> > > From: Jeff Turner [mailto:jefft@apache.org]
> > > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote:
> > > > From: "Jeff Turner" <je...@apache.org>
> >
> > (cross-posting to cocoon-dev, cause it concerns more Cocoon than Forrest)
> >
> > > ...
> > > > > So if, in cocoon.xconf, it is declared with:
> > > > >
> > > > > <component-instance
> > > > > class="org.apache.cocoon.components.modules.input.XMLModule"
> > > > > logger="core.modules.xml" name="forrestconf">
> > > > > <config>context://forrestconf.xml</config>
> > > > > </component-instance>
> > > > >
> > > > > Then the XML file's values are accessible through variables like
> > > > > {forrestconf:/forrestconf/skin}.
> > > >
> > > > Cool!
> > > > I was thinking about XMLModule exactly this way. If it's
> > > ready then I
> > > > can commit it to Cocoon on Monday. It can be useful not only for
> > > > Forrest.
> > >
> > > I've submitted this at:
> > >
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131
> >
> > Cool!
> >
> > I've assigned the patch to myself and posted a comment on Ugo's suggestion.
>
> I've not yet looked at the code so take my comments with a grain of
> salt. (And as I'm not subscribed to the forrest list, haven't seen any
> comments)
>
> 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?
I was thinking it's the other way round; DefaultMetaModule needs
generalizing, in order to be able to 'default' arbitrary input modules,
including XMLModule. Currently, it can only 'default' those with keys
expressible as XML element names. That's what the proposed syntax below
achieves.
> That way it would be possible to apply the XPath expression e.g to a
> bean
That would be nifty.
> or document stored as session attribute.
This might already be possible, since I think JXPath can traverse from
the Session object to a DOM.
> > Regarding the caching of sources, it is definitely needed. Maybe XSP
> > processing part will provide some hints on how to implement it correctly in
> > Cocoon's way.
>
> Wich would then become the task of the module that is used to obtain
> the data. For a session attribute it would not be needed, for example.
Hmm.. thinking at a tangent...
Often, one wants a variable's value to come from one of a number of
sources, ordered by preference:
- From a request value, or if not present,
- From a session value, or if not present,
- From an XML config file or database.
This is the situation in Forrest; we want to specify a skin in an XML
config file, but allow it to be overridden for a user's session, and
optionally overridden by a request param.
Perhaps the idea of "meta" modules can be generalized to that of
"chained" modules? Each module type just worries about resolving what it
knows about, and lets some underlying machinery do the defaulting to
whatever's next in the chain.
--Jeff
...
[The proposed extended DefaultsMetaModule syntax:]
> >
> > <attributes>
> > <attribute name="/forrestconf/skin">forrest-site</attribute>
> > <attribute name="/forrestconf/base-url">/forrest</attribute>
> > </attributes>
> >
> > - this will be in accordance with the InputModule interface.
>
> +1
>
> > > > > Anyway, does this sound like the right road to be following?
> > > >
> > > > Definitely.
> > >
> > > Good stuff
>
> +1
>
> 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 Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 30.Sep.2002 -- 02:06 PM, Piroumian Konstantin wrote:
> > From: Jeff Turner [mailto:jefft@apache.org]
> > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote:
> > > From: "Jeff Turner" <je...@apache.org>
>
> (cross-posting to cocoon-dev, cause it concerns more Cocoon than Forrest)
>
> > ...
> > > > So if, in cocoon.xconf, it is declared with:
> > > >
> > > > <component-instance
> > > > class="org.apache.cocoon.components.modules.input.XMLModule"
> > > > logger="core.modules.xml" name="forrestconf">
> > > > <config>context://forrestconf.xml</config>
> > > > </component-instance>
> > > >
> > > > Then the XML file's values are accessible through variables like
> > > > {forrestconf:/forrestconf/skin}.
> > >
> > > Cool!
> > > I was thinking about XMLModule exactly this way. If it's
> > ready then I
> > > can commit it to Cocoon on Monday. It can be useful not only for
> > > Forrest.
> >
> > I've submitted this at:
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13131
>
> Cool!
>
> I've assigned the patch to myself and posted a comment on Ugo's suggestion.
I've not yet looked at the code so take my comments with a grain of
salt. (And as I'm not subscribed to the forrest list, haven't seen any
comments)
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.
That way it would be possible to apply the XPath expression e.g to a
bean or document stored as session attribute.
> Regarding the caching of sources, it is definitely needed. Maybe XSP
> processing part will provide some hints on how to implement it correctly in
> Cocoon's way.
Wich would then become the task of the module that is used to obtain
the data. For a session attribute it would not be needed, for example.
> > > > Also, it is possible to use the XML file as input to the
> > > > DefaultsMetaModule:
> > ...
> > > > It's still a bit buggy though, because if the XML file
> > doesn't exist
> > > > I get an exception.
> > >
> > > What do you expect to do if the XML file doesn't exist? I
> > think that
> > > having an exception in that case is the best handling. Of course if
> > > the xception has a meaningful message.
What about "null"?
> > I think the problem is that DefaultsMetaModule assumes every
> > variable 'key' can be represented as an XML element name:
> >
> > <values>
> > <skin>defaultSkin</skin>
> > <base-url>http://localhost:8080/cocoon</base-url>
> > </values>
> >
> > Here, the keys are 'skin' and 'base-url'. What happens if the
> > key is an XPath expression like '/forrestconf/skin'? Might be
> > a good idea to support an alternative format:
> >
> > <values>
> > <value key="/forrestconf/skin">forrest-site</value>
> > <value key="/forrestconf/base-url">/forrest</value>
> > </values>
> >
> > Hmm. I can code it up if you think it's a good solution.
>
> I'd change it to:
>
> <attributes>
> <attribute name="/forrestconf/skin">forrest-site</attribute>
> <attribute name="/forrestconf/base-url">/forrest</attribute>
> </attributes>
>
> - this will be in accordance with the InputModule interface.
+1
> > > > Anyway, does this sound like the right road to be following?
> > >
> > > Definitely.
> >
> > Good stuff
+1
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