View Single Post
  #18 (permalink)  
Old October 7th, 2008, 08:08 AM
Ron Howerton Ron Howerton is offline
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

Old Pedant:

There was no button originally, although I tried going that route as well as many other solutions I stumbled across on the web. There appeared to be no difference between coding a button, a function, or clicking F5 - it still displayed that *&^%$ dialog box. So calling the button, hidden or not, still forces the users to click yet another button, and our users dislike having to click even one button. Automatically refreshing on update works as effectively, although I consider it an incomplete solution. At least the report disappears and the users HAVE to do something to get it back, unlike the way it was, where they weren't even bothering to refresh despite urging them to frequently do so. If I could get it to submit the refresh ONUNLOAD, I'd have done that instead, but it kept telling me that the window object didn't exist so I gave up going that route.

While some of our users are undoubtedly evil, most of them are just ignorant, and ALL of them are identifiable, because this is an INTRANET site with no external access. Furthermore, we are a gov't agency with the authority to legally punish any employees out to hack our system. It's therefore very unlikely that anybody would submit anything to screw with the system and this "security feature" is clearly unnecessary in our environment (and I would think others maintaining Intranet sites would have a similar issue). There really ought to be a way to submit a refresh and override that unnecessary dialog in such circumstances, but I expect I am singing to the choir when it comes to the many limitations associated with developing web applications. Hello, W3C?

joefawcett:

I tried that, too. Problem with setting href is that the report was no longer able to read the report selection form fields using request.form. Resetting the href value appears to redirect rather than refresh, losing that magical connection between browser windows that Old Pedant pointed out to me. And it can't build the report if I don't know what the user was looking for. I can't switch to GET because the amount of data passed between the pages exceeds the url maximum length (another unfortunate and arbitrary limitation, imho). Cookies have a similar limitation, and our server seems unable to hold onto sessions long enough to rely upon session variables.
Reply With Quote