cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: JNet integration
Date Tue, 25 Mar 2008 16:53:38 GMT
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>> Reinhard Poetz wrote:
>>> 
>>> Once again, my goal is that if you use e.g. Corona in its simplest form,
>>> I don't want to make everybody and his dog depend on 
>>> JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL 
>>> object is enough for simple use cases of a pipeline API.
>>> 
>>> Yes, I understand that when it comes to caching pipelines, you need more,
>>> but not everybody needs caching pipelines. For that purpose there could
>>> be a CacheableFileGenerator, etc.
>>> 
>>> If you are right and it is difficult or even impossible to remove the 
>>> dependencies on source/sourceresolve/xmlutils/jnet, then be it. I 
>>> withdraw my example Url("servlet:...") from above. When we can switch to
>>> sourceresolve 3.0, the dependency graph will get smaller anyway.
>>> 
>>> The main benefit from using URLs (instead of the SourceResolver) comes 
>>> from simple use cases, e.g. you need a pipeline in your Java application
>>> that reads in some XML file, performs some transformations and finally
>>> creates a PDF document. FWIW, using URLs should be all that you need.
>>> 
>> I totally agree with Reinhard; for most uses cases getting an input stream
>> (or sax events) via a url is totally sufficient. With the source interface
>> we created another abstraction like the request/response abstraction in the
>> cocoon environment which seems to be nice and great but in the end is not
>> really needed, creates problems in other places etc.
> 
> I agree that our Environment abstraction was awkward - it introduced
> abstraction that never was a real abstraction and mostly duplicated existing,
> quite nice servlet API.
> 
> At least now I fail to see coherent, nice to use standard Java API that
> Excalibur's Source and SourceFactory duplicates. As for now I can only see
> obstacles like:
> 
> new URL("blabla/foo");
> 
> will fail with java.net.MalformedURLException: no protocol: blabla/foo so one
> must use:
> 
> new URL(baseURL, "blabla/foo");
> 
> Who will judge if given path is relative and requires baseURL instance? How
> one will get this baseURL instance?

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));

Any need for a Source object?

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message