cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: Jo! & WAR file apps
Date Tue, 06 Nov 2001 14:12:34 GMT
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
java.net.URLConnection 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 :)

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 :)

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.

Take care,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message