It hadn't been doing that. Nothing seems to be triggered when the page is loading. What would trigger SSJS validation to run upon opening an xpage?
Your question is too vague to give an exact answer. I recommend watching the XPages Master Class. It will explain the JSF life cycle and show you how to use the XPages toolbox to diagnose your application to get the answer.
Check any partial refresh calls. Use firebug to view network traffic
See if any Ajax calls are being made when page loads. Also check
If you have any converters altering data that might trigger the validation
Related
There is a 5 second or so after the page is loaded, that e.g. clicking or hovering on elements won't work.
I figured out, it has to do with the Tag Manager.
Just like suggested in the guide, it's loading asynchronously.
Does somebody have any suggestion how to avoid this lag?
GTM shouldn't cause such delays - it loads asynchronously. If you want to test it - remove GTM from the website and check page load time. You can also use WebPageTest and block GTM in the settings to prevent the script from running. Unless there are any custom HTML injections that prevent the buttons from working before all the content is loaded, it isn't GTM.
Looking at the load waterfall you should see which element blocks the page from loading.
I found out what the problem was that was issue in our implementation, not in GTM.
I have becommen the SocketTimeoutException, which is quite hard to replicate now, but it is not the most important here. What is troubling me is the reaction of the PrimeFaces UI on such happening. The UI got frozen, so no AJAX clicks were processed (one could click what one will but nothing happened).
I don't know the PrimeFaces internals well, but with my experience with AJAX apps, it could happen where we have the AJAX queue and the job is not released after unexpected error happens. Is it the case here?
And how to prevent such behaviour? Or if prevention is not possible, is it possible to "restart" the AJAX engine of PrimeFaces in Javascript? As the last resort I could provide the special button to "reset" the AJAX state without "refreshing" (which should be rather called destroy-all-my-changes) the site?
If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.
I read some paragraphs in a book saying that it is not possible to do a partial postback for web, even AJAX is employed. Ajax will postback everything and update only ajaxfied controls.
However, on pages I made using ajax, I used Fiddler to monitor the transportation. I found when the page initial load, it loaded everything include pictures .... However, when I click a button and do a ajax postback. I can only see the some data were loaded.... Looks like it doesn't need to reload the whole page again.
I don't know if what I see is correct? Or the book I read is correct?
Thank you guys.
That depends what you put in the term "postback".
The AJAX call will send the complete form data back to the server, just as if the form was posted normally. The server will answer with a partial response that only contains the parts of the page that should be updated.
So, the request is not partial, but the response is.
I am not sure how you are posting back from the client side. I am guessing you are using UpdatePanels. How well you 'AJAX-ify' a web page depends on what method you employ.
UpdatePanels - Read Dave Ward's posting on them - http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
PageMethods to post back to a web service, get the data and update the DOM to display the result
JQuery and other such AJAX frameworks to post back to a web service
I am sure the link above should clear things up a bit
I'm having a hard time understanding your terminology. I'm not really sure what a "postback" is, much less a "partial" one. I do know that one of the basic ways to transmit information to an HTTP server is via a POST request, which is usually used when submitting forms. If you mean to say that the entire form is transmitted when you click a submit button, I believe you'd be right.
You also seem to be doing something with AJAX, but it's difficult to tell. The whole point of AJAX is to have dynamic data displayed on a page without resorting to reloading it. Defining what to send and what to do with the results is entirely up to your own JavaScript. So unless you're using a framework, which you don't specify, there is no such thing as "ajaxified controls."
In any case, "AJAX" usually means using the XMLHttpRequest() method of modern browsers to send data to servers without refreshing the page. When you call this function, you specify exactly what data to send. This has nothing to do with HTML forms. One caveat: if you are indeed using a library for AJAX, it might impose additional limits on how you structure information to send.
I have a web form with more than 10 fields that are submitted to the database. So before submitting the values I am doing JavaScript validation.
Currently I am using JavaScript validation and shows an alert box if an error occurs in data entry.
Is it a good practice to show alert box when JavaScript validation fails or should I use asp.net validation controls to display the error messages?
I'd avoid using an alert box. It's annoying, requires an extra click, and since it's modal - stops the entire browser.Instead, highlight the erroneous fields/values, and print a message at the top, explaining that the highlighted fields need to be corrected before the user can continue.You can use Asp.Net validation, or jQuery form validation - both work equally well.
ASP.NET Validation controls are more recommended, because the alert can be intrusive. They can be set to give messages without posting back, which is ideal.
Just make sure you make it obvious when the form has failed.
from the usability perspective it is much better to use .net validation. Depending on your alert box implementation you may bombard user with many alerts which is very bad.
Also don't rely on client side validation only. Be sure to validate on the server side as well. And this is where .net validation might be handy again.
A good practice is what when your code supports fall back method. For example, if Javascript is disabled then the user should still be able to view the error messages, if any.
More over, they dont look as good as you could style your own divs and display them after some server side validation .. and then use javascript to hide/fade out this error message container div.
I think its a personal/design preference.
Sometimes its just more obvious when there is a javascript alert indicating something needs to be done. Sometimes a small red asterisk gets lost on the page.
In my own opinion, alert boxes are just too annoying to see on websites these days since they're all you see on Windows... But, if you prefer a better looking site, use something else. If you want to make sure the message gets across - then use an alert.