Christian Haul wrote:
On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:Thanks.
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 = selector.select("{module:name}");
String value = resolver.resolve();
selector.release(resolver);
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 ;-)
Exactly.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 ?
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.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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
