cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Langham" <>
Subject AW: Jo! & WAR file apps
Date Tue, 06 Nov 2001 16:57:09 GMT
Just jumping in with some "real-world" trivia:

The daemon program doesn't have to open a The
Cocoon environment is abstracted and two implementations come with the
distribution : servlet and command line. Just define your own as an
Avalon service and you're done with what you need.

We do this inside what we have built. We have functionality defined inside
Cocoon, using pipelines etc. that can be accessed via a browser interface.
When we needed the same functionality in a sort of batch-mode (without HTTP)
we opted to use the CLI. So we have scripts that then call the _same_
functionality via the CLI - reusing what we already had. Works fine for what
we needed.


Open Source Group               sunShine - Lighting up e:Business
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 -

-----Ursprüngliche Nachricht-----
Von: Sylvain Wallez []
Gesendet: Dienstag, 6. November 2001 17:42
Betreff: Re: Jo! & WAR file apps

Ulrich Mayring a écrit :
> Stefano Mazzocchi wrote:
> >
> > Note: we already agreed on moving all the required components to avalon
> > so that other blocks can use them.
> In my mind the stuff could (and perhaps should) remain in the Cocoon
> project, where it's most heavily used, developed and tested. If there is
> a particular advantage in moving it to Avalon, fine. But just because
> you package something as a bunch of blocks (for example) doesn't mean it
> has to go to Avalon. I wasn't talking about actually merging code with
> Avalon.
> > Ok, show us what you mean with code, then.
> I wrote a couple of taglibs for Cocoon1 and several people downloaded
> and used them. It was possible to do that, because there was a
> well-defined interface for third-party XSP taglibs. If we can't agree on
> a common interface here, then it probably doesn't make much sense if I
> release my code :)
> > Well, come back when you have some real problem to solve and not a bunch
> > a technologies to glue together "just because it might be cool to".
> Sometimes I like to think ahead, is that against the rules on this list?
> > ??? let's make a poll here: did you people ever had to throw something
> > away because of Cocoon?
> Usually the decision goes the other way: not to use Cocoon and keep what
> one has.
> > 2001: Uli finally gets it. Writes a Generators, asks for an avalon
> > component and use it.
> >
> > The end. :)
> >
> > The problem here, buddy, is that you don't get what inversion of control
> > really is and you still want to call Cocoon (as an avalon block, this
> > time) and not allow it to call you (or your avalon components).
> I do understand what IoC is, but I also understand what the real world
> is - and it is not a one-way street. And even if it were a one-way
> street, it is still arbitrary to say the direction is Cocoon ==> World
> and not vice versa. I am not saying this direction is useless, but I am
> defending the direction World ==> Cocoon, which you are cutting short.
> Ok, perhaps the point of my little story wasn't clear, so I'll expand on
> that. I'll give a very simple example and ask you to scale it up in your
> mind:
> Suppose we have the requirement to design a system that can generate
> dynamic PDFs. Dynamic here means they contain some data from a database.
> There is a backend component (an Avalon .sar application) that scans the
> database and whenever it finds some new data, it generates a new PDF.
> Then there is a frontend component (Cocoon) that presents a
> browser-based GUI to people and whenever they click on some data, a new
> PDF is generated. So we want a central component that does
> XML==>XSLFO==>PDF - for the interactive requests and for the daemon
> program.
> In my mind it does not make sense for the daemon program to open a
> to Cocoon. The PDF generator and the daemon are
> both backend components and could both run very sensibly under Phoenix
> and talk to each other using the well-defined Avalon contracts, instead
> of stateless HTTP. I hope that example convinces you that the world is
> not a one-way street, if not perhaps you have a better suggestion for
> this concrete example. But please don't tell me to move the daemon's
> functionality into the frontend :)

The daemon program doesn't have to open a The
Cocoon environment is abstracted and two implementations come with the
distribution : servlet and command line. Just define your own as an
Avalon service and you're done with what you need.

It's true that Cocoon Environment was designed with request/response
paradigm in mind and that it heavily mimics the servlet interface. But
is a request/response really different from a method call on an
interface ? The cocoon service could have the following simple method :

  public void produce(String resource, Parameters params, OutputStream

"resource" is the name of the resource to produce, "params" are
additional values that tailor the way the resource is produced, and
"out" is where you want to get the result. No servlets here, no
URLConnection, but a different way to represent what the HttpEnvironment
in Cocoon represents using a request URI, request parameters and a
socket connection to the client browser.

And if that's not enough for you, Cocoon just an implementation of a
"Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
according to a given Environment (http, commandline, whatever). That
could be the service you're looking for.

Also, if you find the sitemap "too proprietary", you can write your own
pipeline assembly language : the sitemap has recently been decorrelated
from the Cocoon class so that you can use your own implementation of
Processor : I'm currently writing a new interpreted implementation of
the sitemap that could be the foundation of future other pipeline
assembly languages.

About this particular "too proprietary" statement you say often, let me
say also that I really don't understand it. What do you mean by
"proprietary" ?

If this means "under control of someone", then yes, it's under control :
under control of the Cocoon community. But that community is open and
anyone is welcomed to contribute ideas, enhancements, etc. That's how I
became a Cocoon committer, and I'm proud to be part of that community.
Contribute ideas and/or code instead of criticisms and you will be

If this means "not a standard", then this also true : this is not a
standard from W3C, JDK, whatever. But does it need at all to be a
standard ? Is Avalon you seem to love so much (I do also) a standard ?
Not either. Most standards in the software industry emerge today from
research projects or developper communities. Cocoon is both. Take SAX
and javax.xml.transform : there are now a standards, but started as the
work of developper communities.

> Now, if the project "moving stuff to Avalon" is to enable exactly this
> kind of scenario, then we have no disagreement. You can call it IoC, I
> can call it componentware and we can all be happy :)

Moving stuff to Avalon means that some of the Cocoon components have a
broader use that Cocoon. IIRC, Avalon component stuff started just like
that : a nice framework that was built for Cocoon2, but proved to be of
very general interest. Later on, the Excalibur component manager
followed the exact same path. The components that we plan to move to
Avalon will allow to use components for XML parsing, XPath queries, XSL
transformation, etc, without having to import an org.apache.cocoon.*
class and thus give them a wider audience. That's all.

> Again: I don't want to call Cocoon from my programs. That is in fact
> exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> can (and does) claim exclusive ownership of the Sitemap, but it can't
> (and doesn't) claim exclusive ownership of the URI space. In general:
> control your invention, but not the inventions of others.

Cocoon doesn't have any ownership of these : there is no XSL processor
in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
XML (not just XSL) transformer. It doesn't have a FO renderer but uses
smoothly FOP, RenderX or JFor.

What Cocoon does is provide means to assemble all these in pipelines to
produce resources described by an environment. That's all, but that's
done in a way that allows each concern not to overlap with others. If
you want to have a static and hard-coded XML->XSL->FOP pipeline, just
write down a few dozen lines of glue code and you're done. You don't
need Cocoon for that.

> Take care,
> Ulrich

Thanks :)


Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message