[Glass] How to make Seaside ignore a repeat request

Esteban Maringolo via Glass glass at lists.gemtalksystems.com
Mon Nov 5 15:15:37 PST 2018


What I do is to disable the element that triggers the ajax call and also
hook into the global ajax handler this way:

renderLoadingIndicatorHandlerOn: html

html document addLoadScript: ((html jQuery document)
call: 'ajaxStart'
with: (Javascript.JSStream
on: 'window.onkeydown = function(e){e.preventDefault;return false;};'
, 'window.svxLoadingTimeout = setTimeout(
function(){
'$("#svxLoadingIndicator").hide().fadeIn();}
,500);')
asFunction;
call: 'ajaxError'
with: (Javascript.JSStream
on: 'clearTimeout(window.svxLoadingTimeout); window.onkeydown = null;'
, '$("#svxErrorIndicator").fadeIn();')
asFunction;
call: 'ajaxStop'
with: (Javascript.JSStream
on: 'clearTimeout(window.svxLoadingTimeout);'
, 'window.onkeydown = null; '
, '$("#svxLoadingIndicator").fadeOut();')
asFunction)

So everytime I send an AJAX request I locally disable the element, and do
whatever I consider "locally relevant" to the action, then the global AJAX
handler is hooked and removes the handler for all keyboard interactions
(windows.onkeydown), then if the requests takes more than 500ms of wait I
display a modal "loading indicator" that is displayed in front of all the
page, and when the ajax stops I fade out that indicator.
If there was an error I display another indicator used to handle ajax
errors.

So far this worked very well for interactions that might need to invalidate
other elements in the screen after some callback execution (most likely
returning an script).

Regards,

Esteban A. Maringolo


El lun., 5 nov. 2018 a las 16:19, Richard Sargent via Glass (<
glass at lists.gemtalksystems.com>) escribió:

> On Sat, Nov 3, 2018 at 4:48 AM, Johan Brichau <johan at yesplan.be> wrote:
>
>> Hi Richard,
>>
>> In case of  xml-http-requests (aka ajax requests), you could use
>> client-side javascript code to control the request. It would require to
>> standardise the use of ajax calls throughout the entire seaside application
>> code, though. Using custom tags (subclasses of WATag), you could create
>> some abstractions.
>>
>> In the case of full-page requests (triggered by page links), returning a
>> 204 is indeed an interesting thought. I have never experimented with it but
>> it should be straightforward to change the response code in that case. I’ll
>> respond in your other email.
>>
>
> Thanks for the answers, Johan. The 204 status worked out to be more
> trouble than benefit. At this point, it looks like the best option is the
> UI overlay which prevents anything else getting clicked while the first
> request is running.
>
> For those who were interested, it does appear that the second request
> terminates the first. So, the first request's response gets "delivered" to
> a closed socket, since the 204 response was sent back "long before" the
> response to the first request was constructed, and that 204 response
> completed the request/response sequence.
>
>
>
>> What we (Yesplan) do in production to limit the number of such ’session
>> locked’ retries from happening is making the session sticky to the gem.
>> Since Seaside wants to process requests sequentially, we queue them in the
>> load-balancer. See
>> http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass
>>
>> Cheers,
>> Johan
>>
>> On 1 Nov 2018, at 01:25, Richard Sargent via Glass <
>> glass at lists.gemtalksystems.com> wrote:
>>
>> I have a situation where some requests may take a long time, resulting in
>> the
>> user getting impatient and triggering the request again. If the second
>> request cannot get the lock while the first is processing, the request
>> processing loop retries for a total of 10 attempts before giving up.
>> (This is especially critical when the default #retryDelays of 23.31
>> seconds
>> is too long and have been shortened.)
>>
>> Short of fixing the thing that takes a ridiculously long time, what can I
>> do
>> to prevent or ignore the user triggering the request a second time and
>> perhaps getting back a /Too many retries: 11/ response instead of what was
>> requested?
>>
>> Is there a way to disable the UI while a request is being processed?
>> Is there a way to produce a "null response" that won't try to update the
>> display in the browser?
>>
>>
>> Thanks,
>> Richard
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/GLASS-f1460844.html
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20181105/09b994d4/attachment.html>


More information about the Glass mailing list