I'm with you, too.
Just as an example, I think it might be useful to use Corona as the
basis for a new Ant task called Pipeline. That task could do any number
text transformations to a set of files as part of a build process. Here,
caching is a non-issue for the most part since the point of using a
pipeline would be to process each file only once. Rather than either
java.net.URL or SourceResolve, we'd probably want to feed the pipeline
based on Ant resources[1], just as the existing XSLT task is fed.
It may be that SourceResolver and an AntResourceSource is the best way
to solve the problem, but on a cursory glance it sure looks like it is
difficult to separate the banana from the gorilla[2] that is Avalon.
[1] http://ant.apache.org/manual/CoreTypes/resources.html
[2] http://www.ddj.com/architect/184408251
Torsten Curdt wrote:
On Mar 26, 2008, at 14:44, Ralph Goers wrote:
Reinhard Poetz wrote:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap
Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2
- here you are:
Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine
+ Spring
XML-SAX
componnents
This layered approach makes Cocoon easily embeddable in any Java
application and Cocoon's learning curve becomes more gradual.
Is such a situation only appealing to Carsten, Steven and me?
Just lurking but I am with you guys.
Appealing? yes. Actually implementable in Java so that it isn;t even
more complicated than what we have? I don't know.
IMO this would simplify a lot as it separates concerns and the inner
guts can be used in other projects without the pain of dependencies we
have right now. People have been asking for this for years. I really
think think this is the right direction.
cheers
--
Torsten
