Use a flowscript to parse pipeline of choice into dom, process there
and feed result back into sitemap.
HTH
Thomas
Am 24.08.2006 um 13:26 schrieb [EMAIL PROTECTED]:
-------- 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
