Just getting into web programming and when it comes to navigation, so far I prefer the idea of using Javascript and AJAX requests to change the content when the menu links are clicked on. It's fast, no page refresh, brilliant. The only problem is that the website's URL always stays the same. So I can't, for example, link someone to the "About" page. What is the standard way to solve this problem?
I'm currently using only HTML, JavaScript and jQuery.
Usually you would use one of two methods. depending on the set of browsers you need to support:
Change the Hash - You can change the hash part of a url (http://.../index.html#about-page), without reloading the page. So, for example, when you click on the 'About' link, you can set the hash of the URL with something similar to this:
window.location.hash = 'bla-bla';
When your page loads, you parse the hash part and perform the necessary logic:
if (window.location.hash === 'about-page') {
// ...
}
Another method is using the 'History API' - In modern browsers you can use an api called 'History API' which allows you to change the history of the browser, including the URL. You use a method called pushState on the history object, for example:
window.history.pushState({ event: 'event-id' }, "Event Title", "?event=event-id");
For further details, you can see a previous answer I've posted in the past:
How to manage browser "back" and "forward" buttons when creating a javascript widget
Really depends on the framework you're using. That was always the classical criticism of JSF which had the same effect with using Put requests as part of its communication approach. They came up with some changes in later releases.
But whether there is a standard approach is hard to say, unequivocally. I have seen Put requests used strategically. That gets the url changing but it's that full submission you were avoiding.
Some javascript libraries allow you to modify the url yourself. I can't recall which ones we used.
In either cae your app will need to cater for this deep navigation because you're giving the users the ability to move directly to pages they may not have been able to previously
Related
I am having a template structure in which there is a single HTML file inside which related HTML & JS files are loaded (using AJAX).
Section are loaded as per User's activity(Page never reloads which kind of is good for user experience).
i.e.
User clicks a menu say "Profile",which causes:
jQuery.load method is used to load a file "/some/path/profile.html".
jQuery.getScript is used in .load() callback to include js files like "some/path/profile.js",The profile js has event handlers for the profile page along with related business logic.
This happens for each menu item/section of the application like "Profile","Files","Dashboard" etc.
It works fast but I am not sure if this is the optimal way to carry this out.
If a User consequently clicks the "Profile" button twice,would the browser
clear up the earlier loaded resources(profile.html,profile.js) first before
loading it afresh?
When user visit a new section say "Dashboard" after visiting "Profile",would
browser again clear out the resources of Profile before loading for
Dashboard?
If not than could this cause some memory related issues with the browser?I searched about this but did not see any related scenarios.
P.S: In this structure often some HTML part is stored in a JS variable to be used further. I read somewhere in SO that it is a bad practice to do so but I was not able to find details regarding it. I assume it should not be a -ve point if the developer is well versed & storing HTML in a JS variable should not be any problem.
Here's my understanding on this:
You have to make sure that you don't send request if clicking on same button at your end.
(Forgot about we are dealing with scripts/HTMl) No caching in the picture
Clearing out resources?, yes it will be removed from DOM if appened in same section. But i guess it's necessary if same placeholder is used for each section content.
If you know that everytime each section will return same template again, you can create a local cache at client side just like memoization to see if template already exists.
Hope this helps.
I'm currently working on a PHP 5.3 based CMS. A lot of actions are called using GET Parameters.
Example:
index.php?action=create_module
adds a certain module to the database and displays the module structure again. There are also functions (triggered by simple links, no POST request) for removing and ordering modules, working the same way with GET parameters.
Problem with this: If the users clicks on History Back after two actions on that page, the whole action is triggered again, which I would like to avoid.
How can I solve this issue? Searched the internet already, but with no satisfying results.
Is there a jQuery function which can remove this ?action parameter when using the browser Back button?
If not, can I prevent the browser from going back?
Is there a way to trigger this "Page has expired" notice?
Different approach on the PHP side?
Note: Header("Location:..") is no option, and I would like to avoid AJAX here.
Thank you for your help!
You could add an event listener on 'onpopstate' to clean window.location.search which holds the parameters, see http://html5doctor.com/history-api/ to get more info about HistoryAPI.
I'm trying to implement AJAX filtering on my own e-commerce website and looking for the best solution.
With what I've come up is:
Making all content statically generated (built by server-side and then calling ajax request on the same page but with parameters). The only cons is that user doesn't have any back history as his URL page doesn't change.
I would try to implement history.api and etc but just saw this awesome filtering right here: http://trendygolf.com/shop?brand[]=15&brand[]=27&price-min=0&pricemax=2000&sort=newest
From what I see it makes AJAX calls AND changes the URL without reloading the page, how is that even possible?
And of course it simply replaces the old html page with the new one from request
I would love to hear some help on this one, what are best practices, pros/cons, and how does trendygolf.com make it like this.
With respect to updating the URL in place, it's part of HTML5, not 100% sure how IE support is though. This will work:
window.history.pushState(“object or string”, “Title”, “/new-url”);
To learn more about this sort of the thing check out the Mozilla docs: https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history
It sounds like you could use the History.js library, which lets you change the browser's state/URL from JavaScript. Basically this library uses the HTML5 History API if available, but can emulate it in browsers which don't support this. History.js is a low-level API though, and you may want to use a Router abstraction on top of it, which simplifies your programming considerably. For this purpose I've implemented the StateRouter.js library.
A simple example of how one may use StateRouter.js:
function getHome() {
}
function getPersons() {
}
function getPerson(id) {
}
var router = new staterouter.Router();
// Configure routes
router
.route('/', getHome)
.route('/persons', getPersons)
.route('/persons/:id', getPerson);
$(document).ready(function () {
// Perform initial routing
router.perform();
// Navigate to a URL
router.navigate('/persons/1');
// Go back
router.back();
// Go forward
router.go(1);
});
in addition to the answer given by newmu
when you need to maintain history/state on ajax calls you should use hashtags
which are a part of the url after symbol hash('#'). whatever you write after # in a url isn't sent to the server
in browsers where history api is still not supported hashtags are used to maintain state
also hashtags can be changed without reloading the page
I load in HTML pages via Ajax. These files have no <title><head><body> tags, etc. Just a few divs inside them.
At the moment, I place links to these ajax pages in my href for browsers with JS disabled:
Honda
The javascript has return false so the user is never taken to that page physically if their browser supports javascript.
My concern is people potentially right-clicking and sending these links to other people. Which would look bad since it is unstyled, etc. I'm tempted to remove the href link because of this.
Are there alternatives to obfuscating the links? It goes against my ideals on best practices to remove the link entirely from the href.
It goes against my ideals on best practices to remove the link entirely from the href.
I strive to follow best practices as well, but what you're doing is actually worse than not including an href at all.
The href attribute should only be used for URLs that users can visit directly. Using it to hold a URL for Ajax use is common (Stack Overflow does it), but it's a misuse of the href attribute.
If possible, href should point to a full page which contains the content that would be loaded by Ajax. If you can't provide that then either remove href or set it to something like "#".
You don't need to obfuscate it and I also don't think you need to remove it. If you are using a server side language you can check for the
X-Requested-With: XMLHttpRequest
HTTP Header in each page. If it isn't set it has not been requested with Ajax. Then you can redirect the user to the right page.
One solution that would work well, but includes some work, would be to create degradation pages for the content. You could create copies of the pages that were complete HTML documents, and use their URL in the links, e.g.:
Honda
When you fetch the content using AJAX, you would replace the view in the URL with ajax.
This way the pages will also be indexed by web crawlers.
Maybe you could use the data tag to store/retrieve your value in a div with a mocklink style. FIDDLE
Something like this.
<div class="mockLink" data-link="/test/link/honda.html">Honda</div>
CSS
div.mockLink{color:blue; text-decoration:underline}
div.mockLink:hover{cursor:pointer;}
JS
$('div.mockLink').click(function(){
alert($(this).data('link')) ;
//do AJAX
});
I have a single-page ajax powered web app, however the way my app works is if a hash string is in the url it will load that element which is really useful for people to link to content on it.
When it comes to bookmarking/favouriting things are different. My users want to book mark the app and not the current bit of content (hash string) they're on...
I'm thinking this is unlikely but is there anyway to get browsers to not include the hash string when the page is bookmarked?
I'm going with you are using the hash as an anchor, rather than a way to store a page's state in a Ajax application.
There are a few solutions you can implement:
Don't use anchors (and thus don't use a hash) and thus hash won't be bookmarked. Instead you can use something like jQuery ScrollTo and scroll to the link instead using javascript instead of the built-in anchor support. http://demos.flesler.com/jquery/scrollTo/
Have a toolbar up the top which contains the url without the hash, or a sidebar.
Educate your users.
If you are asking about keeping support for anchors in Ajax Web 2.0 Applications, then you may want to look at jQuery Ajaxy as it supports this; as seen by the "Durian" demo: http://www.balupton.com/sandbox/jquery-ajaxy/demo/