Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <010901bfeaab$f9ac2960$28022397@ARES>
Reply-To: "Nicola Ken Barozzi" <nicolaken@supereva.it>
From: "Nicola Ken Barozzi" <nicolaken@supereva.it>
To: <cocoon-dev@xml.apache.org>
References: <B58C40FC.213B%esalon@canuck.com> <3966FB37.2A507476@apache.org>
 <00ad01bfe983$e336f300$5f022397@ARES> <396884E2.66E28AAE@apache.org>
Subject: Re: Forms proposal
Date: Mon, 10 Jul 2000 22:16:54 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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

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

> > 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?

> 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. ;-)

Ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)