var json_string=$.parseJSON(document.getElementById("json_db").innerHTML);
$(function ()
{
$("#folder_tree").jstree({
contextmenu: {items: customMenu},
"json_data" : {data:json_string},
"plugins" : [ "themes", "json_data", "ui", "contextmenu" ],
});
});
function customMenu(node)
{
var items = { };
}
$('#folder_tree').delegate('a', 'contextmenu', function (e)
{
idn = $(this).parent().attr("id");
if(idn) pool_control(idn,e); //sendMsg(idn)
});
Hi, I’m getting something really weird in jsTree.
The above code shows tree creation and delegating the right click event.
sendMsg(idn) sends an AJAX request to another page.
pool_control(idn,e) uses the event to show a form next to the clicked node. After the form is filled, it calls sendMsg.
The script works perfectly when I call sendMsg directly in the delegated event handler(instead of pool_control). However, when I call it through pool_control, this happens:
Each pool_control is called, the no. of Ajax requests sent increases by one. The contents of the request appears to be the same, but I have no idea why the no. of ajax requests increases. This doesn’t happen when I call sendMsg directly.
What’s happening? How do I fix this?
pool_control and sendMsg:
function pool_control(id,ev)
{
$("#pool_count").css("left",ev.pageX);
$("#pool_count").css("top",ev.pageY);
$("#pool_count").css("visibility","visible");
$("#poolbutton").click(function()
{
$('#pool_count').css('visibility','hidden');
sendMsg(id);
});
$("#poolcancel").click(function()
{
$('#pool_count').css('visibility','hidden');
});
}
function sendMsg(a,ev)
{
$('#pool_count').css('visibility','hidden');
var factid = $("#factid").val();
var floor = $("#floor").val();
var ceiling = $("#ceiling").val();
var pool_count = $('#poolsize').val();
var userid = document.getElementById("userid").innerHTML;
$.ajax(
{
type: "POST",
url: "generator.php",
data: {what:a,name:factid,author:userid,floor:floor,ceiling:ceiling,pool_count:pool_count},
async: false,
cache: false,
timeout:50000,
});
}
This is a long-polling webpage. sendMsg sends a user-made change in the tree and doesn’t care about the response.
Another function waitForMsg is the long-polling ajax request. When it sees the change in db due to sendMsg, it calls the jstree() function again to remake the tree.
When I make a change in the tree, sendMsg sends 1 request first time, 2 requests seconds time, 3 requests third time, so on.
I’m pretty sure nothing’s wrong in that function, but here it is, just in case
function waitForMsg()
{
var lastupdate = document.getElementById("lastupdate").innerHTML;
var msg;
$.ajax({
type: "POST",
url: "oracle.php",
data: {lastupdate:lastupdate},
async: true,
cache: false,
timeout:20000,
success: function(data)
{
msg = data.split("@");
document.getElementById("lastupdate").innerHTML=msg[0];
document.getElementById("json_db").innerHTML=msg[1];
initPage(); //a <body onready> function which creates the tree again
setTimeout('waitForMsg()', 200 );
},
error: function(XMLHttpRequest, textStatus, errorThrown){
setTimeout('waitForMsg()', 1000);
}
});
}
Because of the way events work in jQuery, every time you attach an event using functions such as .click(), the event is “stacked” to a list, not replaced.
In layman terms, the following code:
Does not tell jQuery to run this when a click happens, but rather add this to the list of things that should be run when a click is triggered.
That is to say, if you attach the event multiple times, for example in the following manner:
The result will be (you guessed it) sendMsg() gets called 3 times each click, because each event attached is treated independently.
Since new click events are being attached every time pool_control is called, the result is the number of sendMsg() calls, and thus the ajax requests, increases by one for every pool_control() call.
The fix? Either unbind click events before binding them again in pool_control():
OR, and I would personally rather recommend this way because among other things it has less overhead, attach the events only once in your initialization code. You can attach the event whenever you want, it’s perfectly fine to attach them before calling delegate on contextmenu outside of pool_control() in your example for instance:
This method ensures the events are only attached once, and as long as you don’t destroy #pool_count you are off to go, the events will be fired whenever a click happens without having to care about it in pool_control().