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
