You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Gambale, Michael J." <mi...@merck.com> on 2000/05/01 16:21:38 UTC

What is supported in Cocoon 1.x and no longer supported in 2.0

I wanted to ask this question because my group is seriously considering
writing an XML based web site using Cocoon.

We are using the XML and XSL transformation(this is what I'm not worried
about) as well as XSP.  We're using XSP to also dynamically build the DOM
tree.  Are there any issues with Cocoon 2.0 and its use of using the SAX
parser versus DOM as to affect what we are doing?  I may be confused so set
me straight.  I just want to make sure we can upgrade without any problems.
Basically I guess the question is what can't we do in Cocoon 1.x that won't
be supported in Cocoon 2.0.


Thanks.

-Mike



Re: What is supported in Cocoon 1.x and no longer supported in 2.0

Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
> 
> On Tue, 2 May 2000, Stefano Mazzocchi wrote:
> 
> > Rather than this, _everything_ else should work for you without changes
> > if you used XML + XSLT + XSP. No changes whatsoever.
> >
> > This is the beauty of XSP that hides the output from you.
> >
> > This means that if your XSP worked with Cocoon 1.x, the _exact_same_ XSP
> > will work with Cocoon 2.0, modulo cocoon-xxx PIs.
> >
> > Impossible, you say? You don't use the DOM in your XSP pages. You don't
> > even have access to the output stream, or to the output method in
> > general. This is the main difference between XSP and JSP and this is why
> > they rock: Cocoon 2.0 will "recompile" your XSP as "cocoon 2.x
> > generators" rather than "cocoon 1.x producers".
> 
> Er, what are you talking about? Certainly I use the DOM in writing my XSP
> taglibs. Yes, we can use the DOM2SAX adapter classes (or JDOM as a middle
> layer if it turns out it makes things like namespace mapping for XML
> fragments simpler), but it's not optimal. In any case, I _do_ use the DOM
> in my XSP libraries - true, not from the XSP pages themselves generally,
> but it's disenguous to claim that there's no DOM in XSP since we've been
> encouraging people to keep the bulk of their code out of the XSP pages
> themselves and in a normal library instead.

I was not talking about taglibs. I was talking about XSP pages that
_use_ those taglibs.

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



Re: What is supported in Cocoon 1.x and no longer supported in 2.0

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 2 May 2000, Stefano Mazzocchi wrote:

> Rather than this, _everything_ else should work for you without changes
> if you used XML + XSLT + XSP. No changes whatsoever.
> 
> This is the beauty of XSP that hides the output from you.
> 
> This means that if your XSP worked with Cocoon 1.x, the _exact_same_ XSP
> will work with Cocoon 2.0, modulo cocoon-xxx PIs.
> 
> Impossible, you say? You don't use the DOM in your XSP pages. You don't
> even have access to the output stream, or to the output method in
> general. This is the main difference between XSP and JSP and this is why
> they rock: Cocoon 2.0 will "recompile" your XSP as "cocoon 2.x
> generators" rather than "cocoon 1.x producers".

Er, what are you talking about? Certainly I use the DOM in writing my XSP
taglibs. Yes, we can use the DOM2SAX adapter classes (or JDOM as a middle
layer if it turns out it makes things like namespace mapping for XML
fragments simpler), but it's not optimal. In any case, I _do_ use the DOM
in my XSP libraries - true, not from the XSP pages themselves generally,
but it's disenguous to claim that there's no DOM in XSP since we've been
encouraging people to keep the bulk of their code out of the XSP pages
themselves and in a normal library instead.

- donald


Re: What is supported in Cocoon 1.x and no longer supported in 2.0

Posted by Stefano Mazzocchi <st...@apache.org>.
"Gambale, Michael J." wrote:
> 
> I wanted to ask this question because my group is seriously considering
> writing an XML based web site using Cocoon.
> 
> We are using the XML and XSL transformation(this is what I'm not worried
> about) as well as XSP.  We're using XSP to also dynamically build the DOM
> tree.  Are there any issues with Cocoon 2.0 and its use of using the SAX
> parser versus DOM as to affect what we are doing?  I may be confused so set
> me straight.  I just want to make sure we can upgrade without any problems.
> Basically I guess the question is what can't we do in Cocoon 1.x that won't
> be supported in Cocoon 2.0.

Transition from Cocoon 1.x to Cocoon 2.0 will not be hard. The only back
incompatible thing will be the absence of cocoon-xxx PI in your
documents that are ignored in Cocoon 2.0.

Rather than this, _everything_ else should work for you without changes
if you used XML + XSLT + XSP. No changes whatsoever.

This is the beauty of XSP that hides the output from you.

This means that if your XSP worked with Cocoon 1.x, the _exact_same_ XSP
will work with Cocoon 2.0, modulo cocoon-xxx PIs.

Impossible, you say? You don't use the DOM in your XSP pages. You don't
even have access to the output stream, or to the output method in
general. This is the main difference between XSP and JSP and this is why
they rock: Cocoon 2.0 will "recompile" your XSP as "cocoon 2.x
generators" rather than "cocoon 1.x producers".

And while producers worked with DOM, generators work with SAX.

The result, for you, it's exactly the same... the memory consumption and
latency, however, much reduced.

Of course, your mileage may vary due to bugs and/or your own hardcoded
processors/producers and, yes, you will not be able to use your
"compiled XSP", you will need to have the source of them and recompile
them.

But rather than this, you should be all set: don't worry, we know people
are investing on us and we do understand what "investing" and "trust"
means :)

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