> From: Christian Haul [mailto:[EMAIL PROTECTED]] > 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. > > That way it would be possible to apply the XPath expression > e.g to a bean or document stored as session attribute.
Yes, this would be much better. So, what about extending AbstractJXPathModule to say AbstractJXPathMetaModule which can implement the getContextObject() using configured input modules to obtain the object to be processed by the JXPath processor? Maybe even some AbstractMetaModule would be better (not only JXPath based)? > > > 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. Yes. > > > > > > 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"? Sorry, don't quite get what is "null"? The exception 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. > > +1 Fine! Konstantin > > > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
