[Seaside] Non-blocking jQuery load

jtuchel at objektfabrik.de jtuchel at objektfabrik.de
Fri Nov 20 08:16:22 UTC 2015

Hi Johan,

what you describe fits well into my observations (or vice versa)....

Am 20.11.15 um 08:56 schrieb Johan Brichau:
> Joachim,
> Are you inspecting execution of the callbacks on the server-side only?
> It seems that when you say that “the browser is blocking” you are 
> actually saying that the request for the callback is not *processed* 
> while the ajax load is executing?
Of course the use of "blocking" was wrong. The browser is not blocking, 
I just see no reaction to my click on the "normal" link before all the 
all Ajax requests are finished - and it seems you just described why 
that is.

> To verify: do you see the browser performing a request in the browser 
> developer tools when you click the link?
The link does a show:, so the browser navigates away from the page the 
very instant the longest running ajax request is done. The dev toos in 
Firefox are cleared in that moment, so I cannot see anything of that 
"normal" request. While the two Ajax requests are being processed, I 
cannot see that "normal" request being sent to the server (but I should, 
even if the server doesn't react).

> Seaside requires all requests for the same session to be processed 
> sequentially.
> So, callbacks will not execute as long as the server is processing any 
> other callback for the same session.
So this explains a lot. This means we can cheat a little by showing the 
page earlier, but it won't be reacting to menu selections any sooner. 
Unless we do some "use another session (or even server) to collect the 
data" magic.

> It seems to me that this is what you are experiencing.
Yes, I was hoping to not only make page load times shorter, but also let 
the user click sooner... Especially since our dashboard will grow and 
allow more data-intensive reporting over time.
> This has to do with how Seaside manages session state for you.
> Thinking about it: I’m not sure if it would be possible to have an 
> exception for some ajax callbacks.
> At the very least, it would put a responsibility of managing the 
> session state concurrency conflicts in the hands of the application 
> developer.
So far I seem to have learned that this power wouldn't be put in good 
hands in my case ;-)

One stupid question that wants to be asked: AFAIK there is no way of 
stopping the server side from processind Ajax requests? I know you can 
cancel the ajax request on the client side, but this is just keeping the 
browser from waiting, right?
Thinking about this a little further, I could possibly implement some 
crude special ajax call that stops the ajax processing on the server 
side and kills those background-processes on the server side (currently, 
they are not forked processes, but they could be) whenever the user 
clicks one of the links in the menu.... Not sure I really like the idea, 
but maybe it would work...

> However, this does not solve your problem. Do you have a bit more 
> information on why these components are rendering slowly? Is it the 
> rendering phase or is the retrieval of the data for these components slow?
It is a lot of data that has to be processed on the smalltalk side. So 
no Seaside problem here. Glorp is probably the busiest component in this 

Oh my, so I have to put on my Architect's hat again and see how we can 
speed up the data collection before we add more widgets to the dashboard.

