Unico Hommes wrote:
> 
> Carsten Ziegeler wrote:
> > 
> > Unico Hommes wrote:
> > >
> > > Carsten Ziegeler wrote:
> > > >
> > > > How can I get the role of a component in an Accessor?
> > > >
> > > > I looked into the context passed to the access() method, but it 
> > > > doesn't seem to contain the role name, e.g.
> > > > a context.get( "component.name" ) doesn't work.
> > > >
> > >
> > > Haven't tried it myself but I think you should be able to get the 
> > > MetaInfoManager via the ServiceManager that you can get from the 
> > > Context object.
> > >
> > > ServiceManager services =
> > > context.get(ContainerManagerConstants.SERVICE_MANAGER);
> > > MetaInfoManager meta = services.lookup(MetaInfoManager.ROLE);
> > >
> > Wow, that's what I call simple :) Thanks!
> > 
> > > Could you provide some background as to why you need this? 
> > Just trying 
> > > to think along with you :-)
> > >
> > Yepp, of course. I'm trying to get the SitemapConfigurable in 
> > Cocoon 2.2 working. There you have an extra configuration in 
> > the sitemap for a component.
> > So, you have a map of configurations where the key is the 
> > role of the component.
> > Now, when the component is looked up, the lifecycle extension 
> > has to pass the correct configuration to the component. 
> > Therefore it needs the role of the component.
> > 
> 
> I had a hunch you were doing that ;-) I have been thinking about a more
> IoC like solution for this. In order to do this a the
> component-configurations section of a sitemap could be transformed into
> component declarations:
> 
> <component-configurations>
>   <global-variables>
>     <var1/>
>   </global-variables>
> </component-configurations>
> 
>  sitemap2xconf.xsl
>  ---> 
> 
> <global-variables id="global-sitemap-variables">
>   <var1/>
> </global-variables>
> 
> This would tell the sitemap container to add that component.
> 
> Granted it is a little bit different than SitemapConfigurable, but
> perhaps it covers the same ground? Advantages are that you no longer
> have the SitemapConfigureble lifecycle, thus that any configurable
> component can be configured local to the current sitemap.
> 
> WDYT?
I think, this doesn't work :) (but perhaps I'm wrong). The problem lies
in the container hierarchy. The global input module, that is using 
the global-variables componnent is configured in the root container.
So, a lookup from the global input module will never look up the
correct version from a (sub) sitemap.

So, the trick (in Cocoon 2.1) is, to have SitemapConfigurable that is
able at runtime, to get the correct configuration of the current
sitemap while the sitemap.variables component is a singleton.


> 
> Btw. shouldn't it be Creator instead of Accessor for implementing
> SitemapConfigurable extension?
> 
Yes, I just used the class someone else did without thinking :) Creator
seems to be more correct, yes.

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to