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
java.net.URL.
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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________