cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: [Moving on] SAX vs. DOM part II
Date Tue, 25 Jan 2000 04:40:03 GMT
Donald Ball wrote:
> 
> I concur. We need SAX for fast transport between layers and DOM access
> routines for use by layers if the layer prefers to work in DOM. How hard
> could this be? The algorithm seems to be pretty simple.

It's fairly trivial if you convert a whole pack of SAX events (from
startDocument() to endDocument()) into a FULL DOM tree. It gets a little
bit trickier (just a little bit), if you want to have only fragments of
DOM:

I have this document:

<image width="100" height="100" background="#000000">
  <layer method="multiply" opacity="100%">
    <text x="10" y="20" color="#ffffff">
      Print this!
    </text>
  </layer>
  <layer method="multiply" opacity="100%">
    <text x="11" y="21" color="#999999">
      Print this!
    </text>
  </layer>
</image>

I can imagine that the <image> and the <layer> stuff are handled
directly using SAX events, but I want to pass a DOM fragment (an Element
and all that is included into it) to the object handling the <text>
element...

I'm about to complete it, and the implementation will be in CVS
tomorrow...

> If a layer knows
> that it's going to be accessed by DOM, then it could just catch incoming
> SAX events and store them in a list. If and when DOM access occured, you'd
> wait for all SAX events to com in and then either just scan through the
> list looking for nodes or turn the list into a tree. Events would be sent
> out either as incremental processing was done (for SAX processors), or the
> node tree would be serialized as SAX events once DOM processing was
> complete (unless you know the next layer wants DOM access, in which case
> you could maybe just pass on the DOM object.

Yep... The only thing is that both processors (the idea was to call them
Filters, am I right?) are DOM-based, we'll end up building two DOM trees
for the same stuff. The biggest problem (right now) seems to be XSLT,
but I bet that Scott will come up with something nice...

> (sorry to be so pedantic, but I'm trying to convince myself as much as
> anyone else)

:)

> Although, you know, it's not DOM that my processors might want so much,
> anyway, but a _good_ tree-based API. Personally, I think DOM is a poorly
> designed API and that one could do much better (hell, we could even come
> up with the new de facto replacement for tree-based XML API).

I share your opinion on the DOM API, I wouldn't did it in that way, but
those are personal ideas. Anyway I do understand that right now DOM is a
standard, and it's more or less supported everywhere. Designing another
would be overkilling, and the task of porting already built components
from DOM to "our nice dom" would be a too big task.
The best thing is "just stick with SAX" :)

	Pier

-- 
--------------------------------------------------------------------
-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<mailto:pier@betaversion.org>    <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------


Mime
View raw message