cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [Fortress] How to get the role of a component in an Accessor?
Date Wed, 07 Jan 2004 13:08:46 GMT

Moving this discussion over to dev@cocoon.

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

Mime
View raw message