cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: JNet integration
Date Wed, 26 Mar 2008 02:15:38 GMT
On 25.03.2008 10:53, 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.

Hmm, I don't see the advantages of dropping the Source abstractions. Why 
giving up all the "good things" just to remove one dependency? What are 
the downsides of the Source abstraction? I never had the need to 
implement a Source and for the mentioned simple cases I wonder where you 
have to cope with them at all? Cocoon used to be a framework for 
non-Java developers ... even if we introduce a pipeline API as in the 
examples in this thread why do I need to care about Urls or Sources at 
all? Why should it be different then map:generate with its src 
attribtue? And when I read CacheableFileGenerator something tells me 
this approach is wrong.

Joerg

Mime
View raw message