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 > > yourMethod() > > 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? myMethod()? > 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): > > library.myMethod() > > 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). NodeExpression 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 =============================================================================== Document other = this.parser.createEmptyDocument(); Node myNode = other.createElement("p"); myNode.appendChild(other.createTextNode("This REALLY works")); X myNode