cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Questions about Meta Info
Date Mon, 27 Oct 2003 14:55:21 GMT
Sylvain Wallez wrote:

> Berin Loritsch wrote:
>>> - What do sitemap components get for @x-avalon-info?  A new made up 
>>> string like cookie-matcher?  The @name/type from the default sitemap 
>>> in 2.1?
>> The @x-avalon-info name="cookie-matcher" line lets you define your 
>> components
>> like this:
>> <cookie-matcher name="foo">
>>   <internal>configuration</internal>
>> </cookie-matcher>
> I must say that I'm not really convinced by this notation, as it makes 
> finding the various implementations or a service in an xconf file 
> somehow difficult, and even make the xconf file hardly understandable 
> unless you know the shortname for each and every service implementation.

How is it so different than what you see now in ECM based configurations,
really?  There is no real difference.

> In the ECM, the hints were visible only _within_ a selector defining the 
> scope of these hints, e.g.:
> <datasources>
>  <jdbc name="foo">...</jdbc>
>  <j2ee name="bar">...</j2ee>
> </datasources>

How many other component types are named "jdbc" or "j2ee"?  It really
isn't that hard.

> If Fortress configurations are flat configurations with hints (or 
> x-avalon-info), knowing what kind of component an element declares can 
> be tricky. Furthermore, there's a non negligible probability of name 
> clashes on large systems.

By default, but we can adapt it to handle the configuration file however
you want.  If it makes it easier for you to deal with <datasources>
and a bunch of internal components, that can easily be accomodated.
Also if you adopt a few naming conventions there will be no real issue.

For instance, the default naming convention for FOrtress based components
takes the Class Name (minus the package) and trnasform it into an "XML"
name.  Essentially an all lowercase name with hyphens to separate words.
For example:

CookieMatcher -> cookie-matcher
FileGenerator -> file-generator

It's not that difficult.

Is there potential for name clashes?  Absolutely.  In practice however,
the potential is a lot lower than you think.  This style of managing
component meta-info has been around for a while, and it is new to you.
Give it a chance.

> Something that would be more readable IMO, is to have the hint as an 
> additional attribute, e.g.
> <datasource type="jdbc" name="foo">...</datasource>
> <datasource type="j2ee" name="bar">...</datasource>
> and accordingly:
> <matcher type="cookie-matcher" name="foo">...</matcher>

We can adapt the CocoonContainer type to handle this mapping--but is
it really more readable?  It is more verbose than say:

<jdbc-datasource name="foo"/>
<j2ee-datasource name="bar"/>

Which is what is the more normal convention.

> What this means is that the @x-avalon-info should be considered 
> differently for service interfaces (element name) and for classes 
> ("type" attribute).

No, it means that your interpretation of the configuration to get
at the short name would be different.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message