Reinhard Poetz pisze:
> Reinhard Poetz wrote:
>> What about the developer? He could assemble pipelines this way:
>>
>> URL baseUrl = new URL("file:///C:/temp/");
>> Pipeline pipeline = new NonCachingPipeline();
>> pipeline.addComponent(new FileGenerator(baseUrl, "xyz.xml");
>> pipeline.addComponent(new XSLTTransformer(baseUrl, "xyz.xslt");
>> pipeline.addComponent(new XMLSerializer());
>> pipeline.invoke(new InvocationImpl(System.out));
>
> uuups, small correction:
>
> 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));
Hmm, getting back to more complicated scenarios. Do you think that baseURL
should be scoped (with
"call" scope) Spring bean?
Another question is weather we should still support "meta-protocols" like
blockcontext: one.
Currently it works following way:
* if you ask for "blockcontext:" or "blockcontext:/" then you will get
instance of
BlockContextSource that implements TraversableSource (to list all blocks) and
always returns null if
it's asked for InputSource.
* if you ask for blockcontext:/block_name/directory then casual FileSource is
returned pointing to
the filesystem path of block's root directory.
In second case, blockcontext: works as a "meta-protocol" because its Factory
never returns its
instance. This leads to the issue that getURI()/getExternalForm() returns path
beginning with
"file:/" instead of "blockcontext:" which is bad IMHO.
I think one should always expect the same protocol used in canonical
representation of newly created
URL in order to avoid confusion.
WDYT?
--
Grzegorz
