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 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 > > > > 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. 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? > > 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 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 > > =============================================================================== > > > > > > > > > > Document other = this.parser.createEmptyDocument(); > Node myNode = other.createElement("p"); > myNode.appendChild(other.createTextNode("This REALLY works")); > > > > X > > > myNode > > > Of course, this doesn't work if you do other -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- Missed us in Orlando? Make it up with ApacheCON Europe in London! ------------------------- http://ApacheCon.Com ---------------------