W3C home > Mailing lists > Public > public-xg-app-backplane@w3.org > May 2009

Re: Reminder: no Backplane call tomorrow -- pls send SMIL'y thoughts :}

From: Ulrich Nicolas Lissť <unl@dreamlab.net>
Date: Wed, 6 May 2009 10:24:00 +0200
Cc: Mark Birbeck <mark.birbeck@webbackplane.com>, public-xg-app-backplane <public-xg-app-backplane@w3.org>
Message-Id: <CAFB9E3C-EF86-4467-8B62-18175CB4D64A@dreamlab.net>
To: Charles F Wiecha <wiecha@us.ibm.com>
Mark, Charlie,

I completely agree with you. I don't consider using xf:load for  
executing JS a good practice. I just felt it was a bit less 'hacky'  
than adding a xf:call action -- especially because it works in some  
XForms processors today.

Of course it is most desirable to have a full XML Events  
implementation at hand. However, regardless /how/ a piece of JS is  
wired into XForms processing, the script author has to take care for  
RRRR issues. Even if a script is executed through standard XForms  
extension points, it still has to cater for RRRR (depending on the  
kind of model manipulation it performed). So I'm in favour of  
extending XForms' IDL interfaces with counterparts of some - if not  
all - XForms actions.

This requirement is already recorded in the XForms Future Features (http://www.w3.org/MarkUp/Forms/wiki/Better_DOM_interface_to_expose_all_actions 
). Maybe we can start to sketch it out.


On 05.05.2009, at 15:43, Charles F Wiecha wrote:
> 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
> <graycol.gif>Mark Birbeck ---05/05/2009 05:10:43 AM---Hi Ulrich, >  
> it is quite common to use <xf:load resource="javascript:my- 
> function();"/> to
> <ecblank.gif>
> From:
> <ecblank.gif>
> Mark Birbeck <mark.birbeck@webbackplane.com>
> <ecblank.gif>
> To:
> <ecblank.gif>
> Ulrich Nicolas Lissť <unl@dreamlab.net>
> <ecblank.gif>
> Cc:
> <ecblank.gif>
> Charles F Wiecha/Watson/IBM@IBMUS, public-xg-app-backplane <public-xg-app-backplane@w3.org 
> >
> <ecblank.gif>
> Date:
> <ecblank.gif>
> 05/05/2009 05:10 AM
> <ecblank.gif>
> Subject:
> <ecblank.gif>
> Re: Reminder: no Backplane call tomorrow -- pls send SMIL'y  
> thoughts :}
> <ecblank.gif>
> Sent by:
> <ecblank.gif>
> 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)

Ulrich Nicolas Lissť
Received on Wednesday, 6 May 2009 08:24:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:50:45 UTC