How to avoid multiple Ajax Request

CHtml::ajaxLink(), CHtml::ajaxSubmitButton() and similar methods are great, but if they are located inside a portion of the page that is already loaded via ajax something bad will happen, something you may even not notice if you are not using tools like firebugs: the sent ajax requests will multiply themselves.

What's going on exactly? ¶

Let's set up an example:
you have a page with a list of users. Every time you click on a username a div will be loaded via ajax, and this div will contain the user details plus another ajax link that will be used to display a floating div that will contain a form to send a message to the user.

The first time you load the user everything will be going just fine, and when you click on the "send a private message to the user" link just one request will be triggered.

If you load then another user (or the same user) when you click on the "send a message" link two request will be triggered, and then 3, and then 4 and so on.

What's causing the problem? ¶

The ajax request are triggered based on the link ID. Every time the div is reloaded through ajax a new delegate/event will be loaded pointing at the same ID of the one before him. So when you actually click on the link both delegates will do their job, because both match the clicked link.

What can I do to avoid this problem? ¶

Easy solution ¶

The answer is extremely simple: assign to your ajax link a random ID.

You can achieve this result doing something like this:

CHtml::ajaxLink('send a message', '/message', 
    array('replace' => '#message-div'), 
    array('id' => 'send-link-'.uniqid())
);

Total 5 comments

#4207

joblo at 2011/06/15 07:39pm

Other workaround

In my opinion, the problem is the clientChange function of CHtml. Why to register a script and not output the ajax stuff directly if used in a ajax area?

I have detected this article after the release of the extension ajaxutil

It should be easy to add a option 'directOut' to the ajaxOptions of CHtml::ajaxXX elements in the Yii core - see me feature request ajax-handling

Besides: The extension handles the problems with pagers, when loaded inside an ajax area too.

#3667

nickcv at 2011/04/27 04:06am

@seb

of course the easy solution is a workaround :P the main point of the article is making you aware of what causing the problem...

the best thing would be of course not to load any additional js binding the same link more then once

#3612

seb at 2011/04/23 06:47am

Workaround

I think this is an easy solution, but this is only workaround which hides the real problem, isn't it? The real cause of multiple ajax requests is that ajaxLink() uses 'live' to bind an event by default. So when you render a part of HTML along with javascript code then you have multiple handlers binded to the same HTML element. So usually you can whether: - configure ajaxLink to use bind instead of live (pass 'live'=false to the ajaxOptions array) - do not render scripts when returning HTML on the server side – in the controlled do $renderPartial->('view', $data) instead of $renderPartial('view', $data, false, true)

Maybe you have some other case, but I faced this problem many times and it definitely can be solved without such workaround. But also I think you described a really easy solution which can be acceptable in some cases.

#3602

nickcv at 2011/04/21 07:27am

you can use uniqid() and time() still

rand was just an example of a possible solution, you can use more accurate functions to generate the random string like time(), uniqid() or microtime()

#3601

SimonJ at 2011/04/21 07:23am

Relying on rand() could make the 1 in 30,000 chance of failure very difficult to debug when it happens.

RAND_MAX on some systems could be as low as around 32,000 meaning that eventually if the site is used enough rand() should statistically return the same value for 2 versions of the content div. If the site is dependent on only having one AJAX request generated then this will fail in a way that is almost impossible to replicate. If this is considered the best technique then perhaps an incrementing counter could be used, or better still, use jQuery when processing the AJAX request to cancel the all event listeners for the link.

Please login to leave your comment.