ORBEON.xforms.Globals.serverValue cache problem in xforms.js

>
> Hi All,
>
> We're developing some forms which are able to change states depending on the
> buttons clicked. I've attached a sample here which should run in the sandbox
> to demonstrate what we have. In short it is a form that starts in readonly
> mode and can change state to editable mode when the edit button is clicked.
> When in edit mode, users can make changes and hit the save button to save
> the changes, or click cancel to revert back to the previously saved state.
>
> With the cancelling, it is best implemented with a xforms:reset. However
> xforms:reset is not fully supported in Orbeon. So we put in a workaround
> which does a roundtrip to the backend server to retrieve the previously
> saved instance data and replace the exist one with it. This all seems to
> work fine until we did the following test:
>
> Click on Edit to edit the form, make a change (append "asdf" to the text
> field). The xxforms-value-change-with-focus-change event is
> fired back to Orbeon and the
> ORBEON.xforms.Globals.serverValue is now set. Then the user
> change his mind and hit Cancel. The data instance is replaced and the form
> is now in readonly state again with the change reverted.
> Click on Edit once again to edit the form. Make the exact same change
> (append "asdf" to the text field). This time the
> ORBEON.xforms.Globals.serverValue thinks there's no change
> and so not bother hitting Orbeon. The user hit cancel again. (an annoying
> mind changer maybe). The form is back to readonly mode.
> At this point, the editable portion of the form (which is hidden in readonly
> mode) is out of sync with the  data instance. If the user click Edit again,
> they will see the previously unsaved changes appearing in the field.
>
> Does anyone have similar problems with the
> ORBEON.xforms.Globals.serverValue cache? Does it seem like
> a bug? Is there any way to clear this cache when the data instance is
> completely replaced?
>
> Louis
>
> --
> 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
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>

> Louis,
>
> I can reproduce the issue. I entered a bug to track this:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=306185&group_id=168&atid=350207
>
> Thanks,
>
> -Erik
>
>  > We're developing some forms which are able to change states depending on
>  > the buttons clicked. I've attached a sample here which should run in the
>  > sandbox to demonstrate what we have. In short it is a form that
>  > starts in readonly mode and can change state to editable mode when the
>  > edit button is clicked. When in edit mode, users can make changes and
>  > hit the save button to save the changes, or click cancel to revert back
>  > to the previously saved state.
>  >
>  > With the cancelling, it is best implemented with a xforms:reset. However
>  > xforms:reset is not fully supported in Orbeon. So we put in a workaround
>  > which does a roundtrip to the backend server to retrieve the previously
>  > saved instance data and replace the exist one with it. This all seems to
>  > work fine until we did the following test:
>  >
>  >    1.
>  >       Click on Edit to edit the form, make a change (append "asdf" to
>  >       the text field). The xxforms-value-change-with-focus-change event
>  >       is fired back to Orbeon and the ORBEON.xforms.Globals.serverValue
>  >       is now set. Then the user change his mind and hit Cancel. The data
>  >       instance is replaced and the form is now in readonly state again
>  >       with the change reverted.
>  >    2.
>  >       Click on Edit once again to edit the form. Make the _exact_ same
>  >       change (append "asdf" to the text field). This time the
>  >       ORBEON.xforms.Globals.serverValue thinks there's no change and so
>  >       not bother hitting Orbeon. The user hit cancel again. (an annoying
>  >       mind changer maybe). The form is back to readonly mode.
>  >    3.
>  >       At this point, _the editable portion of the form (which is hidden
>  >       in readonly mode) is out of sync with the  data instance_. If the
>  >       user click Edit again, they will see the previously unsaved
>  >       changes appearing in the field.
>  >
>  > Does anyone have similar problems with the
>  > ORBEON.xforms.Globals.serverValue cache? Does it seem like a bug? Is
>  > there any way to clear this cache when the data instance is completely
>  > replaced?
>  >
>  > Louis
>
>  
> ------------------------------------------------------------------------
>
>
> --
> 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
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  

