Ralph Goers wrote:
Sylvain Wallez said:
Ralph Goers wrote:
Sorry, but I don't get the real message you want to convey (languageThis 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.
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?
IMO, <input-modules> is better than <component-instance
role="org.apache.org.component.modules.input.InputModule">. It would be
nice if each input module could be defined via <input-module> instead of
<component>, but I don't believe that is possible since each is a
different class.
It is possible: the element used to declare members of a selector is handled by the selector itself, and not by the individual classes. This requires to use a specific subclass of ExtendedComponentSelector that redefines the "getComponentName()" method (see for example o.a.c.c.treeprocessor.sitemap.ComponentsSelector)
The problem is to define "component's directory". Components are classesFrankly, 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.
and are therefore packaged as jar files (or a class directory)
Sorry. Over usage of the word "component". I meant more in the sense that a cocoon block is a component, or that a project or product is a single component. In those cases you would put a sitemap, an xconf and a roles file together in the root directory for that "project".
Isn't it easier to have the roles automatically defined from the jar
file rather than having to xpatch the xconf file?
Why would I need to xpatch anything? The xconf file in my project
directory would refer to the roles file in the same directory.
That's true. The block's specific xconf can reference the block's specific roles 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.
They do have to understand what roles are available to be used, just as a
sitemap author needs to know what components have been defined. Why not
just "automagically" inspect all classes in a jar and register them with
the component manager based upon the interfaces they implement? (That
question is rhetorical - it would be awful).
Good idea :-)
Seriously, have you seen many people looking at cocoon.roles? The current state is that cocoon.xconf describes all the available components, so you actually don't need to look at cocoon.roles.
Mmmh... or maybe the fact that cocoon.roles is currently hidden is one of the reasons that led cocoon.xconf to be so complete? Mmmh...
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?
Dangerous.
Not patching is the desired goal. I just don't see the need to have the
overhead of a component that goes and manages role files by searching
jars. I would also be concerned that there would be unintended side
effects as roles are implicitly loaded. With declarative inclusion you
could effectively isolate what configurations roles apply to.
That makes sense. On the other hand, roles files are just the enablers of syntactic sugar we use in xconf, and therefore do not hold much information except default classes, and are very unlikely to be modified by users.
So the whole question is if we consider the roles to be some internal machinery that users shouldn't care about, or if we should make it more apparent, even if this is actually limited to a roles="resource://path/to/block/specific/cocoon.roles" attribute that never gets modified, thus inviting curious users to "pull the link" and see what's behind it.
Mmmh... ok, so let's forget about this classpath introspection for now, and see how life is with separate xconf files first.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
