Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <396B15DB.F0CD62A8@apache.org>
Date: Tue, 11 Jul 2000 14:40:59 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Forms proposal
References: <B58C40FC.213B%esalon@canuck.com> <3966FB37.2A507476@apache.org>
 <00ad01bfe983$e336f300$5f022397@ARES> <396884E2.66E28AAE@apache.org>
 <010901bfeaab$f9ac2960$28022397@ARES>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nicola Ken Barozzi wrote:
> 
> ----- Original Message -----
> From: "Stefano Mazzocchi" <stefano@apache.org>
> Sent: Sunday, July 09, 2000 3:57 PM
> 
> > Nicola Ken Barozzi wrote:
> >
> > > Imo, it seems as if something is missing in Cocoon...
> > > We have (C1) producers, processors and formatters, which are java classes.
> > > Then we have equivalent elements that have the same functions, only easier to
> > > use: XSP, XSLT, XSL(?).
> >
> > We call this XSL(?) as FO (formatting objects).
> 
> Mmm... I put the (?) because while FO is the right thing to put there, it's not
> what you find. First of all you usually XSL away directly to HTML, then
> FO is with processors (XSL) not cocoon formatters...

Why so? I could easily imaging having a FO-aware browser (Acrobat Reader
5.0?)
 
> > > Basically there are three types of "interfaces": input, "pass it on" and output.
> > > --producers: input-"pass it on"
> > > --processors: "pass it on"-"pass it on"
> > > --formatters: "pass it on"-output
> > >
> > > Now, if someone wants to manipulate nodes programmatically in XSP, he
> > > is creating a producer that functions like a processor !
> 
> I see you didn't comment this one; in the list there is a discussion on legacy
> XSP and direct DOM processing.
> Taken for granted that includes can resolve some problems, do many cocooners
> manipulate the DOM directly because they are trying to use XSPs in part as
> transformers?
> 
> > >
> > > Then what about XSStylesheets?
> > > I would love to be able to write "XSP style" stylesheets.
> >
> > You mean "compiled transformers", right?
> 
> Yep.
> 
> > I don't see the need for this, but I'll be listening to you guys to your
> > reasons.
> 
> Content-view separation. If I need to put Java code in my pipeline
> without making classes, I can make only XSP-generators. But if
> the code is pertinent to the view of the C-V? Must I put it in the
> XSP-generator? Namespaces help, I can use different taglibs, but the
> file is the same.
> 
> It seems also as if there is overlapping between content and view in the
> processors: some generate content, others "views".
> 
> Maybe I'm missing something...

Yes, you are missing XSLT extensions that give you the ability to do
what you are asking for.
 
> > > I read that you can't do everything with XSLT; this isn't yet true for what
> > > I am doing, but certainly XSLT is not allways as fast as you could get
> > > with custom code.
> > >
> > > And Xalan extensions?
> >
> > I believe the notion of "compiled transformers", "compiled stylesheets"
> > and XSLT extentions are very similar. In fact so similar they are
> > probably all the same thing.
> 
> Yep.
> 
> > Like I said, we could extend XSP to provide the ability to create
> > compiled transformers, just like XSLT was extended with the ability to
> > run without any input. (A filter without an input is not a filter in my
> > vocabulary, but anyway...)
> 
> Must a compiled transformer not have input?

After reading the XSLT spec a hundred times, this is what I understood.
 
> > So what you need are XSLT extentions and hopefully Xalan will be able to
> > "compile" your stylesheets (either in memory or in java classes) to
> > optimize both XSTL and your extentions.
> 
> That could do it.
> 
> > But this is something, IMO, Cocoon shouldn't take care of.
> 
> In the documentation it seems that Cocoon started because servlets
> weren't enough for XML. ;-)

Don't fool me :)

Anyway, the problem is simple: there is another project that already
handles this, why bother duplicating the effort? (they are already
saying XSP is duplicating efforts).

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------