cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: XML input module (was: RE: Nice changes!)
Date Mon, 30 Sep 2002 12:16:07 GMT
> From: Jeff Turner [mailto:jefft@apache.org] 
> On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:

<snip why="absolutely agree with a generalized meta module implementation"
/>

> 
> 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.

Yes, it can, but you should provide the object. This task is performed by
the getContextObject(), which can be implemented in a generic way to
traverse all the listed input modules in configuration to obtain the object
and then apply XPath expression to it.

> 
> > > 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.

I'd also add:
   - From a cookie (e.g. user's last selected Locale)
   - From a system property (in case of Cocoon CLI to provide the skin)

> 
> 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.

+100 for this.

KP

> 
> 
> --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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message