Re: [Xswt-developer] Design of XSWT: 1) use of XSWTException and 2) the XML parser

[David J. O. <dj...@co...>]

I also would value anybody's input to these questions, particularaly Jan=20
and Yu since you two have helped a lot in the past.

Hallvard Tr=E6tteberg wrote:
> The current design of XSWT uses XSWTException to signal that something =
is
> wrong during a parse. This is usually fatal, i.e. it results in abortin=
g the
> parse and giving the end-user an error message. Based on this, several =
of
> the helper objects (DataParser, LayoutBuilder, ...) throw an XSWTExcept=
ion
> when they cannot return an object, e.g. when an ID cannot be resolved o=
r a
> tag cannot be resolved to a class. This design makes it cumbersome to h=
ave
> several strategies for interpreting a tag/attribute, since each strateg=
y
> must be wrapped in a try/catch block.
> <snip/>
> This would be a lot more elegant if either 1) the check for ID was move=
d
> into LayoutBuilder, in case it must take the tag as input, and not the
> object class, or 2) change the protocol to use null instead of
> XSWTException.
>
> I go for 1), but I thought I'd ask the list.
>  =20
(1) sounds fine to me.
> Another question concerning the parser: We currently use the KXML parse=
r,
> but a switch has been suggested. Does this also imply switching from pu=
ll
> parsing to one building an element tree?
Yu (who works for Nokia and I think probably knows a thing or two about=20
small devices) suggested that we use the tree parser from the eRCP=20
project at Eclipse.
> The difference is big if you want
> to be able to save a reference to a node (e.g. style node) and parse it=
 one
> or more times later. Ideally, the parser should live behind an interfac=
e
> that makes it easy to switch parser, but it's difficult to make a pull
> parser look like a tree builder (the other way around is easy).=20
>
> Phrased another way: Do we still have to base our design on a one-pass
> parsing process?
>  =20
Not in my book.  For modules, I think we need some kind of in-memory=20
tree we can use to represent XSWT in an intermediate form.  Naturally,=20
we'll walk that tree as many times as the module is used.  Or the style=20
is used.  Or something like that. :-)
> BTW, it may be desirable to have two interfaces, IParser and ITreeParse=
r
> (extends IParser), and define that some features require the latter. A =
small
> and fast pull parser for a limited device could then still be used, alt=
hough
> with a more limited XSWT feature set.
>  =20
Yu, do you see any reason to keep a pull parser as an option?

I would prefer to have as little abstraction as possible around the=20
actual parser and choose a small fast parser that has a good likelihood=20
of being around for awhile.  Or to say the same thing differently, if we=20
can find a way to not need swappable parsing layers, I would prefer to=20
not have a swappable XML parser API.  (Hallvard, if you disagree, please=20
feel free to do so publicly and we'll talk until we reach a consensus.)


Best regards,

Dave Orme