cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java CookieMatcher.java)
Date Mon, 27 Oct 2003 14:41:48 GMT
Berin Loritsch wrote:

> Geoff Howard wrote:
>
>> ghoward@apache.org wrote:
>>
>>> ghoward     2003/10/25 14:59:50
>>>
>>>  Modified:    src/java/org/apache/cocoon/matching Matcher.java
>>>                        CookieMatcher.java
>>>  Log:
>>>  start fortressizing Matchers.  lots of open questions already,  so 
>>> I'll pause here.
>>
>>
>> I'm hoping someone with more confidence in the changes needed can 
>> check out the simple changes below.  Such a paradigm shift to give up 
>> the marker interfaces (and I'm mourning the loss of content assist.  
>> Don't suppose an eclipse plugin for meta info yet?)
>
>
> Content assist?
>
> Eclipse plugin:  not at this time.
>
>> Open questions:
>> - 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.

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>

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.

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>

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

> It takes away the need for a separate ROLES file.
>
>> - Will this mean we no longer have to declare sitemap components in 
>> the sitemap?
>
>
> More it means that there is no reason to have a ROLES file, which also 
> means taht you can incorporate any component into Cocoon using a 
> friendly configuration name without resorting to specifying user roles 
> files or even internal roles files.
>
>> - What about other lifecycle interfaces like: Contextualizable, 
>> Parameterizable, Disposable?
>
>
> They haven't changed.  They actually have a reason to exist.  They 
> provide information or invoke an event on the component--unlike the 
> marker interfaces that did nothing but mess with the class hierarchy.


Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message