cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: source resolving in 2.2
Date Fri, 30 Jan 2004 16:56:50 GMT
Carsten Ziegeler wrote:

>Unico Hommes wrote:
>>I 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
>>Wouldn't that work?
>Yes, that would work. The only question, how will you check that only nodes
>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).

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>.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message