> -----Original Message-----
> From: Maciek Kaminski [mailto:[EMAIL PROTECTED]]
>
> On 27 Mar 2002 at 10:42, Stefano Mazzocchi wrote:
>
> > 1) TrAXTransformer must have a way to access a specific
> instance of a
> > component, not its role.
> >
> > 2) The component manager should be able of associating different
> > identifiers to components which have the same ROLE, the same
> > implementation class, but have different configurations (which are
> > used to indicate what TrAX factory to use).
> >
> > ...
> >
> > Ok, now: I think I need some Avalon advice here, Berin? is the
> > Excalibur Component Manager already able to do the above? (sorry, i
> > don't have the code at hand right now).
> >
>
> Avalon ComponentSelectors let one to hint ComponentManager
> which implementation
> of role to create.
>
> See: http://jakarta.apache.org/avalon/developing/implementing.html
> Subchapter: Getting Components from a ComponentSelector.
Do keep in mind that the ComponentSelector pattern is available, but
it is generally preferred for you to roll your own. For instance, the
Transformer would be rewritten to return an instance of an XMLFilter
or something similar.
I agree with your point that it does not make any sense at all to make
the role configurable. IT IS NOT A CONFIGURABLE ITEM. For any system
to work, certain contracts like what is an XSLTProcessor *must* remain
constant. It is up to the container (ExcaliburCM/CS in this case) to
determine the implementation.
In short the ComponentSelector pattern would be something like this:
child = conf.getChild("xslt-processor-hint");
String xsltHint = child.getValue("default"); // It is always good to
provide a default
try
{
ComponentSelector selector = (ComponentSelector)
this.manager.lookup( XSLTProcessor.ROLE + "Selector" );
this.xsltProcessor = (XSLTProcessor) selector.select( xsltHint );
}
catch (ComponentException e)
{
throw new ConfigurationException( "Cannot load XSLT processor", e );
}
However, by changing the transformer interface, you can directly manage
the relationships
and transformer instances--always returning a valid XMLFilter
(org.apache.cocoon.xml).
The usage would change to:
try
{
this.transformer = (Transformer) this.manager.lookup(
Transformer.ROLE );
}
catch (ComponentException e)
{
//log
throw e;
}
// ... new part of the sitemap
pipeline.addFilter( this.transformer.findFilter( environment, hint ) );
I think Cocoon is nearing a place where it needs to refine its contracts
and redefine
its components. There are some components that are only used by one
other component.
The symbiosis should be encapsulated into a subcontainer that manages
that relationship.
That way the two can exist in the system, but be easier to remove all
associated components
later.
Cocoon needs to do the following to keep from imploding:
1) Reassert the core and supported roles.
a) this includes refining the interfaces so that they are simpler
b) differentiate between data/information and real components
2) Provide a logically scalable way of adding supporting components.
a) They should be grouped with the components that rely on them
b) Provide pressure to drive out objects that are only semantically
components
3) Refine the story.
a) Roles are like roles in a play--make sure the cast fits the play
b) Make sure that the plot is not lost in the details (there are too
many plot twists in cocoon)
c) Incorporate the Source resolver into the story--it is integral
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
