forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Summary] Recent proposals around v2
Date Tue, 29 Nov 2005 17:28:12 GMT
El mar, 29-11-2005 a las 17:05 +0000, Ross Gardler escribió:
> Tim Williams wrote:
> > On 11/29/05, Thorsten Scherler <thorsten@apache.org> 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. 

:) .

.. that is the problem because we are processing the *.fv and here we do
*not* define where the stuff should go. That is defined in the contract,
so you would need to 
a) process all SAX
b) if contract then see whether @xpath exists if not just insert the
transformed contract into the stream. If @xpath exist this means we have
to alter the SAX stream (I do not know how I can do this).

> It would work like this:
> 
> Build list of insertion points

That is contained in contracts, meaning you would need to process the
whole document generate all contracts look up for insertion points and
store this 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. 

I am afraid you are right, going further you would have to either store
all contracts bean in a collection between the generation of the list
and the actual injection or create them 2 times. ...and this I am afraid
will not gain speed.

> It may be better to finish the approach 
> Thorsten is using and address this if we see a big performance hit.

Yeah I am really keen to finish a first *working* version that you guys
can get your hands on.

...maybe there is something in the code where I overcomplicated
things. ;-)

Thx for your input Ross, Tim and David.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message