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

[<ha...@id...>]

Hi,

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 aborting =
the
parse and giving the end-user an error message. Based on this, several =
of
the helper objects (DataParser, LayoutBuilder, ...) throw an =
XSWTException
when they cannot return an object, e.g. when an ID cannot be resolved or =
a
tag cannot be resolved to a class. This design makes it cumbersome to =
have
several strategies for interpreting a tag/attribute, since each strategy
must be wrapped in a try/catch block.

Example: In XSWT a LayoutBuilder is used for constructing an object from =
a
tag/class name/Class. If this fails, I want to check if the tag is an ID =
(as
suggested in a previous message), in case the corresponding object =
should be
used. However, instead of checking if the LayoutBuilder returns =
non-null, I
must wrap the call with a try/catch and use the DataParser (again =
wrapped in
a try/catch):

		XSWTException xe =3D null;
		try {
			result =3D layoutBuilder.construct(klass, parent,
style, widgetName, parser.getColumnNumber(), parser.getLineNumber());
		} catch (XSWTException e1) {
			xe =3D e1;
		}
		if (result =3D=3D null) {
			try {
				result =3D dataParser.parse(tagName,
Widget.class);
			} catch (XSWTException e) {
			}
		}
		if (result =3D=3D null) {
			throw (xe !=3D null ? xe : new XSWTException("No ID
named " + tagName));
		}

This would be a lot more elegant if either 1) the check for ID was moved
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.

Another question concerning the parser: We currently use the KXML =
parser,
but a switch has been suggested. Does this also imply switching from =
pull
parsing to one building an element tree? 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 interface
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?

BTW, it may be desirable to have two interfaces, IParser and ITreeParser
(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, =
although
with a more limited XSWT feature set.

Hallvard

---
Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology