cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <Ralph.Go...@dslextreme.com>
Subject Re: [Vote] Component confs per sitemap [was: [RT]]
Date Tue, 21 Dec 2004 18:17:25 GMT
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


Mime
View raw message