cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Re: How to intgrate existing XML-Doc in XSP
Date Sun, 15 Oct 2000 21:30:31 GMT
Thorsten Mauch <> wrote:
>I have already classes that produce XML-Documents but
>I don't know how to integrate them into the XSP. I tried the
>following code:
><?xml version="1.0"?>
><?cocoon-process type="xsp"?>
>   language="java"
>   xmlns:xsp="">
> customer   =
>     try{
>       document= customer.getXMLDoc();
>     }
>     catch(Exception ex){}

I'll answer your question in a second, but first this -

Note: This blank catch clause is bad practice - it hinders debugging. XSP 
lets you throw anything, so just get rid of the try and the catch! If you 
want to hide the gritty details of errors from your end users, disable 
handle.errors.internally in instead - then you can flip 
debugging on and off by changing one line, instead of laboriously changing 
various bits of code (imagine if you have 100s of empty catch clauses in a 
complex system, and you don't know where the problem is - pain eh?)

>but if I inspect the generated Producer the code appear in
>the declaration section. But what i want is to override the
>populateDocument() method.

You can't do this, basically, because XSP always generates one and you can't 
override a method in the same class. Well you could try and comment it out 
in the generated code, but that's a REALLY bad hack and if you're going to 
go that far it would be easier to write a Producer anyway!

>How can I archive this ?

There are two problems here.

1. All XSP pages require an explicit root element - this is how it 
distinguishes between page-generating code (which goes in the page root 
element) and declarations (which go outside).

Workaround: put the logic inside a dummy <page> element which will be 
overwritten. Or, better, mandate that all documents will have <page> as 
their root, then it won't be quite so confusing.

2. You can't just reassign the document variable - in Java parameters  are 
passed, in informal terms, "by value" (in this case the value of the 
reference to the document object), so the reassignment would only have an 
effect inside the populateDocument method, but Cocoon would actually still 
use the original document (which would be empty and probably invalid) after 
that had returned.


Document doc2 = myBean.getDocument ();
// overwrite dummy root <page> element
document.replaceChild (xspCurrentNode, doc2.getFirstChild ().clone (true)); 
// do a deep clone

If you wrote a producer or producers instead you wouldn't have either of 
these inconveniences, but then the invocation would be different 
(myfile.xml?producer=myproducer, which isn't ideal). This messy invocation 
will go away in Cocoon 2 by the way.

Also, you are generating an org.w3c.Document, right, not a String? :-)

Get Your Private, Free E-mail from MSN Hotmail at

Share information about yourself, create your own public profile at

View raw message