cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: JNet integration
Date Wed, 26 Mar 2008 07:34:41 GMT
Joerg Heinicke wrote:
> 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? 

I'm not talking about giving up the Source abstraction (as long as there is no 
equivalent replacement in the Java Standard API) but to put it on top of

> What are 
> the downsides of the Source abstraction? 

When we are able to introduce a pipeline API, we don't need it for simple use 
cases. The concept of URLs is well-known in the Java world, the Source 
abstraction is not.

> 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.

What's the advantage of giving our components the responsibility to deal with 
strings that represent sources?

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message