On Wed, 12 Jun 2002 10:24, Peter Royal wrote:
> On Tuesday 11 June 2002 07:35 pm, Peter Donald wrote:
> > > Another key difference is that the Cocoon model has a requirement
> > > to re-connect the hint mappings at runtime--whereas the Merlin
> > > model does it all at init time.
> >
> > Can you explain that? You aquire components based on request parameters
> > but the request parameters supply constraints and not hints (ie "ssl" vs
> > "xalan").
>
> Cocoon's pipelines are assembled dynamically at runtime. The main pipeline
> component types are Generators, Transformers and Serializers.
>
> Each one is implemented as a ComponentSelector with the hint specifying
> which component to use.
>
> For an example:
>
> <map:generate type="file"/>
> <map:transform type="xslt"/>
> <map:transform type="custom"/>
> <map:serialize type="xml"/>
>
> The java code is akin to
>
> ComponentSelector generatorSelector = cm.lookup( Generator.ROLE );
> Generator g = generatorSelector.select( "file" );
Even if you no go the path of the GeneratorManager, Would it not be wiser to
generate an object per-path through pipeline. Something along the lines of
class PipelinePath53
{
private static final String GEN_FILE = Generator.ROLE + "/file";
private static final String TRAN_XSLT = Transformer.ROLE + "/xslt";
...
void compose(ComponentManager cm)
{
Generator g = cm.lookup( GEN_FILE);
Transformer t = cm.lookup( TRAN_XSLT );
}
...
}
>
> ... etc etc.
>
> I don't see why there can't be a specific GeneratorManager that is returned
> to let you specify specific generators. The GeneratorManager,
> TransformerManager and SerializerManager would all be nearly identical
> though, thus the thinking of abstracting out ComponentSelector-style.
> -pete
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
