Forum: Rails Spinoffs (closed, excessive spam) preventing overlapping AJAX requests?

I'm looking for a good pattern that prevents AJAX requests from 
overlapping.

Consider this scenario, using an address book application as an example:

1. On the left side of the page, there's a list of contacts. On the 
right side, there's a box that shows the currently selected contact. 
(Only one contact can be open at a time.)
2. The user clicks on a contact to open it.
3. The app initiates an AJAX request, but it takes a while. Maybe the 
server has to do some extra processing for some reason.
4. The user gets impatient, and clicks on another contact before the 
first one has loaded, which initiates a second, parallel AJAX request.
5. The second contact loads immediately, and the user starts working 
with it, but then...
6. ...the first AJAX request finally completes, and the first contact 
gets loaded over the second!

Obviously, the first AJAX request should be canceled if a second request 
of the same type is issued while it's still running.

Here's what I'm thinking: a generalized utility class - say, 
SerialRequestManager - designed to handle all situations of this type. 
Sort of a wrapper around Ajax.Request. A setRequest() method would 
accept an Ajax.Request object (and, if one is already set, destroys the 
existing one first); you'd probably want a cancelRequest() method, as 
well. The same class could hide and show an activity indicator.

To stray from the original problem a bit: a variant class - 
ParallelRequestManager - could add incoming requests to a queue, rather 
than destroying existing ones; it would show the activity indicator when 
the first request was added to the queue, and hide it when the last 
remaining request in the queue completes.

Does any of this sound sensible? :)

Well, it does sound quite sensible, if not a bit heavy for your specific
problem (which, by the way is not rooted in the transport layer, but in 
the
UX layer... the user experience). The crux of your problem is that the 
user
is clicking something again. Why? Because he is unaware that anything is
going on from the first click (i.e. your request is taking longer than 
the
user expects and you give no indication that something is happening). 
The
most common pattern, which for all intents and purposes works and is far
less complicated to implement than the "request queue", is to implement 
a
"Loading..." shim that renders everything underneath it unclickable, and
goes away when the call returns.

Now... if you're hellbent on implementing the "request queue"... let me 
know
and I'll offer up some suggestions (we have done something similar for 
other
issues). BUT, the answer I gave above is IMHO a more accurate solution 
if
you objectively look at the real issue.



On Tue, Jul 1, 2008 at 7:18 PM, Travis Miller <greenie2600@yahoo.com> 
wrote:

> 3. The app initiates an AJAX request, but it takes a while. Maybe the
>
> first request was added to the queue, and hide it when the last remaining
> request in the queue completes.
>
> Does any of this sound sensible? :)
>
>
>
>
> >
>


--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl

Yes, very important to show immediate feedback so the user knows
what's going on; shocking how often that isn't done.  In many cases,
just that alone is going to prevent the OP's scenario with the
impatient user.

But unless it's unavoidable/inappropriate, I'm not a fan of that
preventing other actions.  The number of times I've clicked the wrong
thing and been frustrated because I couldn't do what I wanted to do
until the thing I didn't want to do finishes...

So my take is:  Offer immediate feedback, and if it's *appropriate* or
necessary disable other actions but not if you can avoidit; offer a
way of cancelling anything that will take any time (which is nearly
anything), whether it's an explicit "cancel" widget or just initiating
a different action.

I can totally see some widget, perhaps something appropriate for
scripteka, that could be general enough to handle this reusably.

[Travis, with my pedantic hat on:  Your "ParallelRequestManager" is
actually a *serial* request manager (the requests are handled in
series, not in parallel); your SerialRequestManager is more of a
*single* request manager... ;-)]
--
T.J. Crowder
tj / crowder software / com

> But unless it's unavoidable/inappropriate...

Huh?!  Probably "unavoidable/appropriate", eh?

-- T.J. :-)