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 14:12:57 GMT

Carsten Ziegeler wrote:
> 
> Unico Hommes wrote:
> > 
> > > 
> > > But there are some problems:
> > > 1) Compatibility. We have SitemapConfigurable in 2.1 and I would 
> > > really like
> > >    to be compatible in this area.
> > 
> > OK, agreed. We need support for it in 2.2.
> > 
> > > 2) The identifier for the component used in the sitemap 
> is currently
> > >    "global-variables", the name of the input module is "global".
> > >    Regardless which of the two you change, you end up in an 
> > > incompatibility
> > >    again, I think.
> > > 
> > 
> > Do you think cocoon.xconf in 2.2 should be compatible with 2.1?
> > 
> Absolutely.
> 

This means we need to overide Fortress' default way of configuring the
container. Because by default it looks for an 'id' attribute as you
mention below. If a component is not declared in the containter
configuration with an id attribute it is not configured with an id
attribute it isn't available.

> > For instance input modules are now declared in cocoon.xconf version 
> > 2.1 as follows:
> > 
> > <input-modules>
> >   <component-instance name="global" src=".." />
> > 
> > In cocoon.xconf I have been using:
> > 
> > <global-input id="global" />
> > 
> > instead.
> > 
> > Btw. the name of the global input module in cocoon.xconf ("global") 
> > refers to its id (hint) not the shorthand you use to declare the 
> > component. Right?
> > 
> > Anyway, I think it should be possible to have more than one 
> shorthand 
> > for a given component by declaring a role mapping in 
> cocoon.roles for 
> > it. That way both <global-variables> and <global-input> can 
> be used to 
> > declare the input module.
> > 
> Hmm, ok.
> 
> This issue is something I encountered today while trying to 
> get the global input module running. Adding the 
> global-variables component in the cocoon.roles file wasn't 
> enough. I also had to add a <global-variables 
> id="global-variables"/> to the cocoon.xconf as well which 
> imho is not very good.
> 

No I don't like this either. If you only intend to have one component of
a certain type you shouldn't have to give it an id. As for not declaring
a component in cocoon.xconf at all, that would be more difficult.
Because there is currently no way in Fortress to ask for component meta
info given a role string. I guess because there could be multiple
choices.

> In general, I think we should stick to the 2.1 syntax of 
> cocoon.xconf for compatibility reasons and not introduce more 
> complexity. I personally don't know what this line 
> <global-variables id="global-variables"/> actually does and 
> why the entry in the cocoon.roles is not sufficient.

Take a look at AbstractContainer.configure() . That's where the
container configuration gets parsed and the components are added
accordingly.

Unico

Mime
View raw message