Unico Hommes wrote:
Yes, that would work. The only question, how will you check that only nodesI haven't had doubts that hosting nodes as components in an IoC container is a good approach, I think it makes perfect sense in light of a sitemap's inheritable nature. What I *have* been having doubts about is the way the container is now being configured from a sitemap following a transformation to a general container configuration, but that may be another story alltogether.
I think that defining a separate lifecycle extension for nodes in combination with a semantic restriction on sitemap components that says they must not implement Node will work well.
For instance, we could define:
interface Node { /** creation time LFE */ setup(Context context, ServiceManager manager); }
where context and manager parameters contain private objects that are not available to their equivalents passed in through contextualize and service respectively.
The LFE should just make sure the component it services is not a sitemap component.
Wouldn't that work?
will implement this? We could test against a common interface: Node.
[guessing you mean "ProcessingNode"]
Yeah, but this won't avoid people to implement that interface just to benefit from the lifecycle extension (and leave the invoke() method empty).
<RT>
Considering that the Avalon doesn't allow enumerating its content, and considering that the sitemap is preprocessed by an XSLT, what about having this stylesheet produce a random identifier that is used as the context entry name for processor-private data? This identifier will be set as a configuration attribute on sitemap statements only, thus totally hiding it from components in <map:components>.
</RT>
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