> Johan
>> On 20 Nov 2015, at 08:08, jtuchel <jtuchel at objektfabrik.de 
>> <mailto:jtuchel at objektfabrik.de>> wrote:
>> Hi Johan,
>> Am 19.11.15 um 22:17 schrieb Johan Brichau-2 [via Smalltalk]:
>>> Hi Joachim,
>>> jQuery load is an ajax request and should thus not be blocking any 
>>> browser action.
>> Yes, that's what I thought as well...
>>> What kind of interaction are you expecting from the ‘click’ to which 
>>> the browser is not responder?
>>> A page request, an ajax request, the execution of a javascript 
>>> program, ... ?
>> On our Dashboard we have the main navigation menu which consists of 
>> anchors with normal callback blocks.
>> After I had sent my last mail, I saw that both ajax requests take 
>> about the same time to finish (4022 and 4096 ms on a slow development 
>> machine), so I thought maybe this all is just a coincidence.
>> So here is what I've tried then:
>> I added a (Delay forSeconds: 5) wait to one of our dashboard widget's 
>> business code.
>> What happens is this:
>> The widgets all immediately start an ajax request, and the one 
>> without the Delay gets rendered after the usual 4 seconds. The other 
>> one renders a bit more than 5 seconds later. So far, so unsurprising.
>> BUT: If I click on one of the main navigation links (which should be 
>> totally unrelated to the Components that issue the ajax call), the 
>> callback is not called before the longer runnin Ajax request is 
>> finished. The Re-rendering of the Component in the Browser is not 
>> performed, however (at least I can't see it).
>> So the first observation seems to tell me the "load html:" calls are 
>> not blocking. The second, however, seems to indicate that they block.
>> Or (shiver) there is something strange going on on the server side 
>> (VA Smalltalk) that keeps the server from handling the "normal" 
>> request before the ajax requests are finished. I need to test with a 
>> bit more logging to find out...
>> Thanks for listening,
>> Joachim
>>> Johan
>>> > On 19 Nov 2015, at 09:59, jtuchel <[hidden email] 
>>> <x-msg://79/user/SendEmail.jtp?type=node&node=4862097&i=0>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > in our application, the user sees a dashboard right after logging in.
>>> > Depending on the configuration of this dashboard, load and render 
>>> times can
>>> > get quite long.
>>> >
>>> > So we tried to wrap slow components into a Decoration that uses 
>>> load() to
>>> > postponbe the loading of their content. The render code in our 
>>> decoration
>>> > looks like this:
>>> >
>>> > replaced
>>> > ifTrue: [div with: [self renderNextOn: html]]
>>> > ifFalse: [
>>> > html document addLoadScript: (
>>> > (html jQuery: self idSelector) load html: [:r |
>>> > replaced := true.
>>> > self renderNextOn: html]).
>>> > div with: [
>>> > html image src: someSpinnerImage
>>> > html space; text: self message]]
>>> >
>>> >
>>> >
>>> > Thus, we hoped, the page would display very quickly, and be responsive
>>> > before all the widgets are loaded.
>>> >
>>> > So far, we've reached one of the two goals: the page now loads 
>>> quickly and
>>> > the widgets use ajax to load their contents later. Another nice 
>>> side effect
>>> > is that if you go back to the start page, all widgets are loaded 
>>> already.
>>> >
>>> > The other goal, however, is not met: If you log in and immediately 
>>> click on
>>> > one of the menu items, the browser won't react to your click 
>>> before all
>>> > widgets have finished loading. So it seems like jQuery's load is 
>>> blocking.
>>> >
>>> > We've tried in Chrome and Firefox, and both expose this behavior.
>>> > Does anybody know how to not only cheat on the load times of our 
>>> dashboard
>>> > but also enable the browser to react on clicks before all widgets have
>>> > loaded their contents?
>>> >
>>> > Any hint is appreciated,
>>> >
>>> > Joachim
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in 
>>> context:http://forum.world.st/Non-blocking-jQuery-load-tp4861881.html
>>> > Sent from the Seaside General mailing list archive atNabble.com 
>>> <http://nabble.com/>.
>>> > _______________________________________________
>>> > seaside mailing list
>>> >[hidden email] 
>>> <x-msg://79/user/SendEmail.jtp?type=node&node=4862097&i=1>
>>> >http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email] 
>>> <x-msg://79/user/SendEmail.jtp?type=node&node=4862097&i=2>
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>> ------------------------------------------------------------------------
>>> If you reply to this email, your message will be added to the 
>>> discussion below:
>>> http://forum.world.st/Non-blocking-jQuery-load-tp4861881p4862097.html
>>> To unsubscribe from Non-blocking jQuery load,click here.
>>> NAML 
>>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>> -- 
>> -----------------------------------------------------------------------
>> Objektfabrik Joachim Tuchel[hidden email] <x-msg://79/user/SendEmail.jtp?type=node&node=4862141&i=0>
>> Fliederweg 1http://www.objektfabrik.de
>> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
>> Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
>> ------------------------------------------------------------------------
>> View this message in context:Re: Non-blocking jQuery load 
>> <http://forum.world.st/Non-blocking-jQuery-load-tp4861881p4862141.html>
>> Sent from theSeaside General mailing list archive 
>> <http://forum.world.st/Seaside-General-f86180.html>atNabble.com 
>> <http://nabble.com/>.
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org 
>> <mailto:seaside at lists.squeakfoundation.org>
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20151120/9e8d7048/attachment-0001.htm

More information about the seaside mailing list