cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: Questions about Meta Info (was Re: cvs commit: cocoon-2.2/src/java/org/apache/cocoon/matching Matcher.java CookieMatcher.java)
Date Tue, 28 Oct 2003 01:10:56 GMT
Berin Loritsch wrote:

> Geoff Howard wrote:
>
>> 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.


What I meant by content assist is that with marker interfaces, normal 
java ide support got you content assist (auto completion, plus in 
eclipse javadoc on hover)
for the Avalon stuff because interfaces are pure java.  The meta-info 
takes that away - just a minor annoyance really.

>> 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>
>
> It takes away the need for a separate ROLES file.

Right, but we don't have our sitemap components in a roles file.  We 
have them in <map:components> and it's not clear to me
how this concept changes in 2.2. 

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


gotcha.

Geoff


Mime
View raw message