-------- Original-Nachricht -------- Datum: Wed, 23 Aug 2006 00:58:14 -0400 Von: [EMAIL PROTECTED] An: [email protected] Betreff: Re: creating DOM out of SAX event? > On 8/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > can someone tell me if its possible to create a DOM out of a currently > present SAX event in a pipeline (before the pipeline becomes serialized)? > Not to confuse you, the pipeline would for sure use the current SAX event for > further computation and not the DOM. > > In other words, I'd like to have the current status of the pipeline (so > the current SAX event) as kind of input stream for the generation of a DOM > which becomes instantiated in e.g. an XSP file within this specific > pipeline. > > It depends on your definition of "pipeline". > In a Lenya/Cocoon Pipeline (which is the topic of this ML), extend the > AbstractDOMTransformer. I have used it for Transformers which use the > whole Document. > > If you are working in SAX events, and want to retrieve the DOM for the > current node, use a recorder. startRecording() in the startElement() > and DOMFragment = endRecording() in the endElement(). See: > http://cocoon.apache.org/2.0/apidocs/org/apache/cocoon/transformation/AbstractSAXTransformer.html
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
..my defininition of pipeline. Hm, ok I see, maybe this word was chosen wrongly in this context. What I want to convert to a DOM is the last SAX event bevore the serialization happens. Further, I want to do some computation on this DOM. But this computation shouldn't (or better must not!) influence the output which becomes serialized in the next step. At the moment I'm not sure which of the two solutions you offered in your last mail would suit the above benefit, because on one hand I am within a pipeline, but on the other I am also within a SAX stream at this moment - right? Maybe its even possible to perform all this much easier, but you are the experts and thats the reason for asking ;-).
You could use either method, unless you want the root node, then you need the former. If you want something to happen every time a specific node appears, and do not want anything else to happen inside those nodes, use recorders inside a SAXTransformer. The recorder traps all the descendants of the node and returns a DocumentFragment. You can return the DocumentFragment to recreate the original Document. I was not able to trap the root node and return the original Document. If you want the root node, or want to return the whole document and are willing to handle processing with DOM, use the DOMTransformer. It starts with the Document object, and you can do what you want with it (such as writing it to a file) or to it (such as changing the output). In either case, write down what you expect to happen. Then decide if it all needs to happen in a single Transformer. Splitting the function into two or more Transformers often simplifies the issue. The migration function from 1.2 to 1.3 uses 4 transformers for the Documents, 3 transformers for the resources (Assets), merges the results together, transforms them again, and calls JavaScript Flow which calls another transformer as it writes files. I am certain it is possible to handle it with much fewer transformers, but I would still be working on it months after it was completed. My intuition suggest you probably want to add a <map:transform type="mytransformer"> to your Lenya/Cocoon Pipeline. The type would be for a new DOMTransformer that does something, and returns the original org.w3c.dom.Document parameter. The new Transformer must be defined in an XMAP's components/transformers section. It is very possible your solution could use the standard Transformers and a few thoughtfully designed XSLTs. It could also use JavaScript as in the migration function. Lenya and Cocoon provide much functionality, and adding a new Transformer is rarely necessary. I wrote two (both extending AbstractDOMTransformer): - CreateRevisionTransformer must decide if several files must be created or changed. - VirtualTransformer allows creation of a Virtual Document. Both functions could have been handled with Pipelines and JavaScript, but they should be used often, and it is simpler for developers to have the code packaged into a single function. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
