Moving this discussion over to [EMAIL PROTECTED] Carsten Ziegeler wrote: > > 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. >
How about not using SitemapVariableHolder component anymore but instead make GlobalInputModule configurable? Unico
