Geoff Howard wrote:

[EMAIL PROTECTED] 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>

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.


--


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



Reply via email to