On 26.03.2008 08:04, Carsten Ziegeler wrote:
What's the advantage of giving our components the responsibility to
deal with strings that represent sources?
Isn't that what components are there for? Encapsulating commonly used
functionality? Why should I extract that to the pipeline *instance*
level? So writing pipelines is becoming a mess!
Hmm, I don't think so. Imagine a pipeline java api just taking a uri for
the sources used in the pipeline. That's simple and easy.
Now, you can use the source resolver on top of that, resolve your
sources and you get a uri from your source that you can put into the
pipeline api.
That's neither a mess nor does it require more java coding.
I'm not sure if we are talking about the same. If I take Reinhard's
sample [1]
URL baseUrl = new URL("file:///C:/temp/");
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(new URL(baseUrl, "xyz.xml"));
pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, "xyz.xslt"));
pipeline.addComponent(new XMLSerializer());
pipeline.invoke(new InvocationImpl(System.out));
and want to add caching to it and therefore have to switch from URL to
Source and from FileGenerator to CachingFileGenerator - sorry, but
that's a mess since this means pretty much rewriting the application for
adding caching. Why is this page so slow? Oh, sorry we forgot this
pipeline to switch to caching ...
Why can't high-level pipeline components use low-level components like
SourceResolver? Then it is up to the component to use either URLs or
Sources. That would be like implementing CacheableProcessingComponent or
not.
That's why I wonder where a pipeline writer gets into uri resolving at
all? Why does he have to care about URLs or Sources? That's the
component developer's concern.
I really wonder if I miss something. All this seems to be too obvious to
me ...
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=120646488429681&w=4
