RE: XForms schema: mustUnderstand and extension

 
The way facileXForms implements extensions is via a "bridge", since most of
our extensions are either Dojo or Yahoo (YUI) composite widgets, the bridge
acts as the controller to the view and model. The bridge has the same logic
as a group element and then uses publish/subscribe paradigm for all its
children . This way any framework can easily be "plugged" in.
Also we did this, because we use JSON as our data interchange. Every one
wants JSON today.

<my:controller ref=".." id="controller1">
<dojo:widgets
<yui:widgets

<xf:action all events as per group element

facileXForms from an Xforms perspective is only interested in the model, our
Xforms with XML Events (client end ) is the controller.

When we have finished our implementation we will support fully Windows
Workflow Foundation concepts (client and server end).The Xforms model markup
is far simpler then the foundations XAML, we can transcribe between the two.
So the logic goes we will be supporting

1] Sequential Workflows
2] Machine state workflow with dynamic updates to single instance of
workflow
3] Data driven workflows

We should all thank Microsoft for bringing Workflow concepts to the masses.

See some of the many example I have sent to the group
Francisco



-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Birbeck
Sent: 24 August 2006 13:11
To: Jan J Kratky
Cc: www-forms@w3.org; w3c-forms@w3.org
Subject: Re: XForms schema: mustUnderstand and extension


Hi Jan,

> Does anyone disagree that extension
> should be permitted as a child of *any* XForms element? What about as 
> a child of elements (i.e. setvalue) whose content models currently do 
> not permit other elements as children? Are multiple extension elements 
> permitted as a child of the same XForms element? Can the extension 
> element appear anywhere in the sequence of child elements?

It would be interesting to see how people have implemented xf:extension, in
order to see what the options are.

What we've done in formsPlayer is to treat xf:extension just like an
xf:instance that was 'local' to the parent element. At run-time we parse the
contents of the xf:extension, and then create an attribute called
'extension' on the parent node, which contains a DOM with the contents of
the xf:extension.

This is then available to any script, in particular to our XBL widgets,
which makes it a very convenient way for an author to provide extra data for
run-time use.

Taking this approach does mean for us though, that it would be more logical
if only one xf:extension was allowed per element. But given that
xf:extension wasn't defined very clearly in the first place, I'm not at all
saying that our approach is supported by the spec--simply that this is the
approach we took, to try to make something useful from xf:extension.

I'd be interested to hear how others have made use of xf:extension.

Regards,

Mark

--
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/