cocoon-dev mailing list archives

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

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

AFAIU, this is required to keep the current format of <map:components>.

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

Agree, but maybe it's just too much automagic...

> Is there potential for name clashes?  Absolutely.  In practice 
> however, the potential is a lot lower than you think.

And what happens in that case? An exception should be raised, otherwise 
I guess the user will have no more hairs on his head when she finally 
finds that the system doesn't behave as expected because the used class 
isn't the one she expected...

> This style of managing component meta-info has been around for a 
> while, and it is new to you. Give it a chance.

Yeah, I'm ok to give it a chance, but I'm wondering about the "too much 
magic kills the confidence" syndrome : too much of today's xconf 
structure is disappearing at once. And I think I'll miss the "class" 

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

Mmmh... Yep, that's better than just "jdbc" or "j2ee". And you're right 
that most often an implementation class name ends with the name of the 
service interface it implements.

We'll see... But I'm still afraid that, although containing less class 
names, the "flat bag" organization of the new xconf file will frighten 
users to touch it even more than the current one that is full of class 

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message