cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [Vote] Component confs per sitemap [was: [RT]]
Date Tue, 21 Dec 2004 23:18:19 GMT
Ralph Goers wrote:

>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.
>  
>

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)

>>>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.
>  
>

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 }


Mime
View raw message