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
