Steve has just hit a reset button and it going to dig some more. Thanks for the feedback.
Take two!
The ECM Scenario ----------------
Here is a ECM/Fortress style <role> element.
<role name="org.apache.cocoon....PortalManager"
shorthand="portal-manager"
default-class="org.apache.cocoon....PortalManagerImpl"/>Here is a Merlin style component element:
<component name="portal-manager" class="org.apache.cocoon....PortalManagerImpl"/>
In Cocoon (please correct any mistaken assumptions) the client application (i.e. the site-map parser) reads in requests for services and invokes requests on an object implementing the ComponentManager interface (e.g. ECM).
Component component =
m_manager.lookup( PortalManager.class.getName() );The ECM implementation locates a role entry based on the interface name, maps that to a implementation class (based on the role and/or config attributes), maps the implementation class to a handler and returns an instance from the handler.
The Merlin Scenario -------------------
In Cocoon the client application (i.e. the site-map parser) reads in requests for services and invokes requests on an object implementing the ServiceManager interface (e.g. ecm-facility).
Object service =
m_manager.lookup( PortalManager.class.getName() );The ecm-facility implementation locates a component model implementing the service class and returns this to the invoking client. At this stage we don't need any role file or configuration. In fact all we need is an empty container with a classloader declaration (example available in the merlin/platform/tutorials/dynamics tutorial in CVS). However - just pulling in implementations isn't enough - sometimes we need to parameterize the solution. In ECM/Fortress this is referred to as a role. In Merlin it is referred to as a profile. Based on the information in existing roles and config file we should be able to automatically generate a block definition.
The above process will work fine for components that are written for ServiceManager and are accompanied by xinfo files. Without the xinfo we would need to either put in place xinfo generator for ECM style components or handle dynamic Type registration based on reading in a role file.
The above scenario sort of looks like the following:
|--------------------------| |----------------- | Merlin | exports | Cocoon | | ServiceManager | | <container> ------------|----------------->| | <ecm-facility> | | | <classic-component> | | <classic-component> | | <generated-component> | | | |
One thing to keep in mind in the above is that none of this requires any change to merlin internals. The complete set of ECM semantics are handled by the ecm-facility (which is a component running in merlin exporting a service that just happens to be the ServiceManager interface from framework). This is nice because we can isolate the ECM style logic while maintaining ability to evolve.
Before going further into the "ComponentManager versus ServiceManager" and "Selector" questions - how is this looking so far?
Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
