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
