Re: [Xswt-developer] the XML parser

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

Hallvard Tr=E6tteberg wrote:
>>> Phrased another way: Do we still have to base our design on a one-pas=
s=20
>>> parsing process?
>>>      =20
>> Not in my book.  For modules, I think we need some kind of=20
>> in-memory tree we can use to represent XSWT in an=20
>> intermediate form.  Naturally, we'll walk that tree as many=20
>> times as the module is used.  Or the style is used.  Or=20
>> something like that. :-)
>>    =20
> OK, this is similar to how I view it. In the case we stick to a pull pa=
rser,
> we may build the tree ourselves, but it's far better to (re)use en exis=
ting
> parser.
>  =20
Agreed.
>> if we can find a way to not need swappable parsing layers,
>> I would prefer to not have a swappable XML parser API.
>>    =20
> I think understand what you mean. What we could do us define a minimal =
API
> that may be wrapped around an existing parser, so we have something to =
work
> on until we settle on the small one. E.g. we define IMinimumParser, wra=
p it
> around XOM (which is the one I'm familiar with), and rewrite XSWT to us=
e
> IMinimumParser. This will let us work on the stylesheet design, without
> becoming too parser-specific. When we find our desired parser, we first=
 wrap
> it in a IMinimumParser adapter, and if desired we migrate to an interfa=
ce
> fitting that parser better, or to that the parser's native API. The cod=
e
> using the parser is anyway so local that there's not much work migratin=
g as
> long as it is based on an in-memory tree. Of course, this process may b=
e
> simplified if we can settle on the parser right away.
>
> Based on my knowledge about how the current parser is used, we need met=
hods
> for:
>
> - loading the tree from a URL or InputStream: rootElement =3D
> parser.build(InputStream)
> - getting the namespace uri and name of an element:
> element.getNamespaceURI() and element.getName()
> - getting the child elements of an element: element.getChildElementCoun=
t()
> and element.getElement(int)
> (I don't think the current design requires getting an element's parent)
> - getting that attributes of an element, and their name, namespace uri =
and
> value of an attribute:
> element.getAttributeCount() and getAttributeName(int),
> getAttributeNamespaceURI(int) and getAttributeValue(int)
> - getting the text of an element: element.getText()
>
> It wouldn't take much time defining such an experimental interface and =
wrap
> it around XOM. Rewriting XSWT shouldn't be that hard either. Although X=
SWT's
> code is complicated from using a pull parser, the logic is fairly
> straight-forward.
>  =20
I'm still of two minds about this.

One of the things we all like about XSWT is that it _isn't XUL_.  It=20
comes from a "less is more" design philosophy.  Lightweight is better. =20
Avoid abstraction.  Tight coupling is a feature, not a bug. =20
37signals.com.  XSWT itself is small enough that the overhead for=20
abstraction is often not worth the weight.

On the + side for this idea, having such a layer would make this=20
migration easier because we could first introduce the XML parser=20
abstraction layer while keeping KXML, then swap out KXML with something=20
else.  And then migrating again would be even easier, should we ever=20
need (or want) to do it.  And as long as we want to stay relevant to=20
embedded folks, it seems that we will always be using non-mainstream=20
parsers...

If you feel strongly that having the abstraction is worth more than the=20
weight it would add, I think I'll defer to your opinion.  If you're not=20
totally convinced yourself, then let's keep discussing it.


Regards,

Dave Orme