cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: Jo! & WAR file apps
Date Tue, 06 Nov 2001 22:55:16 GMT
On Tue, 6 Nov 2001, Sylvain Wallez wrote:

>
>
> 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
> > 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 :)
>
> The daemon program doesn't have to open a java.net.URLConnection. 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
> out)

This is exacly what we are saying many times since week (or month).
If you need a "Cocoon service" as an Avalon Block, write it, it's simply
another Environment Cocoon can run in.

Giacomo

>
> "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
> heard.
>
> 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.
>
>


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


Mime
View raw message