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:[EMAIL PROTECTED]] > > > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote: > > > > From: "Jeff Turner" <[EMAIL PROTECTED]> > > > > (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 > [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]
