cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Date Fri, 10 Jan 2003 16:56:46 GMT
Christian Haul wrote:

>On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:
>>FYI, I patched a bit VariableResolver in treeprocessor.variables so that 
>>it can be used outside the sitemap context :
>>VariableResolver resolver = 
>>VariableResolverFactory.getResolver("{module:name}", manager);
>>String value = resolver.resolve(objectModel);
>>if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
>>It works but isn't clean since it's not COP, so I'm thinking of turning 
>>it to a component :
>>ComponentSelector selector = 
>>manager.lookup(VariableResolverSelector.ROLE + "Selector");
>>VariableResolver resolver ="{module:name}");
>>String value = resolver.resolve();
>This sounds extremely cool!


And Giacomo is right about the typo : "VariableResolverSelector.ROLE" 
should be "VariableResolver.ROLE". Chatting like we do these days on 
cocoon-dev makes me less careful ;-)

>>The selector is a special implementation that does the parsing already 
>>existing in the TreeProcessor, and resolver.resolve() accesses the 
>>object model through CocoonComponentManager.
>That would include parsing the complete string
>eg. "log-{request-param:name}-{date:now}.xml", right?


But I'm also wondering how we could also use the fact that InputModule 
returns Objects and not only Strings and would like to have a means to 
return an object for e.g. {request-attr:foo}.

I also would like to introduce InputOutputModules. For example, I have a 
component which needs some data to work, but doesn't actually care where 
this data comes from, as it may depend from the application. For 
example, it could be {request-attr:foo} or {session-attr:bar} or 
{context-attr:baz}. So I would like to have an InputOutputModule that 
can be used by the application to set the value, and the by the 
component to read it.

Thoughts ?

>Another thought: the Selector needs use the same component manager as the component requiring
the lookup. Otherwise there could be a visibility problem, right? That is, if we allow module
to be declared anywhere else than in cocoon.xconf.

You're right. A solution is for this component to be implicitely added 
to the sitemap's CM, thus avoiding looking up back to the parent's CM.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

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

View raw message