cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: Forms proposal
Date Thu, 13 Jul 2000 20:17:51 GMT
----- Original Message ----- 
From: "Stefano Mazzocchi" <stefano@apache.org>
Sent: Tuesday, July 11, 2000 2:40 PM

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

Ok, that's what I imagine too, it's justs that now it's not the case.
Just saying that this is not how I am using C1.

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

Yesssssss.

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

I'm sorry but I don't understand.
If I compile a java class, it can have methods with input (multiple) and output.
What's the difference?
If it's too long to answer, where can I find this in the documentation?

> > > 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 :)
 
:-)  
In fact it could be more right to say that because you started Cocoon,
if you say that compiled transformers are not necessary we should 
believe you; if they were really needed you would do them right away!

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

I don't think XSP is duplicating efforts.
It's like saying that Java is duplicating efforts because there's allready
C++! XSP are very cool (using XSL for substitution is clever) and
taglibs are easy to write (not like JSPs').
Anyway I think you are right for the compiled XSL.
I wasn't aware of the latest Xalan.
Thank you for taking time to answer.

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



Mime
View raw message