Release 1.1 : Why DOM not SAX ?

[blambeau]

First of all, thx very much to the GWT team ! The new version seems
really promising (many of us will deprecate many personal widgets,
that's cool ...).

Just a little question about the release 1.1,

why the GWT team did choose a DOM parser instead of a SAX parser for
xml documents ?

I don't think DOM is a bad choice at all, but in many cases, I would
prefer using SAX parsing instead of loading the entire XML document in
DOM objects that I never use as such ...

blambeau

[IamRobe...@gmail.com]

> why the GWT team did choose a DOM parser
> instead of a SAX parser

Technically speaking the DOM isn't a parser, and usually uses something
like SAX to create the DOM. If you look at the code, the parser they
used was actually the parser built into the browser. So they actually
didn't write a parser at all, just DOM objects on top of the parser.

As far as actually building a parser (SAX or other) to run in the
browser, I think that it might be a little big, and probably fairly
slow. Abound 6 years ago there was a spec floating around called
Minimal XML, which removed the all but the essential elements from XML
(http://xml.coverpages.org/minxmlspec20000413.html). Maybe it wouldn't
be too hard to write a parser for that.

Rob

[br...@google.com]

The browser platform is a strange place indeed, and the laws of physics
are a little warped. The basic rule of thumb is this: if the browser
can do something for you in native code, let it.

In a JVM running on a server, using SAX directly is really fast because
it does less work than creating a full-blown DOM since, as Rob pointed
out, a DOM is usually built by invoking a SAX-based parser then doing
more work on top of that.

It turns out that what the browser gives you natively is a DOM, and
there is no SAX parser available natively. To provide a SAX-style API
for GWT would basically mean writing code to parse XML in Java(Script),
which would most likely be much slower than using the browser's native
DOM. JSON demonstrates the same principle. JSON uses eval() versus
hand-parsing a JSON structure as a string. eval() will be much faster
since it's native code.

While normally we're trained as Java programmers to do the efficient
thing (SAX) even when it's less convenient, in this case you can use
the DOM without guilt.

-- Bruce

[blambeau]

Thanks very much for your answers ! seems clear now ...

blambeau