cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Fortress Migration Strategy
Date Thu, 16 Oct 2003 08:16:03 GMT
Stephen McConnell wrote:
> Some questions:
>
> 1. Based on the current implementation - how do you declare a
> ParentAware strategy?
It's a marker interface.

> 2. How do you seperate functional service dependency from the
> implementation aware hierarchy solution?
The ParentAware interface defines a method that is passed a handler.
Using this handler, the component can lookup a parent (or
lookup a component with the same role from the parent CM).

> Am trying to translate "request-based" terminology into implementation
> based policy.  We have established a number of standard implementation
> policies.  Global verus Request suggests a request based policy - which
> is problamatic under the ServiceManager/ComponentManger interfaces.
> Could this  request policy be moved to comoponent space by delcare a
> service against which the component requests the flavour explicitly?

Yes, but this is lacks performance. Performance and elegance in using
it are the two reasons for these interfaces.

> >
>
> Is SitemapConfigurable basically the overriding of a configuration based
> on sitemap data or are your qualifying/extending a componet configuration?
>
It's an additional configuration for a component that is not declared in
the sitemap but this additional configuration is.
Dumb but simple example: you define a parser component (currently in
the cocoon.xconf). Now you could say in a sitemap that this parser
validates and in a sub sitemap that it doesn't validate.
So a lookup using the main sitemap would result in a validating
parser while a lookup in the sub sitemap fetches a non validating
one.
Let's not discuss this example, it's just to show the main idea;
I know myself that the example is not a good one.

Carsten


Mime
View raw message