listening to changes to html inputs

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

listening to changes to html inputs

Adrian Baker
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
Reply | Threaded
Open this post in threaded view
|

Re: listening to changes to html inputs

Alessandro Vernet
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
Reply | Threaded
Open this post in threaded view
|

Re: listening to changes to html inputs

Adrian Baker
Alessandro Vernet wrote:
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
  
Aha, I see. This is good news - look forward to experimenting with it.

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
Reply | Threaded
Open this post in threaded view
|

Re: listening to changes to html inputs

Alessandro Vernet
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
Reply | Threaded
Open this post in threaded view
|

Re: listening to changes to html inputs

Adrian Baker
Alessandro Vernet wrote:
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
  
That sounds excellent - I think this would pretty much close the loop in terms of XForms<->Javascript interaction, for Orbeon at least.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: listening to changes to html inputs

Erik Bruchez
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