when i click on a button that tries to modify the session's value on serverside, it runs very well:
$('#btn1').click(function() {
update_session('session.php?session=1');
});
But when i tried to trigger this button from another button:
$('#btn2').click(function() {
$('#btn1').click();
});
At that moment, the session isn't changed. I really don't understand because i saw in firebug that there was a POST to server by ajax with the correct arguments.
The problem may be caused by the fact that .click() does not execute the href attribute of an anchor tag.
Having it this way should work:
var clicked = function() {
update_session('session.php?session=1');
};
$('#btn1').click(clicked);
$('#btn2').click(clicked);
If it didn't work it is very likely a server side problem (as suggested by Oriol).
Related
In my asp.NET application I have implemented a control to validate forms input data using server side logic.
The idea is to drag the control to wherever it's needed, set it up in the code behind and the form will be validated.
This validation occurs on the onchange event of each field and on form submission - synchronous ajax call to the server side.
This was working fine until I published it to IIS.
The problem is the following: the user is writing something in a textbox. Then, with the focus on that textbox, clicks on a button or linkbutton, not related to the form being validated.
The validation ajax call occurs (jQuery onchange fires) and the button postback is not reached. Through debugging I found the problem to be the ajax call is somehow preventing the postback to fire (almost feels like a synchronism problem).
I reduced the problem to the point that an alert seems to be causing the same thing as the ajax call. Please have a look at the following project: EDIT: Link removed because I can't post more than 2 links on the same post - sorry!
Consider the first 2 textboxes and the button:
1) If you write something on the first, then click the button: the onchange fires, an alert is shown and the postback does not occurr.
2) If you write something on the second, then click the button: the onchange fires and the postback occurrs.
Can someone please explain why this behavior happens and if there's any solution to this, ie, make the postback fire after the javascript finishes running?
I can think of 2 ways to solve my problem but I need to know (inside the textbox change event) the ID of the control clicked by the user. Any way of getting it?
That way I could: trigger the control explicitly OR verifiy if it doesn't belong to the form controls and don't event validate the input in that moment (that would make sense).
Thanks in advance.
EDITED 22-10-2014:
The plot thickens. This seems to be a synchronism problem. Check this other test application where I removed the alerts (this concentrated too much attention and is not actually related to the issue as I'm not using alert boxes in my project - I'm using little balloons) and just left the AJAX call.
Now, on the server side (WebMethod) I put a Thread.Sleep(). If the thread sleeps for too long, it seems to miss the postback. In my case, on my development environment, the threshold seems to be 80ms. If the ajax call takes less than ~80ms, then the postback is done, if it takes more than that, it misses the postback. Any ideas or similar (resolved) issues you have seen? Note that my ajax call has async: false.
EDITED 24-10-2014:
Finally had another look into this. I think I may have come to a possible solution, although I don't like the idea of relying on a setTimeout to handle the submit button 'click' before the 'focusin' (same control).
I changed the logic (still achieving the same goal) and now use different events.
Now I need to distinguish when the submit control fires the 'focusin' event because it just gained focus (1) or it was clicked (2):
The user could just be tabbing (validates the last field that had focus - if it belongs to the form being validated)
The user could have clicked (does not validate the last field that had the focus, but the whole form and then submits or not)
Have a look at this new test app which is closer to what I have in my project.
Can you help me finding a better way to handle/process the click event before the focusin event on the same control without something unpredictable like a setTimeout? If I do need to rely on the setTimeout, how much do you think the wait should be set to? On my machine 150ms works, but on another persons, it may require more time? Something like some sort of callback would be ideal.
Thanks again
Use __doPostBack('',''); at end of your javascript function
It does appear that an alert box stops postback in this situation. The sensible solution I found was to use a jQuery dialog which doesn't seem to suppress a postback. Problem is of course the dialog doesn't persist itself through the postback but this is solved by a hidden field containing a 'flag' to display the dialog after postback or not.
You will need to add jquery-ui.js and some style for the dialog, if this is a serious application I suggest you download both files and put them in scripts folder as you already have with the jquery min.
<head runat="server">
<title>Postback with dialog</title>
<link rel="stylesheet" href="//code.jquery.com/ui/1.11.2/themes/smoothness/jquery-ui.css">
<script src="scripts/jquery-1.8.2.min.js" type="text/javascript"></script>
<script src="//code.jquery.com/ui/1.11.2/jquery-ui.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#TextBox1").on('change', function(e) {
$("#doDisplayDialog").val("yes"); // Add a flag so it shows after postback.
$('#jqAlert').dialog({
closeOnEscape: true,
open: function(event, ui) {
$(this).parent().appendTo("form");
}
});
});
if ($("#doDisplayDialog").val() == "yes") {
$('#jqAlert').dialog({
closeOnEscape: true,
open: function(event, ui) {
$(this).parent().appendTo("form");
}
});
$("#doDisplayDialog").val("no"); // Clear the flag so it doesn't display after postback.
}
});
</script>
</head>
Add a hidden field:
<asp:HiddenField ID="doDisplayDialog" runat="server" />
And a Div to be the dialog box:
<div id="jqAlert" title="Alert" style="display: none;">
<p>Postback will happen!</p>
</div>
Code is based on your downloadable test website application.
-- not a working solution below --
Try this - copy/paste replace these lines in your test web application:
$(document).ready(function() {
$("#TextBox1").on('change', function() {
alert('T1 Postback does not fire');
return true;
//return AjaxCall();
});
$("#TextBox2").on('change', function() {
alert('T2 Postback does not fire');
return true;
//return AjaxCall();
});
});
The only change I did was replace single quotes with double quotes in jquery selector here
$('#TextBox2')
with
$("#TextBox2")
Edit: actually it doesn't work, I had a bug in my test code. Will look more into this.
I have a xe:navigator (called navigator1) on an application layout in the Left Column. In the Right Column I have a dynamicContent control. in the onClick event of the navigator I do a partial refresh on navigator1 which works but the dynamicContent1 is not refreshed. I can do a full refresh and both will refresh, but at a performance price. I put this in the Client side of the onClick:
XSP.partialRefreshGet('#{id:dynamicContent1}');
return true
but when I do the dynamicContent1 is not refreshed. I think my syntax is correct. If on the server side I do a partial refresh on dynamicContent1 it refreshes it correctly but navigator1 is not refreshed. So the issue is can one do two partial refreshes on the same onClick event?
If I'm reading your question correctly, this is just a timing issue: when you define client-side code and server code in the same event, the client-side code is always executed first. So it's refreshing your dynamicContent control before it executes the navigator event.
Move the CSJS code to the onComplete property of the eventHandler. This property isn't surfaced in the "pretty panels" for events, so you'll need to navigate directly to the <xp:eventHandler /> tag (either in the Source XML or via the Outline), and you'll find onComplete listed under All Properties.
Placing the refresh code in onComplete will ensure that the second refresh doesn't occur until after the first one is completed, which will allow the second target to reflect any changes triggered by the event.
Bonus tip: you can also chain refreshes:
XSP.partialRefreshGet("#{id:div1}", {
onComplete: function() {
XSP.partialRefreshGet("#{id:div2}", {
onComplete: function() {
XSP.partialRefreshGet("#{id:div3}", {
onComplete: function() {
XSP.partialRefreshGet("#{id:div4}");
}
});
}
});
}
});
This allows you to refresh as many targets as you want, but the same rule applies: if you need any of the targets to be "aware" of changes to data or components made within an event, you'll need to trigger the start of the chain in the onComplete attribute of that event, not as the client-side code of the event itself.
I am currently trying to run an action in my grails controller upon a page load in my application that will start a thread an continue with a task. I still have yet been able to successfully implement this in. This is my code:
$(document).ready(function(){
var $form = $("#background_thread");
$form.submit(function(e){
e.preventDefault();
$.post($(this).attr("background"), $(this).serialize(), function(data){
alert("should work" + data)
});
return false;
});
});
I cannot for the life of me figure out why it's not working. Is there some simple syntax I'm overlooking or a different way I should be doing this?
Update:
My form id is #background_thread and I am trying to do it asynchronously so that the page will still stay the same and my action will be run.
My script is run but fails on $form.submit(function(e){ and will not pass through.
You need to prevent the default behaviour on the event that has been generated.
$form.submit(function(e){
e.preventDefault();
// your code
}
Update:
You will certainly need to add the above regardless, once you get the overall script working. Also, please add your markup to the question. A few basic questions to make sure:
Is #background_thread the id of your form?
In your network tab in Chrome Inspector (or similar) is the request being fired off?
Is the markup being delivered asynchronously, as if it is, you will need to use .on to attach the event permanently, rather than just a basic selector?
Update 2:
Your form is being delivered asynchronously itself, therefore your event attaqchement must change to:
$(document).ready(function(){
$("body").on("submit", "#background_thread", function(e){
e.preventDefault();
$.post($(this).attr("background"), $(this).serialize(), function(data){
alert("should work" + data)
});
return false;
});
});
So, to explain, your event attachment was happening during document ready. Document ready fires, but the form hasn't been delivered to the DOM yet, so it doesn't have an attachment to it. Therefore, you use on() to permanently attach that event to that element for the lifetime of the entire page's rendering to the browser.
N.B. I attached it to body, to begin listening for submit at that point, in practice you would not do this for many reasons, you would attach it to the outermost point of AJAX replacement for the form, essentially, the nearest parent to the form that will be known on initial page load.
I hope that this has been of some use and good luck with your application.
I have a button in my HTML page which is not part of any form.
<input type='button' id='submitter' value='add'/>
I have a click handler on it:
$('#submitter').click(function(e) {
e.preventDefault();
e.stopPropagation();
var args={}
$.get('notexists.php', args, function() {alert('what?');}, 'json')
.error(function(){ alert('error'); });
return false;
}
Now, notexists.php does not exist, so the click should alert error. But for some reason, The page refreshes with I click the button!
Some experiments I've tried to identify the problem:
removed everything from the handler (no return false, no prevent default, no stop prop, no jquery post call - nothing) - the page did not refresh on click, and it should not. the button is not a submit button, and it dont belong to no form.
removed teh $.post call - no refresh
enabled the firebug's "break on error" feature and tried clicking - refreshed again. so there is no error.
changed the post URL to something that exists and works - still refreshing
added an "alert" after the $.post call - it did not get called. Seems like the execution breaks at $.post, but there's no error (experiment 3).
changed the input to a "div" with the same id. Same results - page gets refreshed.
Can anyone help?
PS: I'm using $.post in MANY other parts of this app, and its working as expected everywhere.
Have you checked $('#submitter').length when you attempt to bind the event? Maybe you have duplicate id's in the dom? Have you got your script running before the closing body tag or inside a jquery doc ready block?
Posting a fuller code sample would help to eliminate the questions I pose.
I believe your selector isn't selecting the button, so the event handler is not being applied.
Test your selector by doing something like:
$("#submitter").val('Test');
I have a page with a TabContainer control (from the Ajax Control Toolkit), and I toggle the visibility of some elements on the page depending on the currently-selected tab. I'd been doing this in an event handler for OnClientActiveTabChanged (which works fine), but I discovered that it leaves the page in the wrong state after a postback. I tried adding some code to the document.ready event handler to get the index, but when I do the following:
$(document).ready(function () {
var index = $('#<%= TabContainer1.ClientID %>').[0].control.get_activeTabIndex();
// Do some stuff with the index
});
...I get a null reference exception on the .control property. Is there a way to hook a client-side "ready" event for the TabContainer?
I’m not familiar with the event lifecycle with normal DOM elements (it seems like there ought to be a general onload event, but I don’t see one). If there isn’t an event that can be easily handled, it seemed like it might work to add an UpdatePanel with UpdateMode=Conditional and an AsyncPostBackTrigger that pointed to a hidden button with an onclick event handler that would get the active tab index – but that seems like a lot of moving pieces for something that I’d expect the DOM to expose already.
Too late to be helpful, but I've had the same issue and found a workaround.
Change you code
$(document).ready(function () {
var index = $('#<%= TabContainer1.ClientID %>').[0].control.get_activeTabIndex();
// Do some stuff with the index
});
to
function pageLoad() {
var index = $('#<%= TabContainer1.ClientID %>').[0].control.get_activeTabIndex();
// Do some stuff with the index
};
Explanation here:
http://encosia.com/document-ready-and-pageload-are-not-the-same/
Basically, jQuery's ready event is "a bit early" and the TabContainer is not initialized yet, whereas the client side ASP.Net's pageLoad is late enough and the TabContainer has been initialized by then.
Check this post to save tab selection during postbacks. It works for normal post backs by saving the active tab index in hidden variable. Though its written for a JQuery plugin in the posted link, concept should be the same i.e., persisting the index of the selected tab.