Return-Path: 
 <cocoon-dev-return-31488-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 76044 invoked by uid 500); 30 Sep 2002 11:38:39 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 75963 invoked from network); 30 Sep 2002 11:38:36 -0000
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9875BF94@postman.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: XML input module (was: RE: Nice changes!)
Date: Mon, 30 Sep 2002 15:38:39 +0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Christian Haul [mailto:haul@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" <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.
> 
> 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
> 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