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



Reply via email to