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 <component-instance role="org.apache.org.component.modules.input.InputModule"> 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
