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