You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mike Engelhart <me...@earthtrip.com> on 2000/06/06 05:58:50 UTC
XSP again
After the discussion today about the "right" way to insert external DOM
elements into XSP, I am left totally confused. I had all my pages working
fine until I found out I was doing things the supposedly "wrong" way :-)
The suggestion was "never" to use internal XSP object local variables such
document, xspCurrentNode, etc (even though they are fully documented and
have suggested uses for XSP writers in the XSP documentation). How is it
then possible to insert an element that has a different parent then the XSP
page?
Several people said that the way to insert an element was (assuming a
library class whose myMethod() returns an org.w3c.dom.Element):
<xsp:expr>library.myMethod()</xsp:expr>
This does not work. You will always get a "DOM005 Wrong document error"
doing this.
Does anyone have any suggestions on how site developers are supposed to use
library methods that return Node or Element objects if it's highly
recommended not to use the XSP variables?
Mike
Re: XSP again
Posted by Mike Engelhart <me...@earthtrip.com>.
on 6/6/00 8:18 AM, Stefano Mazzocchi at stefano@apache.org wrote:
> I say we forget about this back compatibility since the XSP codebase
> that used such internal hooks are very little (probably only Mike got
> that far off).
+1 on that. I didn't mean to bring this up saying that I want my current
code to work perfectly in C2. I just want to make sure I don't keep digging
myself underground using things that are obviously going to break when I
begin to migrate.
Mike
Re: XSP again
Posted by Stefano Mazzocchi <st...@apache.org>.
Ricardo Rocha wrote:
>
> Mike Engelhart wrote:
>
> > The suggestion was "never" to use internal XSP object local variables such
> > document, xspCurrentNode, etc (even though they are fully documented and
> > have suggested uses for XSP writers in the XSP documentation).
>
> XSP builtin objects can be:
>
> 1) Core, XML-related objects.
> For DOM (Cocoon1): document, parser, xspCurrentNode, etc.
> For SAX (Cocoon2): contentHandler, lexicalHandler, etc.
>
> 2) Cocoon's "request" and "response" objects
>
> 3) "Environment", container-supplied object
> For servlets: HttpServletrequest, HttpServletRequest, HttpSession,
> etc.
> For offline: [command-line] parameters, target directory, etc.
> For other modes: ...
>
> If one wants to write XSP pages that are portable across XML API's, one
> should encapsulate access to "core" objects by means of logicsheets
> and/or
> method calls (as opposed to inlined, "raw" code). If one doesn't, who
> cares!
> :-)
Well, it should be made _clear_ what objects you should _not_ be using
to keep portability and forward-compatibility.
> Cocoon's objects provide support for the request/response model in a way
> that is abstracted from the containing environment. In particular, a
> Cocoon
> request is _not_ and HttpServletRequest (though it's based on it for the
> servlet execution environment).
>
> If Cocoon is run from the command line (using the offline package), then
> "request" becomes a wrapper for command-line parameters, while the
> "response"
> ends up being written to disk files (instead of to an Http stream).
>
> It's obvious that XSP needs a "clean" way of accessing the underlying
> host
> environment objects (in addition to the Cocoon's request and response
> objects)
>
> This is a matter of further discussion in the list:
>
> What's the best way to make environment objects available to
> Cocoon2 Generators? (not only to XSP, btw!)
Yes. This has been one of my worse nightmares in the cocoon1->2
transition.
> The XSP implementation for Cocoon1 did not establish this kind of
> distinction
> among its builtin objects. In particular, servlet objects were given the
> same
> status as DOM objects. Bad, bad...
Yep. It should be possible to restrict the scope of such objects from
the <xsp:logic> tags so to "validate" the XSP logic. But you should tell
me if this is feasible or not.
> Neeme Praks wrote:
> > Donald Ball wrote:
> > > 6 of one, 1/2 dozen of the other. i guess i just don't like relying
> > > on XSP's built in and not documented very well variables.
> >
> > One more question: is there somewhere some documentation about these
> > built-in variables?
>
> Stefano Mazzocchi wrote:
>
> > No and you should not be aware of them!
> > xsp were designed so that you didn't require to know how they are
> > compiled to make them work. If you tie yourself to a particular XSP
> > engine implementation, you're fucked!
> >
> > So, use
> >
> > <xsp:expr>yourMethod()</xsp:expr>
> >
> > and only this!
>
> Using a separately written method or (better yet) using logicsheets are
> good ways to "protect" you from the DOM/SAX dychotomy. Beyond that,
> this discipline also allows you to write dynamic pages that can run in
> both servlet and offline modes.
Right.
>
> Mike Engelhart wrote:
>
> > Does anyone have any suggestions on how site developers are supposed to use
> > library methods that return Node or Element objects if it's highly
> > recommended not to use the XSP variables?
>
> <xsp:expr>myMethod()</xsp:expr>?
>
> > How is it then possible to insert an element that has a different parent
> > then the XSP page?
> > Several people said that the way to insert an element was (assuming a
> > library class whose myMethod() returns an org.w3c.dom.Element):
> >
> > <xsp:expr>library.myMethod()</xsp:expr>
> >
> > This does not work. You will always get a "DOM005 Wrong document error"
> > doing this.
>
> This does work.
>
> I just checked the commit logs and I see XSPPage.java was fixed 2 months
> ago. I'm inlining a working example I just tested on my machine (see
> below).
>
> <xsp:expr>NodeExpression</xsp:expr> works in all cases, whether you
> choose
> to use a logicsheet, embed a single method call or write a long sequence
> of Java statements.
>
> > Wait a second. I though Ricardo said only the generators that get
> > created by Cocoon 2 are going to use SAX but the XSP part would still
> > use DOM??
>
> 1) XSP for Cocoon2 is completely, 100% SAX-based
> 2) This means that old XSP pages will not run under Cocoon2's SAX-based
> XSP engine
>
> 3) A separate, backwards-compatible, DOM-based version of XSP is planned
> to
> allow the existing XSP codebase to run under Cocoon2
> 4) This DOM version has not been developed yet and may not be developed
> soon
> 5) This DOM version would simply translate DOM to SAX events and is not
> guaranteed to run all existing DOM XSP code without changes
I say we forget about this back compatibility since the XSP codebase
that used such internal hooks are very little (probably only Mike got
that far off).
> 6) The code generation engine used by XSP for Cocoon2 uses DOM
> _internally_
> 7) This may or may not change in the future and has _no impact_ on how
> generated SAX-based XSP pages behave
Let's keep the cycles for making a better engine _today_ rather than do
back compatible stuff with things you should not support anyway.
The only exception should be the use of XObjects but I don't know if you
used them in Cocoon2 XSP or not.
> Regards,
>
> Ricardo
>
> ===============================================================================
> <!-- An example of importing nodes created by a different document -->
>
> <?xml version="1.0"?>
>
> <?cocoon-process type="xsp"?>
>
> <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core">
> <html>
> <xsp:logic>
> Document other = this.parser.createEmptyDocument();
> Node myNode = other.createElement("p");
> myNode.appendChild(other.createTextNode("This REALLY works"));
> </xsp:logic>
>
> <head>
> <title>X</title>
> </head>
> <body bgcolor="white">
> <xsp:expr>myNode</xsp:expr>
> </body>
> </html>
> </xsp:page>
Of course, this doesn't work if you do
<xsp:expr>other</xsp:expr>
--
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: XSP again
Posted by Ricardo Rocha <ri...@apache.org>.
Mike Engelhart wrote:
> The suggestion was "never" to use internal XSP object local variables such
> document, xspCurrentNode, etc (even though they are fully documented and
> have suggested uses for XSP writers in the XSP documentation).
XSP builtin objects can be:
1) Core, XML-related objects.
For DOM (Cocoon1): document, parser, xspCurrentNode, etc.
For SAX (Cocoon2): contentHandler, lexicalHandler, etc.
2) Cocoon's "request" and "response" objects
3) "Environment", container-supplied object
For servlets: HttpServletrequest, HttpServletRequest, HttpSession,
etc.
For offline: [command-line] parameters, target directory, etc.
For other modes: ...
If one wants to write XSP pages that are portable across XML API's, one
should encapsulate access to "core" objects by means of logicsheets
and/or
method calls (as opposed to inlined, "raw" code). If one doesn't, who
cares!
:-)
Cocoon's objects provide support for the request/response model in a way
that is abstracted from the containing environment. In particular, a
Cocoon
request is _not_ and HttpServletRequest (though it's based on it for the
servlet execution environment).
If Cocoon is run from the command line (using the offline package), then
"request" becomes a wrapper for command-line parameters, while the
"response"
ends up being written to disk files (instead of to an Http stream).
It's obvious that XSP needs a "clean" way of accessing the underlying
host
environment objects (in addition to the Cocoon's request and response
objects)
This is a matter of further discussion in the list:
What's the best way to make environment objects available to
Cocoon2 Generators? (not only to XSP, btw!)
The XSP implementation for Cocoon1 did not establish this kind of
distinction
among its builtin objects. In particular, servlet objects were given the
same
status as DOM objects. Bad, bad...
Neeme Praks wrote:
> Donald Ball wrote:
> > 6 of one, 1/2 dozen of the other. i guess i just don't like relying
> > on XSP's built in and not documented very well variables.
>
> One more question: is there somewhere some documentation about these
> built-in variables?
Stefano Mazzocchi wrote:
> No and you should not be aware of them!
> xsp were designed so that you didn't require to know how they are
> compiled to make them work. If you tie yourself to a particular XSP
> engine implementation, you're fucked!
>
> So, use
>
> <xsp:expr>yourMethod()</xsp:expr>
>
> and only this!
Using a separately written method or (better yet) using logicsheets are
good ways to "protect" you from the DOM/SAX dychotomy. Beyond that,
this discipline also allows you to write dynamic pages that can run in
both servlet and offline modes.
Mike Engelhart wrote:
> Does anyone have any suggestions on how site developers are supposed to use
> library methods that return Node or Element objects if it's highly
> recommended not to use the XSP variables?
<xsp:expr>myMethod()</xsp:expr>?
> How is it then possible to insert an element that has a different parent
> then the XSP page?
> Several people said that the way to insert an element was (assuming a
> library class whose myMethod() returns an org.w3c.dom.Element):
>
> <xsp:expr>library.myMethod()</xsp:expr>
>
> This does not work. You will always get a "DOM005 Wrong document error"
> doing this.
This does work.
I just checked the commit logs and I see XSPPage.java was fixed 2 months
ago. I'm inlining a working example I just tested on my machine (see
below).
<xsp:expr>NodeExpression</xsp:expr> works in all cases, whether you
choose
to use a logicsheet, embed a single method call or write a long sequence
of Java statements.
> Wait a second. I though Ricardo said only the generators that get
> created by Cocoon 2 are going to use SAX but the XSP part would still
> use DOM??
1) XSP for Cocoon2 is completely, 100% SAX-based
2) This means that old XSP pages will not run under Cocoon2's SAX-based
XSP engine
3) A separate, backwards-compatible, DOM-based version of XSP is planned
to
allow the existing XSP codebase to run under Cocoon2
4) This DOM version has not been developed yet and may not be developed
soon
5) This DOM version would simply translate DOM to SAX events and is not
guaranteed to run all existing DOM XSP code without changes
6) The code generation engine used by XSP for Cocoon2 uses DOM
_internally_
7) This may or may not change in the future and has _no impact_ on how
generated SAX-based XSP pages behave
Regards,
Ricardo
===============================================================================
<!-- An example of importing nodes created by a different document -->
<?xml version="1.0"?>
<?cocoon-process type="xsp"?>
<xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core">
<html>
<xsp:logic>
Document other = this.parser.createEmptyDocument();
Node myNode = other.createElement("p");
myNode.appendChild(other.createTextNode("This REALLY works"));
</xsp:logic>
<head>
<title>X</title>
</head>
<body bgcolor="white">
<xsp:expr>myNode</xsp:expr>
</body>
</html>
</xsp:page>