We've got a custom HTML control
which sits on top of an Orbeon-generated input, which has to work in
repeats. The Orbeon-input is hidden and then kept up to date with calls
to
ORBEON.xforms.Document.setValue(this.parentNode.id, this.value); which works fine when our control is used directly to enter a value. However keeping our control synchronised with value changes from the *backend* (via an XForms action, rather than direct user input) seems to be impossible without patching xforms.js. Initially I thought I could keep it up to date by listening to xforms-value-changed. eg <xxforms:script ev:event="xforms-value-changed"> synchroniseMyControlWithNewHiddenInputValue("myControlId"); </xxforms:script> But this doesn't work, for two reasons: 1. not going to work within a repeat, we can't communicate to the Javascript call which iteration of the repeat fired xforms-value-changed. 2. Events other than xforms-value-change also result in changes to HTML input values. For example, in a repeat, delete/inserts result in the values of the repeating HTML elements being reassigned by Orbeon. eg I might delete the first on screen, behind the scenes Orbeon will remove the last repeat-iteration from the DOM and reshuffle the values to make it look like the first was deleted (and suddenly our custom control is totally out of synch with reality). (1) could be worked around by a brute force approach of synchronising all the controls within a repeat. (2) seems to be a real problem, synchronising every control on every possible action/refresh from server is too expensive. What we're considering is a patch to xforms.js to fire a custom event when the Orbeon HTML input is updated, which our javascript could then subscribe to (otherwise there is no way we can be notified/listen to changes to inputs from the server). (I think we'd want to avoid manually firing the standard "change" event, because it would be caught by Orbeon, and perhaps break other places where it's assumption a programmatic change doesn't hit onchange handlers). Ideally we don't want to maintain a patched version of xforms.js: since this is a fairly generic change (and to a generic problem I imagine), would an approach like this be suitable for inclusion & publication as part of the Javascript API? Unless someone can suggest a better solution of course! Adrian -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Administrator
|
Adrian,
On 10/2/07, Adrian Baker <[hidden email]> wrote: > 1. not going to work within a repeat, we can't communicate to the > Javascript call which iteration of the repeat fired xforms-value-changed. Actually you can, using event('repeat-indexes'). > 2. Events other than xforms-value-change also result in changes to HTML > input values. For example, in a repeat, delete/inserts result in the values > of the repeating HTML elements being reassigned by Orbeon. eg I might delete > the first on screen, behind the scenes Orbeon will remove the last > repeat-iteration from the DOM and reshuffle the values to make it look like > the first was deleted (and suddenly our custom control is totally out of > synch with reality). xforms-value-changed event will be dispatched to all the controls that changed. So if you have 3 controls in a repeat with the value "foo", "bar", and "" (empty string) you insert a node before that, and you might picture that a control is "inserted before foo", but in fact the first control value will change from "foo" to "" (copy of the last value), the second one from "bar" to "foo", the third from "" to "bar", and finally there will be an insertion at the end. So I think this is exactly what you need for what you would like to implement. I have attached an updated version of repeat-table-cells.xhtml that you can use to test this out. Outside of the repeat, I added: <xforms:action ev:event="xforms-value-changed"> <xforms:message level="modal"> Changed: <xforms:output value="event('target')"/> / <xforms:output value="string-join(event('repeat-indexes'), '-')"/> </xforms:message> </xforms:action> Alex -- Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws repeat-table-cells.xhtml (7K) Download Attachment |
Aha, I see. This is good news - look forward to experimenting with it.Adrian, On 10/2/07, Adrian Baker [hidden email] wrote:1. not going to work within a repeat, we can't communicate to the Javascript call which iteration of the repeat fired xforms-value-changed.Actually you can, using event('repeat-indexes').2. Events other than xforms-value-change also result in changes to HTML input values. For example, in a repeat, delete/inserts result in the values of the repeating HTML elements being reassigned by Orbeon. eg I might delete the first on screen, behind the scenes Orbeon will remove the last repeat-iteration from the DOM and reshuffle the values to make it look like the first was deleted (and suddenly our custom control is totally out of synch with reality).xforms-value-changed event will be dispatched to all the controls that changed. So if you have 3 controls in a repeat with the value "foo", "bar", and "" (empty string) you insert a node before that, and you might picture that a control is "inserted before foo", but in fact the first control value will change from "foo" to "" (copy of the last value), the second one from "bar" to "foo", the third from "" to "bar", and finally there will be an insertion at the end. So I think this is exactly what you need for what you would like to implement. I have attached an updated version of repeat-table-cells.xhtml that you can use to test this out. Outside of the repeat, I added: <xforms:action ev:event="xforms-value-changed"> <xforms:message level="modal"> Changed: <xforms:output value="event('target')"/> / <xforms:output value="string-join(event('repeat-indexes'), '-')"/> </xforms:message> </xforms:action> Alex One question: can you see a tidy way to get the value of event('repeat-indexes') to the javascript call though? Having to read a hidden output is a bit clumsy, but it's one way to do it. Adrian -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Administrator
|
On 10/3/07, Adrian Baker <[hidden email]> wrote:
> Aha, I see. This is good news - look forward to experimenting with it. Yes, you'll let us know how it goes. > One question: can you see a tidy way to get the value of > event('repeat-indexes') to the javascript call though? Having to read a > hidden output is a bit clumsy, but it's one way to do it. In the JavaScript code you can use this.id and event.target.id, but there is not easy way to pass some parameter to an <xxforms:script> block. Like you said, you would need to store the value in an instance with a hidden control bound to that instance. This seems to be a concept that is missing in XForms in general. Maybe we could add a child element to <xforms:dispatch> so you can add property/value pairs to the context (which you can access with the event function). Then we could expose those to a <xxforms:script> block through the event object. How does that sound? Alex -- Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Alessandro Vernet wrote:
That sounds excellent - I think this would pretty much close the loop in terms of XForms<->Javascript interaction, for Orbeon at least.On 10/3/07, Adrian Baker [hidden email] wrote:Aha, I see. This is good news - look forward to experimenting with it.Yes, you'll let us know how it goes.One question: can you see a tidy way to get the value of event('repeat-indexes') to the javascript call though? Having to read a hidden output is a bit clumsy, but it's one way to do it.In the JavaScript code you can use this.id and event.target.id, but there is not easy way to pass some parameter to an <xxforms:script> block. Like you said, you would need to store the value in an instance with a hidden control bound to that instance. This seems to be a concept that is missing in XForms in general. Maybe we could add a child element to <xforms:dispatch> so you can add property/value pairs to the context (which you can access with the event function). Then we could expose those to a <xxforms:script> block through the event object. How does that sound? Alex -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Administrator
|
Adrian Baker wrote:
>> This seems to be a concept that is missing in XForms in general. Maybe >> we could add a child element to <xforms:dispatch> so you can add >> property/value pairs to the context (which you can access with the >> event function). Then we could expose those to a <xxforms:script> >> block through the event object. How does that sound? > That sounds excellent - I think this would pretty much close the loop in > terms of XForms<->Javascript interaction, for Orbeon at least. It sure would be doable. I added an RFE for this: http://forge.objectweb.org/tracker/index.php?func=detail&aid=307659&group_id=168&atid=350207 -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Free forum by Nabble | Edit this page |