cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: XML input module (was: RE: Nice changes!)
Date Mon, 30 Sep 2002 11:59:06 GMT
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" <jefft@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


Mime
View raw message