cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: XSP again
Date Tue, 06 Jun 2000 09:58:20 GMT
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,
   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
method calls (as opposed to inlined, "raw" code). If one doesn't, who

Cocoon's objects provide support for the request/response model in a way
that is abstracted from the containing environment. In particular, a
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
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
environment objects (in addition to the Cocoon's request and response

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
among its builtin objects. In particular, servlet objects were given the
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?


> 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 was fixed 2 months 
ago. I'm inlining a working example I just tested on my machine (see

<xsp:expr>NodeExpression</xsp:expr> works in all cases, whether you
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
   allow the existing XSP codebase to run under Cocoon2
4) This DOM version has not been developed yet and may not be developed
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
7) This may or may not change in the future and has _no impact_ on how
   generated SAX-based XSP pages behave



<!-- An example of importing nodes created by a different document -->

<?xml version="1.0"?>

<?cocoon-process type="xsp"?>

<xsp:page xmlns:xsp="">
      Document other = this.parser.createEmptyDocument();
      Node myNode = other.createElement("p");
      myNode.appendChild(other.createTextNode("This REALLY works"));

    <body bgcolor="white">

View raw message