Sylvain Wallez said: > Ralph Goers wrote: > >> >>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?
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. > >>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) 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. > >>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). > >>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. Ralph
