Tim Williams wrote:
On 11/29/05, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
El mar, 29-11-2005 a las 10:04 +0000, Ross Gardler escribió:
David Crossley wrote:
Thorsten Scherler wrote:
...
Eager to hear what u think how we can have the xpath injection with SAX.
The problem I have is since I added the injection stuff it is not
working anymore like I expected, so I am not keen to check something in
that is not working ATM.
Transformers are SAX events to new SAX events, right? Couldn't we
have a list of XPath-insertion points we're interested in and in the
event handler test to see if the current element happens to be one of
our insertion points? It'd be similar to some of the existing Cocoon
Transformers (e.g. CInclude) but instead of testing for the element
names as constants we'd have to be more clever in not only evaluating
against the element name but figure out how to evaluate against our
xpath insertion points (I'm not sure how much context we get with a
SAX event so maybe this test isn't possible).
This thought may be wildly wrong since I'm doing a lot of guessing not
having seen the code your working with, but this just came to mind
while I was reading your previous code snippet and this latest
explanation.
Yeah, this is pretty much what I meant when I suggested that we could
process the includes as we find them. It would work like this:
Build list of insertion points
SAX Event
-> is it an element requiring an insertion?
Yes
-> process the inserted document and insert the resulting SAX events
No
-> process as normal
I have vague recollections of a cocoon component to pass SAX events
directly from one source to another. If that recollection is correct
then the hard part would be the processing of the insertion.
However, since we need to build a list of insertion points in advance we
may not gain any performance. It may be better to finish the approach
Thorsten is using and address this if we see a big performance hit.
Ross
