I have some pages that load data slowly and will not have valid session data for the HDIV state while the page is rendering.
So if the user clicks a link during that time, they will get a Security Violation page because the HDIV state was not committed. Almost on all the components the link is loaded in a "href:"
This is not reproducible manually each time, but with automation is reproducible.
Any idea how to fix this?
I would avoid having an overflow to block clicking on the page until the page is fully loaded.
Related
I was reading up on ajax and how it empowers us to exchange data with a server behind the scenes and consequently avoid full page reloads. My confusion lies here, I don't really understand what full-page reloads mean. I think it's probably cause I've been working with ajax/react since the start I guess and have not really seen any webpage of mine fully reload when I access stuff from a database or an api.
It'd be great if someone could explain what they are and why did we need them before ajax?
A full page load is where the entire page is downloaded from the server. A page typically consists of several sections: header, footer, navigation, and content. In a classic web application without AJAX, a user clicks on a link to another page, and has to download the full page, even though only the main content is changing. The header, footer, and navigation all get downloaded again even though they don't change.
With AJAX there is the opportunity to only change the parts of the page that will change. When a user clicks on the link, JavaScript loads just the content for that link and inserts it into the current page. The header, footer, and navigation don't need to reload.
This introduces other problems that need attention.
When AJAX inserts new content into the page, the URL doesn't change. That makes it difficult for users to bookmark or link to specific content. Well written AJAX applications use history.pushState() to update the URL when loading content via AJAX.
There are then two paths to get to every piece of content. Users can either load the URL containing that content directly, or load the content into some other page by following a link. Web developers need to test and ensure both work.
Search engines have trouble crawling AJAX powered sites. For best compatibility, you need to employ server side rendering (SSR) or pre-rendering to serve initial content on a page load that doesn't require JavaScript.
Even for Googlebot (which executes JavaScript) care must be taken to make an AJAX powered site crawlable. Googlebot doesn't simulate user actions like clicking, scrolling, hovering, or moving the mouse.
Content needs to appear on page load without any user interaction
You must use <a href=...> links for navigation so that Googlebot can find other pages by scanning the document object model (DOM). For users, JavaScript can intercept clicks on those links and prevent a full page load by using return false from the onclick handler or event.preventDefault() in the click handler.
I'm developping a jqm application with spring mobile in the back-end.
Whenever I hit the browser refresh button on my mobile phone the page is completely devastated afterwards. Browsers back-button works properly.
The data are still available due prg pattern (flashAttributes in Spring) after refresh. Only the view is malformed.
Any ideas how to solve this problem?
From jQuery Mobile docs :
The simplest approach when building a jQuery Mobile site is to reference the same set of stylesheets and scripts in the head of every page. If you need to load in specific scripts or styles for a particular page, we recommend binding logic to the pageinit event (details below) to run necessary code when a specific page is created (which can be determined by its id attribute, or a number of other ways). Following this approach will ensure that the code executes if the page is loaded directly or is pulled in and shown via Ajax
So what happens is - in jQuery Mobile, the scripts and styles defined in the head are loaded only once. So, in normal conditions, it works fine, as all the pages will use the scripts loaded from the first page.
But. When you refresh a page in-between, it triggers a page-reload instead of the ajax navigation model thatjqm uses. So all the scripts and styles loaded from the first page will not be included from here on out.
What you need to do is "reference the same set of stylesheets and scripts in the head of every page", so that even if you hit refresh in the middle, the scripts and styles that had been loaded from the head of the first page are loaded again.
I recommend you read the docs from the above link fully to gain a better understanding.
I'm optimizing my site speed. One of the main issue I'm facing is the homepage.
In the homepage, each article has FB/TW share buttons.
I only inserted the scripts in the footer once but I'm getting bunch of FB/TW share button requests.
Is it normal or there is something I need to do?
For every Like/Share button that you have, your browser needs to make a request to get the content. This is only executed when the browser has received the page from your server, so it does not affect the initial load time.
As CBroe mentions, the button is displayed in an iFrame. These are loaded and depending on your browser settings all at the same time or consecutive. During this time, your browser is not blocked so your used can already interact with the page.
If you want to reduce load, the only option is to remove the buttons. I think you have some index/home page where you load all the articles and for each of those a button? You could consider only showing the buttons on the articles itself, if you are really concerned about this.
But, since this is normal behaviour and your page is not blocked by loading all the iframes, this is not a big issue nor can you optimise it yourself.
I'm using Richfaces 4 and Mojarra 2.0.4. So I'll be glad if the answer is specific to Richfaces 4 framework :)
I understand that the JSF components are processed at the server side. Some of my pages are really data centric. So when I load that page (eg: inside a richTab with switchType ajax), it takes a lot of time for my bean to execute the method marked with #PostConstruct to execute and fetch data. And hence the time period between user clicking on the tab's header and actual page rendering is quite large, a really bad user experience. I've implemented lazy loading for the dataTables in the page but that still doesn't optimize my page load time since #PostConstruct is still there.
Is there anyway I can load the page first and THEN fetch the data with ajax and update the page? This loading time is really annoying for the user.Any help appreciated :)
PS: I thought of using the oncomplete and onbeforedomupdate client side events of rich:tab and call ajax functions declared with a4j:function. But it seems that these events are fired before the page is actually switched.
use onload event of <body> tag in html along with <a4j:jsFunction>
If you still feel your page is not rendering completely before the method called then use setTimeout('a4jfunctionName',10) javascript function in onload to complete the rendering first.
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.