> I think this problem is actually quite common - perhaps this should be
> higher priority? Attached is a very simple example which demonstrates
> the same issue:
>
> - select 'Male'
> - hit the 'Clear' button
> - select 'Male' again
>
> The second time Male is selected, the model is not updated even though
> the radio button appears selected. This is quite bad because the user
> may think they are submitted one value, but in fact they are submitting
> another.
>
> Any time a control's value is updated from the backend (rather than
> directly by the user) it seems the ORBEON.xforms.Globals.serverValue
> array gets out of date, leading to mistaken caching decisions. Ensuring
> that this array is updated when the server returns new values for
> controls seems to fix the problem:
>
> function xformsHandleResponse(o) {
>
>    ...
>
>    // Update control value
>    case "control": {
>        var controlElement = controlValuesElement.childNodes[j];
>        var newControlValue =
> ORBEON.util.Dom.getStringValue(controlElement);
>        var controlId = ORBEON.util.Dom.getAttribute(controlElement, "id");
>
>        ORBEON.xforms.Globals.serverValue[controlId] =  newControlValue;
> // NEW
>
>         ...
>       Adrian
>
>
>
> Erik Bruchez wrote:
>> Louis,
>>
>> I can reproduce the issue. I entered a bug to track this:
>>
>> http://forge.objectweb.org/tracker/index.php?func=detail&aid=306185&group_id=168&atid=350207 
>>
>>
>> Thanks,
>>
>> -Erik
>>
>>  > We're developing some forms which are able to change states
>> depending on
>>  > the buttons clicked. I've attached a sample here which should run
>> in the
>>  > sandbox to demonstrate what we have. In short it is a form that
>>  > starts in readonly mode and can change state to editable mode when the
>>  > edit button is clicked. When in edit mode, users can make changes and
>>  > hit the save button to save the changes, or click cancel to revert
>> back
>>  > to the previously saved state.
>>  >
>>  > With the cancelling, it is best implemented with a xforms:reset.
>> However
>>  > xforms:reset is not fully supported in Orbeon. So we put in a
>> workaround
>>  > which does a roundtrip to the backend server to retrieve the
>> previously
>>  > saved instance data and replace the exist one with it. This all
>> seems to
>>  > work fine until we did the following test:
>>  >
>>  >    1.
>>  >       Click on Edit to edit the form, make a change (append "asdf" to
>>  >       the text field). The xxforms-value-change-with-focus-change
>> event
>>  >       is fired back to Orbeon and the
>> ORBEON.xforms.Globals.serverValue
>>  >       is now set. Then the user change his mind and hit Cancel. The
>> data
>>  >       instance is replaced and the form is now in readonly state again
>>  >       with the change reverted.
>>  >    2.
>>  >       Click on Edit once again to edit the form. Make the _exact_ same
>>  >       change (append "asdf" to the text field). This time the
>>  >       ORBEON.xforms.Globals.serverValue thinks there's no change
>> and so
>>  >       not bother hitting Orbeon. The user hit cancel again. (an
>> annoying
>>  >       mind changer maybe). The form is back to readonly mode.
>>  >    3.
>>  >       At this point, _the editable portion of the form (which is
>> hidden
>>  >       in readonly mode) is out of sync with the  data instance_. If
>> the
>>  >       user click Edit again, they will see the previously unsaved
>>  >       changes appearing in the field.
>>  >
>>  > Does anyone have similar problems with the
>>  > ORBEON.xforms.Globals.serverValue cache? Does it seem like a bug? Is
>>  > there any way to clear this cache when the data instance is completely
>>  > replaced?
>>  >
>>  > Louis

> I think this problem is actually quite common - perhaps this should be
> higher priority? Attached is a very simple example which demonstrates
> the same issue:
>
> - select 'Male'
> - hit the 'Clear' button
> - select 'Male' again
>
> The second time Male is selected, the model is not updated even though
> the radio button appears selected. This is quite bad because the user
> may think they are submitted one value, but in fact they are submitting
> another.
>
> Any time a control's value is updated from the backend (rather than
> directly by the user) it seems the ORBEON.xforms.Globals.serverValue
> array gets out of date, leading to mistaken caching decisions. Ensuring
> that this array is updated when the server returns new values for
> controls seems to fix the problem:
>
> function xformsHandleResponse(o) {
>
>     ...
>
>     // Update control value
>     case "control": {
>         var controlElement = controlValuesElement.childNodes[j];
>         var newControlValue =
> ORBEON.util.Dom.getStringValue(controlElement);
>         var controlId = ORBEON.util.Dom.getAttribute(controlElement, "id");
>
>         ORBEON.xforms.Globals.serverValue[controlId] =  newControlValue;
> // NEW
>
>          ...
>
> Adrian
>
>
>
> Erik Bruchez wrote:
> > Louis,
> >
> > I can reproduce the issue. I entered a bug to track this:
> >
> > http://forge.objectweb.org/tracker/index.php?func=detail&aid=306185&group_id=168&atid=350207
> >
> > Thanks,
> >
> > -Erik
> >
> >  > We're developing some forms which are able to change states depending on
> >  > the buttons clicked. I've attached a sample here which should run in the
> >  > sandbox to demonstrate what we have. In short it is a form that
> >  > starts in readonly mode and can change state to editable mode when the
> >  > edit button is clicked. When in edit mode, users can make changes and
> >  > hit the save button to save the changes, or click cancel to revert back
> >  > to the previously saved state.
> >  >
> >  > With the cancelling, it is best implemented with a xforms:reset. However
> >  > xforms:reset is not fully supported in Orbeon. So we put in a workaround
> >  > which does a roundtrip to the backend server to retrieve the previously
> >  > saved instance data and replace the exist one with it. This all seems to
> >  > work fine until we did the following test:
> >  >
> >  >    1.
> >  >       Click on Edit to edit the form, make a change (append "asdf" to
> >  >       the text field). The xxforms-value-change-with-focus-change event
> >  >       is fired back to Orbeon and the ORBEON.xforms.Globals.serverValue
> >  >       is now set. Then the user change his mind and hit Cancel. The data
> >  >       instance is replaced and the form is now in readonly state again
> >  >       with the change reverted.
> >  >    2.
> >  >       Click on Edit once again to edit the form. Make the _exact_ same
> >  >       change (append "asdf" to the text field). This time the
> >  >       ORBEON.xforms.Globals.serverValue thinks there's no change and so
> >  >       not bother hitting Orbeon. The user hit cancel again. (an annoying
> >  >       mind changer maybe). The form is back to readonly mode.
> >  >    3.
> >  >       At this point, _the editable portion of the form (which is hidden
> >  >       in readonly mode) is out of sync with the  data instance_. If the
> >  >       user click Edit again, they will see the previously unsaved
> >  >       changes appearing in the field.
> >  >
> >  > Does anyone have similar problems with the
> >  > ORBEON.xforms.Globals.serverValue cache? Does it seem like a bug? Is
> >  > there any way to clear this cache when the data instance is completely
> >  > replaced?
> >  >
> >  > Louis
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > --
> > 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
> > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
> >
>
>
>
> --
> 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
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>