Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Thinking further... We could use for the sitemap the <import> directive I'm currently working on for cocoon.xconf.
The sitemap components could then be
<map:components>
<map:import src="blah.xconf" roles="blah.roles"/>
...
</map:components>
After thinking about this a little bit, I agree :)
Also, do we really need a roles file, which really is a component writer's concern? The role manager can be setup by aggregating all cocoon.roles files found in the classpath. That would make role management totally transparent.
Hmm, *I* like this idea, but each time I come up with such a solution
everyone shouts "TMM" (too much magic) ;)
I don't think this is TMM, as cocoon.roles is already hidden in the jar file. The roles file mostly defines the syntactic sugar that can be used in cocoon.xconf and people can happily live without knowing about it. This is very different from cocoon.xconf where we describe how the system is assembled and configured.
I think we should support the "roles" attribute; in most cases you
don't need it; if you need it you propably would use the resource
protocol (loading the roles files from a jar) and in some rare cases
(e.g. prototyping) you use a plain file.
Well, if you use the resource protocol, this means that your roles file is already in the jar! Also, even for prototyping, new roles are needed when new component interfaces are defined, meaning a new jar file or a class directory where the roles file can be placed!
Honestly, I consider the requirement to explicitely declare the roles files that are present in jar files "TMC" (too much complexity) ;-) or more precisely it requires users to know things about the Cocoon internals that they shouldn't really have to care about (and that they don't care about today).
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
