Every control value change is hitting the server

<model ev:event="xforms-recalculate" ev:defaultAction="cancel">

...

<trigger>

  <label>Recalculate now</label>

  <recalculate ev:event="DOMActivate"/>

</trigger>

-----Original Message-----
From: Stephen Bayliss [mailto:[hidden email]]
Sent: Friday, February 17, 2006 9:49 AM
To: [hidden email]
Subject: [ops-users] Every control value change is hitting the server

From what I can see, any control value change on an xforms page is hitting the server: eg typing into a text box, clicking a checkbox etc.

 

For our application there’s a large proportion of controls which really don’t need to interact with the server (all that should happen is that the page instance data should be updated when the control value changes).

 

Is there any way to “optimise” the application to reduce this amount of event traffic between the browser and the server?

 

With our server, and sufficient clicking around, we can actually lock up the server at 99% CPU for a number of minutes, presumably because of the number of events that are being processed server-side.

 

Steve

-----Original Message-----
From: Richard Braman [mailto:[hidden email]]
Sent: Friday, February 17, 2006 10:00 AM
To: [hidden email]
Subject: RE: [ops-users] Every control value change is hitting the server

After reading XForms Essentials by Micah

http://xformsinstitute.com/essentials/browse/book.php#ch07-1-fm2xml

I would think you would use something like the following, but I dont know if it suported in OPS, and if so how.

Because NG uses AJAX, that is why there are all these round trips to the server.  I would also like to hear about this from Erik and Alex.

 

Name

revalidate, recalculate, refresh, and rebuild

Synopsis

XForms keeps track of computational dependencies, like a spreadsheet, so that any chained calculations properly resolve themselves in the face of changes. This action explicitly invokes a rebuilding of the dependencies, and is almost never needed.

These four actions trigger the processing involved with revalidation, recalculation, refresh, and rebuilding dependencies, respectively. Under normal conditions, all of these activities take place automatically, and form authors don't even need to consider these events or actions.

The primary exception, however, is on limited platforms where any of these activities might be expensive, in terms of processing or perceived user delay. When that's the case, it's not desirable for these events to happen automatically. Instead, users will want to have greater control over exactly when such things happen. This is similar to the concept of spreadsheets that have an option to turn off automatic recalculation.

To do this in XForms is a two-step process. First, an observer needs to be set up to cancel all automatically generated events for the expensive process (recalculation in this example). That step, by itself, will result in the recalculation never happening, which doesn't work so well. So the second step is to provide an option for the user to manually fire off a recalculate. This example shows both aspects:

<model ev:event="xforms-recalculate" ev:defaultAction="cancel">

...

<trigger>

  <label>Recalculate now</label>

  <recalculate ev:event="DOMActivate"/>

</trigger>

Note that this works because the recalculate action directly invokes the processing, without the intervening event flow (which would get cancelled by the observer on model anyway).

-----Original Message-----
From: Stephen Bayliss [mailto:[hidden email]]
Sent: Friday, February 17, 2006 9:49 AM
To: [hidden email]
Subject: [ops-users] Every control value change is hitting the server

From what I can see, any control value change on an xforms page is hitting the server: eg typing into a text box, clicking a checkbox etc.

 

For our application there’s a large proportion of controls which really don’t need to interact with the server (all that should happen is that the page instance data should be updated when the control value changes).

 

Is there any way to “optimise” the application to reduce this amount of event traffic between the browser and the server?

 

With our server, and sufficient clicking around, we can actually lock up the server at 99% CPU for a number of minutes, presumably because of the number of events that are being processed server-side.

 

Steve