Return-Path: 
 <dev-return-53734-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 99352 invoked from network); 7 Jan 2004 14:13:05 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 7 Jan 2004 14:13:05 -0000
Received: (qmail 10524 invoked by uid 500); 7 Jan 2004 14:12:57 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 10493 invoked by uid 500); 7 Jan 2004 14:12:57 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 10472 invoked from network); 7 Jan 2004 14:12:57 -0000
Received: from unknown (HELO naomi.webworks.nl) (24.132.161.79)
  by daedalus.apache.org with SMTP; 7 Jan 2004 14:12:57 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Fortress] How to get the role of a component in an Accessor?
Date: Wed, 7 Jan 2004 15:12:57 +0100
Message-ID: <84F0A43A4248CE45B5C0E20F4C40779C600AC9@naomi.webworks.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fortress] How to get the role of a component in an Accessor?
Thread-Index: AcPVJhVOT7sOqzPCQBKXncE+I7QdIwAAEQ8A
From: "Unico Hommes" <Unico@hippo.nl>
To: <dev@cocoon.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


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

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

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=20
> cocoon.xconf for compatibility reasons and not introduce more=20
> complexity. I personally don't know what this line=20
> <global-variables id=3D"global-variables"/> actually does and=20
> 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