Incremental request delay

> Hi everyone,
>
> I am using an incremental input to filter a list of items, i.e. the xforms-
> value-changed is connected to the submission querying the database for the
> filtered dataset. Since filtering for short strings is rather expensive, I want
> the form to wait a bit before sending the request, since the user will most
> likely enter more than one character. So I tried increasing oxf.xforms.delay-
> before-incremental-request to 500ms, but looking at the database log, even if
> I type quickly, several requests are sent. Even if I set the delay to 5
> seconds, the filter is applied almost immediately (less than a second). Is that
> a bug somewhere, or am I using the property the wrong way? Unfortunately I
> found no documentation for it and only learned that it existed by looking at
> the source JavaScript file.
>
> I am using the latest stable Orbeon release (3.8).
>
> Kind regards,
> Ralf Jung
>
>
> --
> 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
>
>

> Hi,
>
>> Wow - this is a nice catch. I couldn't believe my eyes. This is indeed
>> a bug (not too much of a surprise so far), but this one has been
>> introduced in a refactoring done in November 2008. Here is the
>> relevant section of that 2008 commit:
>>
>> http://github.com/orbeon/orbeon-forms/commit/547d4776bc7077ba434d9978eea8c6
>> 2688bd42ac#L0R2316
> Wow, glad you found that out :)
>
>> I checked all the other changes done at that time (you never know!),
>> and this one was the only faulty one. So I fixed this, and the fix
>> will be in the next nightly build. For reference, the bug is:
>>
>> http://forge.ow2.org/tracker/index.php?func=detail&aid=315584&group_id=168&
>> atid=350207
>>
>> You'll let us know how the new build works for you.
> I solved the problem in the mean time by using xxforms:script. This also
> allowed to be get the behaviour that I actually wanted - to update the form
> not some fixed time span after the first key press, but some time span after the
> last. So, pressing a key every 100ms, 10 times in a row, should only result in
> one update after the last keystroke. Is this possible with the built-in
> settings? Besides, I am hesitant to use a nightly build in production.
>
> I'll try to do a quick test of the nightly later this week.
>
> Kind regards,
> Ralf Jung
>
>
> --
> 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
>
>

> Hi,
>
>> I am not sure what the "this" refers to when you say "Is this possible
>> with the built-in settings?", and I don't really see how using
>> <xxforms:script> can be used to work around this.
> "this" = "to update the form not some fixed time span after the first key press,
> but some time span after the last. So, pressing a key every 100ms, 10 times in
> a row, should only result in one update after the last keystroke"
>
> Kind regards,
> Ralf Jung
>
>
> --
> 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
>
>

> Hi Alex,
>
>> So you could just re-apply this change in your build. You can extract
>> xforms.js from WEB-INF/lib/orbeon-resources-public.jar, do this
>> change, regenerate the xforms-min.js from xforms.js using the YUI
>> compressor (http://developer.yahoo.com/yui/compressor/), and update
>> xforms.js and xforms-min.js in WEB-INF/lib/orbeon-resources-public.jar
>> with your patched versions.
> I did that, and verified that the changed files are in the jar, and restarted
> tomcat. But it's still using the old version, as I can see from opening
> /xforms-server/xforms-dialog-yuicalendar-min.js
> Maybe I should better try a nightly... hm. Does it suffice to replace all the
> jar files with the new ones? I did some configuration to disable the
> /orbeon/exist and so on and do not want to re-do all that.
>
> Kind regards,
> Ralf Jung
>
>
> --
> 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
>
>

> The reason we implemented it this way is that if users type
> continually, if we wait for x ms after the last keystroke, we might
> not sent a request for a long time, which might not give the
> impression that the field is "incremental enough". I.e. imagine those
> two use cases:
>
> 1. Auto-translate content of a text area, or auto-rendering of
> Markdown: users will have to stop typing to see the result.
> 2. Auto-save: here again, data won't be saved until after users stop
> typing.

> Hi,
>
>> Have you regenerated the xforms-min.js?
> Yes, I re-generated and re-packed both of the js files.
>
>> Also, instead of repackaging the xforms.js into the jar, you can put
>> it in your WEB-INF/resources/ops/javascript. Any file you put in
>> WEB-INF/resources by default overrides files in the jars/classpath.
>> And if you are curious why, you'll find the configuration for this in
>> your web.xml. Also, you might find some information about editing the
>> Orbeon Forms JavaScript code at the page below:
>>
>> http://wiki.orbeon.com/forms/doc/contributor-guide/development-environment/
>> javascript-development
> Thanks for this, good to know the "overloading" of Orbeon's virtual file system
> (as I call it for myself) works even for the shipped core resources.
>
>> The reason we implemented it this way is that if users type
>> continually, if we wait for x ms after the last keystroke, we might
>> not sent a request for a long time, which might not give the
>> impression that the field is "incremental enough". I.e. imagine those
>> two use cases:
>>
>> 1. Auto-translate content of a text area, or auto-rendering of
>> Markdown: users will have to stop typing to see the result.
>> 2. Auto-save: here again, data won't be saved until after users stop
>> typing.
> I agree that there are usecases for both types of behaviour. In this case, it
> is about a filter, and filtering for short strings is relatively costy. Usually,
> the user has some name in his mind and will enter at least 4 or 5 characters,
> in which case I do not want the shorter queries to be executed.
>
> Also, with these additional options, it seems to work now, thanks a lot! This
> is much cleaner than my Javascript solution. It was not *that* hacky though:
> <xxforms:script ev:event="DOMActivate">
> if (filterTimer != undefined) window.clearTimeout(filterTimer);
> var time = ORBEON.xforms.Document.getValue("filter").length == 1 ? 500 : 200;
> // single-character queries are quite costy, so let's see if we can avoid them
> filterTimer = window.setTimeout("filterTimer = undefined;
> ORBEON.xforms.Document.dispatchEvent('summary-model', 'filter-update');",
> time);
> </xxforms:script>
> But it went through the server, so if the fixed incremental update does not
> suffice, I will try to add some local event listener and disable incremental and
> trigger the update myself. Somehow...
>
> Btw, a timeout of 5000ms is still not honoured, it gets update after a second
> or two - but I guess that is caused by some of the other limits like delay-
> before-force-incremental-request.
>
> Kind regards,
> Ralf Jung
>
>
> --
> 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
>
>