cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <Ralph.Go...@dslextreme.com>
Subject RE: [Vote] Component confs per sitemap [was: [RT]]
Date Tue, 21 Dec 2004 16:38:53 GMT
Carsten Ziegeler said:
> Sylvain Wallez wrote:
>
>> Try again ;-)
>>
> Grumbl, grumbl...sigh...ok :)
>
> So, I suggest we forget about the roles file for now; which means
> we don't add a support for a per sitemap roles file.
> We can add it later on whenever we feel the need for it; it's plain
> simple to do so.
> And we don't add the auto-scan feature unless we need it.
>
> Deal? :)

This will not make me happy.  I prefer using the roles file for some
things as it makes the component definitions a little clearer.  For
example, look at the way input modules are defined. It is pretty self
explanatory that what you are looking at between <input-modules> and
</input-modules> is a bunch of input module definitions.

Frankly, I'd like to do the same thing for a lot of the portal components.
 In my editor the role typically is off the right of the screen. It would
be easier for me (and somewhat clearer) if <component> was replaced by a
shorthand for the role.

In addition, I have done this for the proprietary components we use. They
are currently brought in via Xpatching cocoon.xconf to specify our
cocoon.roles file.  However, it would make much more sense if it could be
specified in the xconf in the component's directory, since that is where
the file actually is anyway.

By the way, I'm not really sure why you are talking about the roles file
needing to be in the classpath as the user roles file doesn't need to be.

Frankly, I'd support this by just allowing the .xconf file in a directory
to specify a companion roles file in the same way it is done with
cocoon.xconf today.

Ralph


Mime
View raw message