- From: Charles F Wiecha <wiecha@us.ibm.com>
- Date: Tue, 5 May 2009 09:43:16 -0400
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: public-xg-app-backplane <public-xg-app-backplane@w3.org>, Ulrich Nicolas Lissé <unl@dreamlab.net>
- Message-ID: <OFC394FE82.B629076E-ON852575AD.004977EA-852575AD.004B34B7@us.ibm.com>
So in my original note I hinted that we could discuss the desirability of calling JS functions from an xf:call event handler...I expected just this discussion and wanted to be clear that my code was a temporary fix for not being able easily to attach event handlers in XHTML files in FF3...that platform doesn't evaluate getElementByID for non-HTML/XUL elements in XHTML documents (as I understand the problem)...so this code: <xf:call ev:event="DOMActivate" fn="myscriptfn"/> was a work-around in place of registering myscriptfn as a DOMActivate event hander directly (which I did in an earlier version by truely hacking how I found the relevant element to observe... Within myscriptfn of course you have to be careful to flag rebuild as required if doing any DOM manipulations. It seems Mark's suggestion of ensuring the existing extension points are easy (and safe) to use is the key item going forward...we need an easy way to attach handlers perhaps by implementing the XML Events 2 script handler (http://www.w3.org/TR/xml-events2/#section-script-element) but perhaps more importantly need safe methods in such scripts for manipulating the model...using existing XForms actions such as insert, delete, setvalue etc via their APIs (reusing the same code paths as in their markup forms) would be one way to do so...which would help script authors stay within the regular XForms processing model. So we should continue to evolve this example as a means to get consensus and build up an example of "best practices" for how to do this...Charlie From: Mark Birbeck <mark.birbeck@webbackplane.com> To: Ulrich Nicolas Lissé <unl@dreamlab.net> Cc: Charles F Wiecha/Watson/IBM@IBMUS, public-xg-app-backplane <public-xg-app-backplane@w3.org> Date: 05/05/2009 05:10 AM Subject: Re: Reminder: no Backplane call tomorrow -- pls send SMIL'y thoughts :} Sent by: public-xg-app-backplane-request@w3.org Hi Ulrich, > it is quite common to use <xf:load resource="javascript:my-function();"/> to > trigger JavaScript functions from XForms. I don't know if ubiquity-xforms > supports this, but it should be a no-brainer to add it. I'm afraid we won't be adding that, if I have anything to do with it. :) We never use this technique in our own code. In fact, when consulting on form design, we've seen more problems with that technique amongst our customers' forms than just about anything else. The 'technique' -- or 'hack' as it should be called, in its full, perjorative sense :) -- completely bypasses the whole XForms infrastructure, in terms of value evaluation, rebuild, refresh, event handling, and so on. All that happens is a function is executed out of context. And what's more, it's completely unnecessary. There are two natural extension points in XForms, where authors can use their own functions; event handlers and XPath extension functions; all we need to do is to ensure that both of those extension points are easy to use. That's not to say that we might not add the ability to have action handlers too, probably based on the XHTML 2 Handler spec; it's just that calling a function from within XPath or an event handler covers most scenarios. Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 5 May 2009 13:43:58 UTC