ASP.Net + jQuery + jQuery + UpdatePanel + nyroModal validation plugin - successful launch in every field!

Question

I have a form containing a list of input fields that the user fills with prices (numbers). I set their css classes to "required" and "number" so that the jQuery validation plugin validates them accordingly. Everything works perfectly. Errors are displayed when each field is either not a number or the absence of a value, etc.

All this form is actually in the popup window of the nyroModal model (jQuery plugin). But that shouldn't matter, it's just a .aspx web form. Inside this, I also used UpdatePanel and put everything in it, because my form is essentially a two-step process. There are some basic steps that the user must complete on the first "page" of the form. When this is confirmed and works, I simply hide / show some elements in the UpdatePanel to show the user the next "page" of the form, which is all the input fields of the price text field, as described above.

I use ImageButton as a trigger point to validate the form. By default, if you just leave ImageButton as it is, .Net will disable the postback, the AJAX postback in my case, because it all happens inside the UpdatePanel. Which again, is desirable. I don't want an ugly full postback for obvious reasons.

After many readings, I needed a way to connect to .Net PageRequestManager in javascript so that I could intercept when .Net wanted to do a postback based on whether jQuery successfully validated the form or not. Therefore, my logic is: postbacks are not allowed by default, but when jQuery successfully validates the form, set a variable that says postbacks are now allowed, then the next time an attempt to postback tries to happen, it will pass. And therefore, demonstrate success for the user.

This all works well, but there is one final problem.

The jQuery validation validation parameter ({success}) seems to fail after successfully validating each individual field, and not the entire form. That is, if I enter a number in any of the price input fields, this success option will work and set my cancelPostback variable to false, which, in turn, means that the form is now submitted even if it has not been verified, just because that one field was valid. I would expect this verification option ({success)) to work only after validating the entire form.

I misinterpreted this and actually did what it means? If so, how can I simply set the cancelPostback parameter to true ONLY when the GENERAL FORM is checked?

Thanks for the heaps for any insight or head.

My jQuery code to implement checking and catching the .Net postback event is as follows:

<script type="text/javascript"> // By default, don't allow Postback until we've successfully validated our form on the client-side. var cancelPostback=true; // Every single time the page loads, including every single AJAX partial postback function pageLoad() { // Reset the value to say that "We don't allow Postbacks at this stage".. cancelPostback=true; // Attach client-side validation to the main form $("#<%= form1.ClientID %>").validate({ success: function() { alert('validation succeeded!'); cancelPostback = false; } }); // Grab a reference to the Page Request Manager var prm = Sys.WebForms.PageRequestManager.getInstance(); prm.add_initializeRequest(onEachRequest); alert("Page Load"); } // Our own custom method to be attached to each new/future page request.. function onEachRequest(sender, args) { alert("About to cancel? " + cancelPostback); // Check to see if we need to Cancel this Postback based on Conditional Logic within this page.. args.set_cancel(cancelPostback); } </script> 

Answer 1

I would suggest looking at the submitHandler and invalidHandler options. One or the other should work for what you want. The best way, in my opinion, is to allow the default sending and set the cancelPostback parameter to true in invalidHandler. Alternatively, you can write your own submitHandler, which calls __doPostBack directly and replaces the view via ImageButton.

Answer 2

I had problems with your solution because all browsers except IE ran the onEachRequest function before the jQuery validator submitHandler () function. I came up with a more elegant solution that simply cancels the postback if the check fails, rather than relying on the given variable.

  Sys.Application.add_init(function() { var prm = Sys.WebForms.PageRequestManager.getInstance(); prm.add_initializeRequest(onEachRequest); }); function onEachRequest(sender, args) { if (args.get_postBackElement().id == <%= [YourSubmitButton].ClientID %>) { args.set_cancel(!$('#aspnetForm').valid()); } } 

Answer 3

Thanks for a bunch of tvanfosson for prompt help.

OK update:

I followed more and more links and eventually found documentation for "success." The documentation on the plugin’s homepage is awful and omits many key features :) But on the jQuery official page, it’s “better.” The Success parameter is intended to be run each time a separate field is successfully checked. So it worked on the design, and I mistakenly believed that it only works when the whole form is valid.

I tried your idea invalidHandler. I liked this idea. One of the problems I ran into was that the ImageButton postback still ALWAYS fired before starting recording before invalidHandler code was run. Thus, postback will continue anyway, after which invalidHandler will disable future callbacks, unfortunately, they fired incorrectly. But besides this, he showed all the other signs of an ideal solution.

Then I went the other way by trying the submitHandler method, i.e. back. Again, this suffers from some ordering issues because postback starts first, but blocks again, and then submitHandler resolves future callbacks, but it was already too late, so this postback was missed. You need to double-click the button to make it go away.

So, the final solution of the half-clue is not so bad, to be honest:

I changed this line to: // Attach client-side validation to the main form $ ("# <% = form1.ClientID%>"). validate ({submitHandler: function () {PreventPostback = false; __doPostBack ('UpdatePanel1', '');}});

As you can see, it first switches the PreventPostback variable, but then starts a new record manually, because the first feedback was already blocked and died. Thus, this call to the __doPostBack guide ensures that the new postback will be launched with the new PreventPostback value.

I removed the event methods due to ImageButtons and made a new method in the server-side code called "DoPostBackLogic ()", which is only called when the page is sent back, which, as I know, should have been from this validation logic because this is the only postback that can happen on my form. Then for me there is all the logic of hide / show / save. This means that when I manually call __doPostBack, I can just use the UpdatePanel identifier and not worry about how to simulate a specific ImageButton, etc.

Thus, it works perfectly. Postprocesses are disabled by default, and when the form is valid, then callbacks are allowed, but then the postback starts manually so that the new value takes effect.

So, this is essentially your second decision, thanks again for listening and sharing! :)