- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Fri, 12 May 2006 18:03:41 +0100
- To: "'www-forms'" <www-forms@w3.org>
Mikko, > I think running these examples in a split processor (where > e.g. model is in the server, and UI in the client) will be > not so straightforward. What I was aiming for was that it *should* work. What I was thinking was that all you do is translate an XForms document into another XForms document. So say you want to implement tabs--you take each xf:case within the xf:switch that you want to use, and then create a xf:trigger to that toggle that particular xf:case. But the resulting document is still XForms, and it's this resulting document that gets used by formsPlayer, X-Smiles, Mozilla, FormsFaces, Orbeon, etc. The only point I made about the server-side processors in particular is that if we ended up with a great list of these standard pre-processing steps, they could add this to their pipeline so that you don't need to do it in your editor. But it would need to be a distinct pre-processing step. > Also, for instance the example you sent was not using the > standard XForms DOM API from Javascript, so I doubt it will > run on more than one processor. I'm hoping that by making these things public we can make them standard. (Although in the case of the timer it doesn't need to use the XForms DOM; what are you thinking needs to be changed?) 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 Friday, 12 May 2006 17:05:38 UTC