Re: trees & tables

Guy,

> I've been looking at using xforms and SVG for an application I'm
developing.

in general, that's great. SVG+XForms is a exciting field that needs more
exploration.

> Although encouraging there doesn't seem to be a tree representation for
data
> in xforms? It seems complicated to construct in SVG. How could I do it?

Whereas "table controls" should work in XForms (see below), indeed
tree controls are not covered by XForms 1.0. This is, however, a general
issue, and I think it is really good to open up this issue now and see what
we could possibly do in XForms 2.0:

The tree control issue has been around for a while. I think an early draft
of the XForms 1.0 Requirements document even listed tree controls for
XForms 1.0, it has been on our minds for a long time. We ended up not
doing tree controls, one of the main reasons being that tree controls are
not such a concrete thing like the other form controls and there are many
different interpretations of what a tree control ought to be. Let me try
and walk you through some of the issues:

Since XForms is data-driven, what kind of data would be bound
to a tree control?

Well, isn't XML itself all about tree structures? OK - so I bind a sub-tree
of my instance to the tree control widget. What happens now? Do I get
something like the IE collapsable XML source tree view, whereas
everything can be edited? How do I style that in general, and how can I
style, say, the attribute value in one tree node be different than the
element's content?

Then we realize that tree controls are in fact *aggregate* controls. That
perhaps you could construct a tree controls out of smaller, more atomic
form controls in XForms - and in fact you can. Even though tree controls
do not exist as a seperate, single control that you might look for when you
want to see it from a design perspective, XForms in a way is all about tree
controls since the data it processes is a tree: You can bind a
form control to every leaf of that tree, and get, a tree control.

You could go on and, say, write an XSLT that takes an arbritrary
XML document structure and generate an XForms out of it instead of
just a HTML view mode - the well-known IE xml tree source (that is
generated exactly this way inside IE, via XSLT) would then automatically
become a generic XML editor.

In this case we would perhaps rely on the <html:ol> semantics to visually
display discs or numbers in front of every tree node and use the indents
to visually show the branching, so this visual implementation is up to the
host language and not XForms itself.

In SVG you need to look for something equivalent, perhaps really using
XSLT to generate a SVG+XForms document whereas every tree node
is indented relative to its position in the data tree.

The collapsing functionality, clicking on a node to visually open and close
subtree is perhaps really the missing thing, and this is what most people
would expect to get from a single, distinct tree control if there was one,
and
assume that this UI functionality would be the legitimation for such a
control.

There is the solution to work with Events and relevant in XForms
1.0, that a sub-branch only becomes relevant if you click on a trigger next
to each node or listen to the DOMFocusIn and DOMFocusOut events
for each node.

This might give you the functionality of "opening" and "closing" nodes based
on the user actions, however it will still not visually draw on the screen
the
nice boxes with a + or - sign and even draw those lines between those
boxes for each node that visually immediately make it resemble a tree.
This one thing is not covered, whereas I do believe everything else is there
in XForms 1.0 to build custom, aggregate tree controls using the existing
XForms 1.0 methodology.

What could be a thing to ask for XForms 2.0 to do, is whether the author
could give a hint to the processor that a certain aggregation of UI controls
is meant to visually be a tree control - which would be something in the
spirit of the appearance attribute on select, that really just gives a hint.

However, I guess this would be very hard to implement, since it gives quite
a lot of implication for a processor and assumes things that depend on the
host language. Visually drawing connecting lines to enforce the tree
relationship on top of a custom aggregation of controls might work for
XHTML+XForms and SVG+XForms, but other UI languages, like SMIL,
might not be able to deal with such a thing at all. One the central
questions
might be to ask whether XForms itself could possibly do anything more than
it does today or whether perhaps specific host languages should add
a UI manifestation of a tree control to complement the already existing
underlying data modelling for trees in XForms. XHTML in
general is well prepared for this given the existing ol and ul idioms and
the proposed nl extension for XHTML 2.0. What additions to SVG could
be done to help here would perhaps be good thing to investigate.

Now revisiting my initial statement, that tree controls are not covered by
XForms: A tree control itself does not exist, and it is to be argued
whether such a thing could exist at all, given the vagueness of its
definition and it's apparent nature of being just an aggregation.
However XForms 1.0 from the data modelling side is ideally suited
to deal with trees since XML is nothing but trees - then how much
this can be visually reflected as looking and feeling like a tree control
ought to be up to the host language embedding XForms.

> Also the list control equiavlent. Do you just use xhtml or html tables
with
> some js to manipulate the data?

No. This is where XForms 1.0 really does fully cater for this thru the
repeat construct. We follow a similar thought pattern as before:

You can use repeat to bind to a nodeset, and the repeat cursor allows
the user to (visually) highlight one item of that repeat, whereas the repeat
really repeats the host language UI markup embedded in that repeat
element for every occurance in the homogenious collections of nodes
bound to it in the instance.

The host language can now use one visual row in a table construct to be
embedded in the repeat element, the table row then visually repeats for
each item found in the instance, making it look like a table, allowing the
user to highlight a row, and to perform actions on that selection.

The fact that it really looks like a table is here again the host language,
and in XHTML, tables come in handy, in XSL-FO the similar table construct
makes this job very easy, too. One could also use CSS tables to get similar
rendering effects over arbitrary XML data.

> Any guidance appreciated.

Hope this helps.

- Sebastian

Received on Sunday, 22 December 2002 11:06:27 UTC