Raising strange number of events when removing controls

Hi.

I have come across some strange event behaviour of xforms when I was trying
to remove items from an instance using xforms:delete.

Following your "Enabling and Disabling Your 'Save' button" blog I have an
xform page which raises an event every time new values are entered into a
control (using a 'dirty' flag set with xforms-value-changed).

This all works fine, however when I try and delete that control the xforms
engine seems to be firing off an strange number of xforms-valid and
xforms-value-changed events.

I attaching a demo which you can try in the sandbox. Simply run it an try
clicking non the 'Remove current item' link. In this case I am receiving 7
messages that the values in my controls have changed!

What I would like to do is to remove an item without causing it to raise
any xforms-valid or xforms-value-changed events of the control being
removed.

Chris.



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

Chris,

That's a nice case, thanks!

FWIW, the following is done on purpose whenever a control or repeat
iteration becomes non-relevant:

* An xforms-disabled event for that control is dispatched. This allows
   you to use events to monitor the state of controls, including their
   appearance and disappearance, and allows implementing things like
   the error summary.

* In addition to xforms-disabled, we also send the default values for
   other MIP events (xforms-optional, xforms-readwrite, xforms-valid)
   of the control that just went out of business. Whether this should
   happen is arguable, but it will probably not impact you at the
   moment.

* We don't send xforms-value-changed, as the control no longer has a
   value.

* For repeat iterations, and in part because we are not quite "smart"
   enough yet to detect if associated controls slided up or down, we
   send change events for all the iterations following the control
   bound to the deleted node. This is one reason you are seeing more
   events than you would expect.

But you were right that too many events were sent: we sent value
changed events for xforms:group as well. Groups don't have a value so
this should not happen, although relevance and read-only events could
arguably be dispatched on groups when they are bound to a node.

So I fixed the above. After this change, you should now get less
events, although you will still get several xforms-value-changed and
xforms-valid events after deleting a row.

http://forge.objectweb.org/tracker/index.php?func=detail&aid=306832&group_id=168&atid=350207

I attach a modified version of your case which shows more information
about what is happening. Please let us know if this is better.

-Erik

Chris Bailey wrote:
 > Hi.
 >
 > I have come across some strange event behaviour of xforms when I was
 > trying to remove items from an instance using xforms:delete.
 >
 > Following your "Enabling and Disabling Your 'Save' button" blog I have
 > an xform page which raises an event every time new values are entered
 > into a control (using a 'dirty' flag set with xforms-value-changed).
 >
 > This all works fine, however when I try and delete that control the
 > xforms engine seems to be firing off an strange number of xforms-valid
 > and xforms-value-changed events.
 >
 > I attaching a demo which you can try in the sandbox. Simply run it an
 > try clicking non the 'Remove current item' link. In this case I am
 > receiving 7 messages that the values in my controls have changed!
 >
 > What I would like to do is to remove an item without causing it to raise
 > any xforms-valid or xforms-value-changed events of the control being
 > removed.
 >
 > Chris.

--
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Thanks for the detailed reply Erik.

I was hoping the removal of a control would not raise any
xforms-value-changed events as the user has not changed the values of the
controls (although if you implement the removal by shifting all the values
of the controls up one then that would cause their values to change).

My situation is that I have a form that regularly saves it's state to a db
on every xforms-valid event (if the value has been changed using a test on
a 'dirty' flag). However when the user removes a row from a table full of
controls, I end up repeating the save action many many times. I would like
to disable the save mechanism, remove the controls and then re-activate the
control mechanism.

I thought that adding a second flag might work:
<xforms:instance id="datachange">
  <controls>
    <dirty>false</dirty>
    <override>true</override>
  </controls>
</xforms:instance>

Updating only if both are true:
<xforms:action ev:event="xforms-valid" if="instance('datachange')/dirty =
'true' and instance('datachange')/override = 'true'">
  ..[save form contents]..
</xforms:action>

And then on my removal, first disabling my override, performing the delete
and then setting it back to true at the end.

<xforms:action ev:event="DOMActivate">
  <xforms:setvalue
ref="instance('datachange')/override">false</xforms:setvalue>
  <xforms:delete context="instance('controls')" nodeset="*"
at="index('repeat_group')"/>
  <xforms:setvalue
ref="instance('datachange')/override">true</xforms:setvalue>
</xforms:action >

Unfortunately the two setvalue instructions happen instantly before the
xforms:delete and so this doesn't work. Is there any other way I could
engineer this so that on a delete I only receive one xforms-valid event?

Chris.

--On 23 March 2007 12:52 -0700 Erik Bruchez <[hidden email]> wrote:


--
----------------------
Chris Bailey
[hidden email]



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

Chris,

 > I was hoping the removal of a control would not raise any
 > xforms-value-changed events as the user has not changed the values
 > of the controls (although if you implement the removal by shifting
 > all the values of the controls up one then that would cause their
 > values to change).

Yes exactly!

 > My situation is that I have a form that regularly saves it's state
 > to a db on every xforms-valid event (if the value has been changed
 > using a test on a 'dirty' flag). However when the user removes a row
 > from a table full of controls, I end up repeating the save action
 > many many times. I would like to disable the save mechanism, remove
 > the controls and then re-activate the control mechanism.

[...]

 > Unfortunately the two setvalue instructions happen instantly before
 > the xforms:delete and so this doesn't work. Is there any other way I
 > could engineer this so that on a delete I only receive one
 > xforms-valid event?

What about something like the attached? I used a second flag, but I
force a refresh before clearing the flag.

-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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Excellent - thanks Erik that's exactly what I was after.

It seems that <xforms:refresh/> element is very useful to give you some
control over event management a bit.

Chris.

--On 02 April 2007 14:56 -0700 Erik Bruchez <[hidden email]> wrote:


--
----------------------
Chris Bailey
[hidden email]



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

Chris,

Yes. Ideally you shouldn't have to explicitly use xforms:refresh because
you would like everything to be transparent, but since that action
causes refresh events to be sent it does come in handy!

The way things work if you don't use xforms:refresh explicitly is that a
refresh is done implicitly (and if needed) after your actions have
executed (the exact logic is described in more details in the XForms 1.1
spec).

-Erik

Chris Bailey wrote: --
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
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws