cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: XSP again
Date Tue, 06 Jun 2000 13:18:12 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message