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
