[Seaside] Non-blocking jQuery load
jtuchel at objektfabrik.de
jtuchel at objektfabrik.de
Fri Nov 20 08:16:22 UTC 2015
what you describe fits well into my observations (or vice versa)....
Am 20.11.15 um 08:56 schrieb Johan Brichau:
> 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
> 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
> 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
> 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
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.
>> 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?
>>> 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,
>>> > 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
>>> > 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
>>> > 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
>>> > 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
>>> > 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
>>> > Sent from the Seaside General mailing list archive atNabble.com
>>> > _______________________________________________
>>> > seaside mailing list
>>> >[hidden email]
>>> seaside mailing list
>>> [hidden email]
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>> To unsubscribe from Non-blocking jQuery load,click here.
>> 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
>> Sent from theSeaside General mailing list archive
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> <mailto:seaside at lists.squeakfoundation.org>
> seaside mailing list
> seaside at lists.squeakfoundation.org
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...
More information about the seaside