- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Mon, 8 May 2006 13:33:46 +0100
- To: <www-forms@w3.org>
Stefano, > > Perhaps one angle to explore here is to work toward AJAX toolkits > > having more direct support for XForms. Many of them are now > > introducing data models, model-view binding notations, and event > > systems. If these were aligned more closely with XForms > we'd have a > > much better story not only for accessibiliy but in general... > > > > Charlie Wiecha > > Excellent point, btw it would be a great start if AJAX-based > XForms implementations offered interfaces and APIs that are > sexier to the more general AJAX crowd and/or that make it > easy to integrate with frenzier libraries... Excellent point, too, Stefano! ;) There are two parts to this; the first is to make some of the features that are being popularised in Ajax libraries available to XForms authors, and the second is to make the XForms architecture and standards available to those still unlucky enough to have to use script. ANIMATED UI Perhaps the most important feature that the current slew of Ajax libraries have that XForms doesn't is an ability to animate the display. Sure, some programmers like to dismiss this as 'eye candy', but we believe it is very important for two reasons: * asynchronous form updates do actually require additional ways of conveying change to a user. Yellow highlights are the classic Ajax way, but they are GUI-bound; an XForms solution being accessible would allow also for whispers, and so on; * for XForms to succeed it needs to show that it can do everything that authors want to do, but more easily. There is no point in ignoring the desire to produce great looking user interfaces. Having said all of this, I don't think that the animation effects themselves should be in XForms, but rather in some new CSS module. But what we should be thinking about is how to link up these effects libraries to the XForms architecture. We've done quite a lot of work in this area over the last 6 months, and although it's still work in progress, we've found that if you can do this--link the effects features to XForms' higher-level concepts--you get incredibly powerful UI at little cost. Some things that would be very difficult to maintain in 'ordinary' Ajax become ridiculously easy when using XForms with effects. To achieve this we embedded a couple of Ajax effects libraries into formsPlayer, and provided hooks so that you can make use of them from CSS, rather than having to do the usual Ajax library stuff of creating extra divs, calling functions to manipulate specific divs, registering handlers, and so on. For example, in formsPlayer you can do things like this: .pc-enabled { -event-xforms-enabled : fx-Effect-Highlight(duration:4.0 startcolor:'#89CE23'); } xf\:case { -event-xforms-deselect : fx-Effect-SlideUp(duration:0); -event-xforms-select : fx-Effect-SlideDown(duration:1); } The first rule says that when any form control becomes enabled it should have a 4 second highlight on the background. The second rule says that whenever a <case> becomes selected it should slide down, and when it becomes deselected it should slide up. In just a couple of lines of CSS you have livened up your UI, but most importantly, you are dealing with high-level XForms concepts and states (selected and deselected, enabled and disabled, valid and invalid, and so on) rather than having to mess around with divs and calling functions to affect those divs. You can see this in use in the "Introduction to XForms" tutorial on our skimstone site; there's a specific HOWTO on producing a Flickr search form, and these techniques are shown in a section called "Animating the Display": <http://skimstone.x-port.net/node/105> Note by the way, that this demo is based on one originally put together by the Flex people. Interestingly enough, as with the Ajax approach, solutions like Flex tend to bind behaviour like animations to actions such as 'user clicks the mouse'. The XForms solution is far more sophisticated since the animation is tied to the <case> changing state from deselected to selected, which means that the animation will be triggered regardless of how the state gets changed (which could be anything from a mouseclick on a <trigger> to an action handler invoked as a result of a failed submission). USING THE XFORMS PHILOSOPHY FOR AN AJAX LIBRARY Using XForms to guide the production of an Ajax library is also a very interesting area. We've pursued this by creating a so-called Ajax library that in one sense is no different to any other Ajax library...except that all of its features are based around XForms patterns and philosophies. So, for example, nearly all of the Ajax libraries have a way of manipulating a DOM, in one manner or another, but because our library is based on the XForms architecture, we use the behaviour described in <setvalue>. The idea is that since all of the behaviour of the setvalue method is defined clearly in the XForms specification--deferred updates, recalculate, refresh, datatype conversion, incorrect XPath expression, and so on--then we can leverage that documentation and get a nice and clear specification for our setvalue method. And if you do that for the whole Ajax library, you end up with some very clearly defined behaviour and interfaces. As you rightly point out, Stefano, this is very important, since current Ajax libraries are all very different in how they handle data requests, UI updates, validation, XPath, events, and so on. Our view is that even if two different XForms-based libraries were created, they would still have pretty much the same architecture, and the programmer could rely on having the same events and methods available to them. To illustrate the kind of thing we're doing, here is the setvalue function. As you can see it very closely reflects the way the XForms specification defines setvalue: this.setvalue = function(val) { try { if (m_oDataSourceNode) { if (typeof(val) == "string") m_oDataSourceNode.nodeValue = val; else m_oDataSourceNode.nodeValue = val.stringValue(); this.makeDirty(); document.UpdateManager.EnterDeferredUpdate(); m_Model.recalculate(); m_Model.revalidate(); m_Model.refresh(); document.UpdateManager.ExitDeferredUpdate(); } } catch(e) { ...error handling... } } Note that the reason we are doing this is because we believe that Ajax libraries are useful for some things, but if you are going to use them, why not use one based on standards, rather than one based on various proprietary techniques? We can therefore provide a standards-based library for those who need to use script, but we certainly wouldn't see that as a replacement for coding in 'pure' XForms; XForms mark-up remains far, far better than anything 'Ajax' has produced, or ever will. We will be doing a 'lightening demo' of the formsPlayer Ajax Library on the Ajax day at XTech 2006, later this month: <http://xtech06.usefulinc.com/2006/05/02-ajax-lightning> Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 b: http://internet-apps.blogspot.com/ w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Monday, 8 May 2006 12:35:12 UTC