- From: T.V Raman <raman@google.com>
- Date: Fri, 25 Aug 2006 08:06:49 -0700
- To: monterro2004@tiscali.co.uk
- Cc: mark.birbeck@x-port.net, kratky@us.ibm.com, www-forms@w3.org
JSON is a fine S-Expression representation --- and in some respects a better S-Expression for pure data than XML. Another interesting XForms extension that we should look at is the ability to bind to JSON data for instance values --- Given that XForms has a clean Data vs Interaction separation, this should actually be quite easy to do Francisco Monteiro writes: > > 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/ -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman
Received on Friday, 25 August 2006 15:08:32 UTC