implementors proposal for load/@show="embed"

With this mail (sorry for the long read) i'd like to describe our
experiences with a 'new' XForms extension we've implemented that might
be worth considering for the future feature list.

Motivation:
we got a project where a huge XML Schema is in use with about 250
different data structures that can be nested in thousands of
combinations. Some of the structures are even circular which made a
fully generative approach hard to follow. Further the depth of nesting
of the structures is not predictable and theoretically unlimited.
Straight generation of XForms for this schema would have lead to forms
with thousands of lines of markup ( > 15.000) using huge switches or
prototype instances. This simply seemed not practical with regard to
parsing times, memory consumption and response times.

To circumvent these problems we followed the idea of dynamically
loaded subforms and more concretely put the idea into practice that
was described by Mark Birkbeck in his blog article about the extension
of the load action
(http://internet-apps.blogspot.com/2006/08/using-subforms-in-xforms.html).
After a short discussion with Mark we felt that this tiny extension of
the XForms standard could do the job.

More concretely we extended the load action to support the value
'embed' for the 'show' attribute like so:
<xf:load show="embed" targetid="foo" resource="subforms/foo.xhtml#someId">
...

The implementation was actually much easier and (as we feel) nicely
aligned with the standard than we initially expected. When the load
action fires we resolve the resource just like we'd do for a 'normal'
load, then import the parsed XML into our host document DOM and
replace the Node referenced by the targetid attribute. Then we trigger
initialization as we do for a normal XForms document. This means we
fire all the model init events so that the subform behaves just like
any other normal XForms document. Of course this means that we import
a complete XForms model and UI and not just a part of UI markup. From
then on all processing continues as normal. This also implies that the
subform is just a normal XForms that can be run standalone
(independent of the master) which is great for testing and re-use.

For this to work there's only a small price to pay: the XForms should
be authored (generated) so that the model and UI live under a common
parent element (as is the case for X4H). The targetid must be
somewhere in the body of the master form but outside the model section
of the master form (if that happens to be in the body).

Our current implementation runs smoothly and allows us to meet the
requirements outlined above. We doubt that we've been able to master
this project without this extension. Of course it also raised new
questions about the inter-model communication and unloading of
subforms (we've developed but not settled some alternatives) but that
are maybe better discussed in a separate mail if there's a general
interest for this approach.

Thanks to Mark for the inspiration and hoping for your comments.

Joern Turner

Received on Thursday, 18 June 2009 21:45:23 UTC