cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Vote] Component confs per sitemap [was: [RT]]
Date Tue, 21 Dec 2004 17:21:20 GMT
Ralph Goers wrote:

>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.

Sorry, but I don't get the real message you want to convey (language 
problem): do you mean that <input-modules> is better tha 
role=""> for the 
enclosing tag or that <component> is better than <input-module> for the 
inner elements?

>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.

The problem is to define "component's directory". Components are classes 
and are therefore packaged as jar files (or a class directory)

Isn't it easier to have the roles automatically defined from the jar 
file rather than having to xpatch the xconf file?

>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.

Automatically loading roles files contained in jar files allow role 
management to be transparent to users. An xconf file is something 
component users are more than likely to change. A roles file is 
something that allows to use a clearer syntax but that component users 
never modify.

And even more: as they don't need to understand what's inside a role 
file, why should they even care about this file at all? Defining new 
roles is a component developper's concern, and as such can be included 
in the jar file containing the component classes.

>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.

You name a companion role files today because proprietary components 
have no other way to provide their role definitions to the system.

With my proposal, this is handled transparently by packaging your 
specific role definitions within the jar containing your proprietary 
classes. You can even have several proprietary blocks, each providing 
its own role definitions, which you cannot do today with a single 
companion role file.

No more xpatch to build the xconf and transparent loading of role 
definitions that are just syntactic sugar for the xconf files. That's 
what I would like to achieve.

How does that sound?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message