Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (asf.osuosl.org: domain of williamstw@gmail.com designates
 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LW8qE8IfReapJIY52RmJ3akOUmbfoL/aSgRAInup5uE5QA7bn1IJEVBqUkwz9FK2YTHDOY03bm6K0L8jyHMegxd2Uo6j+OtT6pDVsdAlBrzCSKpdlgy2D82wjzhwZFqMEP8Qc1U8AqGg8mySJQ2n48KgsrMaqpGNlRI4C28zTx4=
Message-ID: <499888440511290853k2992c8ebq7cd006ae9fdff321@mail.gmail.com>
Date: Tue, 29 Nov 2005 11:53:39 -0500
From: Tim Williams <williamstw@gmail.com>
To: dev@forrest.apache.org
Subject: Re: [Summary] Recent proposals around v2
In-Reply-To: <1133278663.8200.62.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1132697107.13942.8.camel@localhost>
	 <200511232050.01985.diwaker@apache.org>
	 <1132829182.8222.34.camel@localhost>
	 <20051125044435.GA4445@igg.indexgeo.com.au>
	 <438C27A6.1030106@apache.org> <1133278663.8200.62.camel@localhost>

On 11/29/05, Thorsten Scherler <thorsten@apache.org> wrote:
> El mar, 29-11-2005 a las 10:04 +0000, Ross Gardler escribi=F3:
> > David Crossley wrote:
> > > Thorsten Scherler wrote:
> > >
> > >>No, I had a simple transformer that was "just" transforming the
> > >>contracts into the position where it could be found.
> > >>
> > >>I wanted to check that in but started to clean the code and added
> > >>comments. Doing this I then started to apply recent proposals and it =
is
> > >>not that easy. ;-) The challenge is to create a DOM result with SAX
> > >>events out of attributes of contracts and the structure path of the
> > >>hooks and then inject it again in the SAX result stream. I hope to ha=
ve
> > >>a first version ready after the weekend.
> > >
> > >
> > > I don't know what i am talking about, but ...
> > >
> > > Will creating an intermediate DOM cause a bottleneck?
> >
> > I've been waiting for a response from someone who knows this stuff
> > better than me, but it's not come. I'll try a response and wait for a
> > more educated fellow to tell me I'm wrong ;-)
> >
>
> Sorry no time ATM (...to tell u u're wrong). ;-)
>
> > Yes. It will cause a bottleneck. Those who know the early Cocoon will b=
e
> > aware that in Version 1.0 it used DOM in 2.0 it moved to SAX because of
> > performance problems with DOM.
>
> In general I agree, but we are speaking here about *some* code in *one*
> transformer (which is SAX based).
>
> >
> > My intention was to see the code and then try and make a suggestion as
> > to how we can avoid this bottleneck. I'm guessing there is a good
> > technical reason for needing a DOM.
> >
>
> Hmm, actually yes. Do you remember the @xpath injection? How can you do
> this via sax events. ATM I am generating the response in DOM to inject
> all the xpath stuff (which is harder that I thought) coming from the
> contracts.
>
> > Perhaps Thorsten could let us know more about this problem and see what
> > we can come up with as a community.
> >
>
>
> 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.

--tim