cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stevens" <>
Subject Re: Dynamic configuration of input modules, and the XMLFileModule
Date Fri, 05 May 2006 10:42:28 GMT
>From: Ellis Pritchard <>
>Date: Fri, 5 May 2006 08:20:46 +0100
>The LinkRewritingTransformer might be your thing, but given that you  are 
>using map:redirect, I suspect that it isn't. You could sub-class  
>XMLFileModule to dynamically provide the configuration you need via  
>modeConf (LinkRewritingTransformer provides the configuration this way).

Oh.  I figured it was the other side of things that needed adapting.  So far 
as I can see, XMLFileModule can already take its configuration via modeConf, 
inasmuch as there's a modeConf parameter to the getAttribute methods and it 
does appear to do something with it (looking for a file child element in 
getDocument).  The problem I have is how to get something passed into the 
modeConf from my map:redirect-to and/or sitemap, as that appears to be 
specific to each sitemap component.

Judging by the linkrewriter transformer javadocs[1], that looks for 
input-module elements inside the map:transformer, and passes their contents 
to the relevant module as the modeConf.  Whether that's a general thing for 
all transformers or specific to that one I'm not sure (though I suspect the 
latter, since other transformers may not need to use an input module in the 
same way).  The global input module appears to be supplied with dynamic 
configuration from the global-variables element in the 
map:component-configurations part of the sitemap, presumably by the sitemap 
tree processor?

As for the map:redirect-to entries, I've no idea if or how those might do 
it.  redirect-to appears to be merely a treeprocessor ProcessingNode rather 
than PipelineEventComponentProcessingNode, and I don't see anything in its 
invoke method that would do dynamic input module configuration prior to the 
URI resolution.

Am I missing something, or is the only way to configure the xmlfile input 
module for use in my map:redirect-to to put it in the cocoon.xconf?  Or is 
there somewhere else in the sitemap I can configure it? (e.g. something 
under map:components or map:component-configurations?)

Asides from trying to configure the module closer to where I'm using it, 
I've managed to solve the rest of my problem for now.  Rather than messing 
around with the directory generator, [x|c]include transformer and xsl to 
combine the files, I used the xpathdirectory generator.  Much neater; the 
whole thing now just has

		<map:pipeline internal-only="true">
			<map:match pattern="external_links">
				<map:generate type="xpathdirectory" src="link_data">
					<map:parameter name="xpath" value="/link/href"/>
				<map:serialize type="xml"/>
			<map:match pattern="goto/*">
				<map:act type="resource-exists" src="link_data/{1}">
					<map:redirect-to uri="{xmlfile://href[../../@name = '{../1}']}"/>

in the sitemap, and

logger="core.modules.xml" name="xmlfile">
        <file src="cocoon://external_links"/>

in cocoon.xconf.  If I could just shift the configuration to the sitemap so 
I can reuse it with different directories/pipelines in different places, 
it'd be even better :-)



>You need to override the getAttribute() method, and create a  
>DefaultConfiguration object with an element of 'file' and a 'src'  
>attribute with the URI of the XML file to read; your suggested  xpointer 
>syntax is nice (although my own version didn't bother with  that, and just 
>used a fragment identifier to separate the URI and the  XPath).
>i.e. you are programatically providing:
><file src="uri"/>
>to the module via the modeConf. See the documentation for Avalon's  
>DefaultConfiguration object.
>Beware of the caching though; document caching doesn't use the  Transient 
>Cache, but instead a memory cache, which isn't even using  SoftReferences 
>(although oddly the XPath cache does), so if you've  got a large or 
>unlimited number of documents, turn caching off  entirely (look at the code 
>for XMLFileModule), else you'll run the  risk of running out of memory.
>On 2 May 2006, at 18:38, Andrew Stevens wrote:
>>In the Cocoon javadocs[1]  it says that input modules are passed a  
>>dynamic, per-request configuration which will usually override the  static 
>>configuration from the cocoon.xconf.  However, neither the  javadocs nor 
>>the Input Modules Reference[2] in the docs give any  indication of how you 
>>actually do this.  Is it talking about  something you can include in a 
>>pipeline, or somehow within the  {foo:bar} string of a sitemap 
>>parameter/attribute?  Or is it simply  talking about the 
>><map:component-configurations> section of the  pipeline?  If the latter, 
>>is it possible to include these within a  pipeline matcher, and use any 
>>available sitemap variables in the  configured values?
>>My suspicion is the "dynamic" configuration isn't as dynamic as I  need.  
>>I have a number of XML files (using the same DTD) and need  to extract a 
>>value from one of them to pass into a map:redirect-to  (which file to use 
>>being supplied as part of the request).  If I  was using a single file, I 
>>think I could handle it with the  XMLFileModule; judging from the 
>>URLEncode & decode input modules'  docs, it's okay to nest input module 
>>attributes (e.g. src="http:// 
>>remote/page?param1={url-encode:{request-param:param1}}"), so I  reckon 
>>something along the lines of <map:redirect-to uri="{xmlfile:/ 
>>document/link[@name='{../1}'/url}"/> would work.  With separate  files, I 
>>can just use {xmlfile:/document/link/url}, but how do I  specify for each 
>>request which file this is evaluated on?
>>If the XMLFileModule can't be used in this way, I guess I've got  two 
>>- either write my own input module that takes an xinclude-like  expression 
>>as the attribute ({myxmlfile:{1}.xml#xpointer(/document/ link/url)}) 
>>specifying both the source file and jxpath
>>- or, (since the XMLFileModule user docs say the XML can be  obtained from 
>>any cocoon source) use the directory generator and c/ xinclude transformer 
>>in a separate pipeline to combine all the  files and configure the input 
>>module to use that pipeline as its  "file".
>>Or does anyone know of a better way?
>>[1] see under "Static/dynamic configuration" in http:// 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message