Sebastien Sahuc wrote:


Stefano Mazzocchi wrote :

> > Original thought on using SAX based XSP engine instead of DOM :
> >
> > When the SAX events for the original XSP document is
> submitted to the
> > XSP
> > transformer, then when the 'processing intruction SAX event' is
> > thrown,
> > the method 'processingInstruction(target, data)' acts as a
> controller
> > and
> > set a new transformer on the fly that correspond to the stylesheet
> > declared in the PI. Therefore all the following SAX events are
> > forwarded
> > to the new transformer we've just set up.
> > Then this later transformer send its result SAX events to the XSP
> > transformer which acts one more time as a controller. And we repeat
> > the
> > loop until there is no more PI to handle.
> what the hell are you talking about??
> are talking about C2 or C1? C2 doesn't have any PI reaction
> and we won't
> touch C1 with big changes... am I missing something here?

Sorry for misusing the processing-instruction term. Indeed by processing-instruction I meant the core and built-in logicsheets triggered by the presence of their namespace in the XSP page.

I don't know why I had the PI in mind since I've never used them so far. Strange..,, I must have be infected by the Reactor pattern :-)

Anyway, there is quite some performance problem in the current Cocoon2's XSP engine by the simple fact that it's DOM based. That's why I suggested to definitely get rid of DOM in the XSP code...

but it's DOM-based only at compile-time, at the run-time it's SAX-based.




> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------