avalon-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 12:43:36 GMT

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?

Unico

Btw. shouldn't it be Creator instead of Accessor for implementing
SitemapConfigurable extension?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message