+1 Carsten
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > <RT-starts/> > > This revives an idea I had a long time ago when writing the > treeprocessor : "parent-aware" components. > > The elements in the <map:component> part of the sitemap are > ComponentSelectors (CS) with a special behaviour : they know their > "parent", i.e. the component that has the same role in the parent > ComponentManager (handled by the parent sitemap), in order to implement > component inheritance : if a CS is asked for a component it doesn't know > of, it delegates the call to its parent. It is "parent-aware". > > This is not useful only for sitemap component selectors if we consider > the fact that <map:components> is nothing more than an xconf file. > Consider for example datasources : we have defined global datasources in > cocoon.xconf, and want local datasources defined (and visible) only in a > particular subsitemap. Currently, if we write <datasources> in > <map:components>, we hide global datasources. If we used parent-aware > selectors, we could _augment_ the set of available datasources. The same > can be used for InputModules. > > Up to know, I thought this behaviour could be mostly useful for > ComponentSelectors, but the Interpreter use case proves that it can be > useful for "regular" (i.e. non-CS) components as well. > > Implementation-wise, I'm thinking of defininig parent-aware by a new > lifecycle interfacee : > public interface ParentAware { > public void setParent(Object parent) > } > > Any component implementing this interface will be given once (before > initialize()) the object that implements the same role in the parent > component manager. > > Thoughts ? > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } > >
