Slashdot Mirror
Ajax Back, Forward, Reload and PHP
IdaAshley writes "A major challenge of Asynchronous JavaScript and XML (Ajax)-driven Web sites is the lack of a Back button. Mike Brittain discusses ways to get around this obstacle in part 1 of the 'Developing PHP the Ajax way' series." From the article: "The Web is a page-by-page medium. The backward and forward buttons on your browser's toolbar direct the browser from page to page. When Macromedia's Flash became all of the rage, developers and users started to see how Rich Internet Applications (RIAs) break this metaphor. You might click around a few sites, land on a Flash-based Web site, then click around in it for a few minutes. One click of the Back button and the ride is over. Rather than going one step backward within the Flash site, you completely lose your place."
This is terrible, and does nothing to make the back button in the browser work. At best, it gives you an undo/redo in the applications. The back button not working is more of a symptom than the actual problem, and if widely implemented this kind of workaround is only going to distract and make it less likely that the actual problem get fixed.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
That has been discussed to death and known for years. You do it with a hidden iframe and anchor links (#blahblah). That's the gut of the whole deal.
I felt the same way. I recommend you install the Stylish firefox extension and specify the following CSS modifications (also removes left hand nav bar):
@-moz-document domain(slashdot.org) {
body {
font: 82%/150% Times !important;
}
#contents { margin-left: 0em !important;}
div#links{display:none !important;}
}
All it does is create a history stack then store it as a cookie. The history is then used to power the back button in whatever the application is.
What'll intrigue me is when someone comes up with a way to integrate the back functions of ajax and friendsto work seamlessly with the browser back button. Hmm... someone should do a Firefox extension.
The hardest part would be deciding on a standard API for this.
If this signature is witty enough, maybe somebody will like me.
Why would you need the Stylish extension when all of those CSS rules could be enclosed in the @-moz-document domain() directive? They'll still only take effect at Slashdot.
When you browse Google Maps for example, there is a button called "Link to this page". It's needed because the URL in the address bar doesn't actually allow you to browse to the map you are viewing. This is because google has no way of dynamically specifying the "link" URL in your address bar without making your browser go to another page.
(Like when you change location.url -- it makes your browser actually go there, not just display different text in the address bar.)
Something like "Link to this page" could be implemented as a standard, so that when you're viewing an AJAX site, the "bookmark" button could be given a special URL that would actually go back to that page as intended, which the AJAX application would have to be programmed to support. The link that is actually bookmarked might differ from the one you used to get to what you are viewing, but is guaranteed to get you back there if you click it.
On the other hand, a system like that would also be very ripe for phishing exploits, so never mind.
"Every great mistake has a halfway moment, a split second when it can be recalled and perhaps remedied. That split second is now."
-- Perl Buck, 1843
How about doing something that actually uses the built-in back and forward buttons of the browser (when possible)?
Like something similar to this?
We already know that Morfik and GWT support all of these features, but does Script# or Atlas, yet? I didn't think so, but my memory may be faulty. Even more importantly than knowing how to support is not having to know how to support it. Thankfully AJAX is advancing so quickly that articles like this are going to be less and less relevant since more and more tools will just implement the features right out of the box.
Friends help you move. Real friends help you move bodies.
Never forget: 2 + 2 = 5 for extremely large values of 2.
I'm 99.5% positive that Adobe Flex can help address using back/forward buttons in the browser and Google has code to do this with Ajax. If I'm not mistaken, Gmail no longer croaks if you try using back/forward now. I'm at work and don't want to take the time to look up the links, so (hopefully) free mod points to whoever feels like posting some links to this stuff!!
That being said, the article is garbage. People ARE integrating it into the browser controls... no point in using this crappy method. Fact is, most users will, through force of habit, use the back/forward buttons, or mouse gestures, or keyboard shortcuts.
This doesn't talk about using the browser's native back/forward buttons, as I inferred from the summary. It just creates fake back/forward buttons within the application, and maintains a history stack. Move along, nothing to see here...
A major challenge of Asynchronous JavaScript and XML (Ajax)-driven Web sites is the lack of a Back button
So says you. I say: if it makes sense for a user to hit your back button, why are you using Ajax? Do users hit their back button when they're using native desktop applications? Sounds to me like you're just to ajax-ify a traditional web application for the heluvit.
Ever use GMail? Next time you're ina folder hit your back button.
Guess what? Works as expected.
There's nothing magical about making the back and forward buttons work alonsgide AJAX. The way Google does it is to track a uniqke token that associates what your page state is on th ebackend, and pass the token along in an IFRAME every time you do something on the page. Since an IFRAME will work along withh your back/forward buttons, functionality is preserved.
It isn't rocket science. Sites who don't want to do this properly are either designed by people who don't know any better, are lazy, or some combination of the two.
Ruby?
What sound do people on rollercoasters make? Hint: it's not Xbox 360.
Not only does the hidden frame + named anchors work with AJAX, it also works for other browser-button-challenged technologies, like full flash sites. Case in point, one of the better known design studios (apparently does work for Ford, Motorola, AOL, Disney, Bacardi, etc) just relaunched, so click click click for working browser buttons.
Mooniacs for iOS and Android
We implemented in-page history (and bookmarking) in Vox by overloading the anchor portion of the URI (the part after the #) and using iframes in IE. The anchor URI form is in simple key:value form that the JavaScript parses and triggers an event to enter the state specified.
Randy
Dojo has already solved this and is also an all-around great ajax toolkit. It's major drawback is a horrible gap in documentation. If you're not afraid of mailing lists and IRC, this is easily overcome.
Why aren't you using Georgia or one of the new Vista fonts (if you have access to those)? It seems such a waste to use a typeface that isn't designed for viewing on a screen.
PHP is a lost cause, and hopefully any decent web programmer has switched to Ruby On Rails already. If you haven't, please google for "Ruby on Rails". You'll find no bullshit coders there.
I 'use' (am abused by) WebCT Vista for my university studies. And it is crap.
When using a web browser you would expect that the standard functions to work, back and forward buttons, multiple tabs on a site and so on. But WebCT Vista doesn't let you do that! Oh no, it restricts you to one page and the navigation is terrible.
People already know how to use webpages, they do not need a new concept thrust at them, especially not a new concept that breaks the old.
I think that Yahoo mail works really well, it is an example of an online app that works with in the web browser concept and offers interaction beyond that for those who want to learn.
I wank in the shower.
Look, the browser is still a two-dimensional (I guess two and a half, if you count pop-ups) document navigation application. If Ajax and other schemes, by their very nature, break out of this linear document structure without the cooperation of the browser itself, then that's what you get.
I'm not dissing Ajax - I'm just saying it's best used in certain circumstances. The times when you don't WANT the user to have arbitrary control over navigation - such as a shopping cart checkout or CMS tools, in which they must be locked into a certain workflow for the sake of application structure, security, user hand-holding, or speed. Ajax is great for db-driven tools, especially when trying to get the speed and interactivity of a client application, plus greater control over navigation to avoid repeat POSTs, etc.
I can appreciate that everyone is trying to innovate a way around this problem, and it seems there are some possible solutions with compromises - that's what makes new waves of tech like Ajax come into existence in the first place. But sometimes you just have to remember there's a time and a place for a certain tool.
Ok, lets think about this one a little bit. I have no patience for toolkits and perfer to write my own code, and Im sure that there are other folks who want to figgure this one out and not just whimp out and borrow code from google.
On Entering the page:
1) check the url for a hash that would say which subsection if it exists load that section (this resolves the problem of bookmarks, as the string after the hash will identify the specific section)
2) if there is no hash in the url, check for a cookie that is keeping track of the users location once again, if its there load that section (twice cook it, keep a cookie updated with the current section of the page, this also solves the problem of people using the back and forward buttons when entering and leaving the page, however does nothing for in page back and forward functionality)
3) If there is no hash or bookmark you can assume this is a new user create a bookmark and load the default section.
On clicking a link:
Update the cookie, Update the hash, load the new section.
This was just a quck thought, as Im a designer not a dev and dont have to do the dirty work myself most of the time. So Im just throwing this out to be picked apart.
Back in a shopping cart should always be a contextual "cancel" -- if you're on the page asking for final authorization, its the same as "no". If you're on the page showing you the items you have ordered, its the same as "go back to shopping". Forward should always be the same as hitting the submit button -- forward on the "whats your address" form should process the form if it is sufficiently filled in or throw an error if it isn't. Forward on final authorization should get you "Thank you for this order!". For a CMS application the metaphors are different but the functionality should be pretty similar -- back when reviewing a draft causes the draft to be edited but not published, forward causes it to proceed to the next stage of the workflow.
Help poke pirates in the eyepatch, arr.