Well, I'm first of all not sure the "evil back button" is something you should be fighting in the first place... there is a whole group of developers who believe messing with what the button does in any way is bad design. Their reasons are sound IMO: users expect their browsers to work a certain way, the back button especially, and trying to defeat that provides a confusing user experience at best, and an experience they don't want to stick with at worst (i.e, you'd hate for your client to lose sales because you somehow disabled the back button!)
Now, that being said, I've historically for one not been in that group, but that's a consequence of the type of development I've typically done: very complex back-office applications. The goal with those apps has been to more or less give a fat-client experience with web technologies (one could ask why we didn't just do fat clients in the first place, but that's a debate for another day). In these types of cases, I think you can, and have to really, get away with a lot more. Popping a new window that doesn't have a back button for example (which doesn't mean the back functionality is disabled, it's still accessible via keyboard shortcut, but at that point it becomes a trainig issue). So, I think that you first want to make sure you really want to do what your talking about in the first place. You may instead want to design your app in such a way that what your trying to eliminate doesn't cause a problem in the first place. If you decide you still want to do it, I think you were probably on the right track... I would probably off the top of my head think of doing like your saing, fire an AJAX request onLoad of the page. The server part could be as simple as storing some sort of page ID in session. Return a response code that indicates whether it is OK for the user to be on that particular page at that point in time, and redirect or alert if not. Then again, you probably don't have to even get the server involved: why not just store the ID in a cookie and check that? Then again, doing it server-side would allow you to have some more complex logic for determing when a page is valid or not. It would also have the side benefit of allowing you to confirm the server is still available... might be nice pop a message if it goes down, or redirect them to an alternate site, something like that. Oh yeah, and you'll need to ensure they can't do anything on the page before the request returns. A transparent GIF sized to the page with a higher z-index than everything else does the trick, albeit simplistically. Now, all of this presupposes Javascript is available, so if there's a possibility it won't be, your hosed. So, when all is said and done, is any of this really worth it? That's the important question to ask I think... I'm pretty sure I wouldn't implement anything like this in the first place, I'd instead figure out how to make my app more tolerant of user navigation. Probably less work in the long run, and almost certainly a better user experience too. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, January 22, 2007 4:03 am, Peter Neu wrote: > Hi Frank, > > I just read your post. What would you suggest as a clean solution for the > backward problem? As suggested before the reload does not happen in all > browsers when the user hits the backward button.... So what to do? > > Cheers, > Pete > >> -----Ursprüngliche Nachricht----- >> Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] >> Gesendet: Freitag, 19. Januar 2007 17:50 >> An: Struts Users Mailing List >> Cc: 'Struts Users Mailing List' >> Betreff: Re: Timed Java Script Request & Struts? >> >> I'm not sure what your suggesting is architecturally a good idea, but >> that's for you to decide :) I'm all about helping you make it happen >> regardless, so... >> >> In addition to the options others have mentioned, another to consider is >> the AjaxParts Taglib (APT), a part of Java Web Parts (JWP): >> >> http://javawebparts.sourceforge.net/ >> >> More specifically: >> >> http://javawebparts.sourceforge.net/javadocs/javawebparts/ajaxparts/taglib >> /package-summary.html >> >> This will allow you to fire an AJAX request on a timer, without having >> to >> write any Javascript. It will work with Struts 1.x, 2.x, or any other >> (java-based) framework. >> >> Frank >> >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> AIM/Yahoo: fzammetti >> MSN: [EMAIL PROTECTED] >> Author of "Practical Ajax Projects With Java Technology" >> (2006, Apress, ISBN 1-59059-695-1) >> Java Web Parts - http://javawebparts.sourceforge.net >> Supplying the wheel, so you don't have to reinvent it! >> >> On Fri, January 19, 2007 9:09 am, Peter Neu wrote: >> > Hello, >> > >> > >> > >> > in one of my endless attempts to fight the evil browser backward >> button >> > mechanism I was thinging about this: >> > >> > >> > >> > Can I make a periodic java script (ajax) request to determine when a >> user >> > hit the evil button and tries to work >> > >> > a page that is not current anymore? Say the user hit the back button >> and >> > now >> > resides on the "wrong" page >> > >> > I make a hidden ajax request and determine he is in the wrong pace. >> Then >> I >> > give him a notice and send him back >> > >> > to the right place. >> > >> > >> > >> > Is this possible? How would I make the periodic request? >> > >> > >> > >> > Cheers, >> > >> > Pete >> > >> > >> > >> > >> > >> > >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
