...

View Full Version : Loading a page on unload?



babadi
07-09-2005, 03:49 PM
Hello,

Here's what I need to do: when a certain page unloads, I need to load a certain other URL. The page that is to be loaded doesn't have any HTML content, and it would be just as well if the user didn't even know of it being loaded. It's simply a PHP script that updates a record in a database reflecting that the page is being unloaded.

1. One way I know I could definitely do this is on unload, pop open a popup (or maybe pop-behind) window. Since so many people use popup blockers, though, this isn't ideal.

2. Another thought I had was that on unload, I could set an IFRAME on the page to point to my script URL. This has worked in superficial testing, but I'm concerned that it may not always, i.e. if the server is taking too long to respond, and the unload takes place before it does.

Any thoughts?

Thanks,
Martin

vwphillips
07-09-2005, 05:09 PM
If you are controlling the page to be loaded

The url could be passed to the php page which is loaded in a hidden iframe

the php page can have an onload event to load the page it has been passed

babadi
07-10-2005, 01:14 AM
I don't have control over the page to be loaded.

Thanks,
Martin

Willy Duitt
07-10-2005, 01:37 AM
If the page that is to be loaded "doesn't have any HTML content" and you "don't have control over the page"... Why are you wanting to force this upon your unsuspecting visitors?? And why are you trying to do this without "the user didn't even know of it being loaded"...

What's the purpose of all this... keylogger
All seems rather malicious...

.....Willy

babadi
07-10-2005, 02:40 AM
It is completely beyond me how what I describe could be construed as "malicious."

This is for a content management system. When the user goes onto the "edit article" page, a "locked" flag is set in the database to indicate that that article is in use, so that another user cannot edit it at the same time. When the user navigates away from the page -- whether he's going to another page within my application or not -- I want to transparently load a PHP page that causes the article to be "unlocked" so that others can work on it.

Sheesh.

jscheuer1
07-10-2005, 03:00 AM
Better to just run the PHP code onunload then.

babadi
07-10-2005, 04:27 AM
JavaScript can't run PHP...

Jalenack
07-10-2005, 05:21 AM
Or can it? Javascript can run PHP, in a way, using AJAX. Really, I see this as the only way to do what you're trying to do without requiring a 'transition' page that requires the user to continue on.

Use the onunload event in javascript to send a request to the server, telling you that the article is 'free'

AJAX is a technology that allows javascript to load data from the server without reloading the page. Google it, look for it in the wikipedia, and find the webpasties AJAX article. It's brilliant.

I know a lot about ajax, so if you have any problems post here or contact me (http://blog.jalenack.com/contact.php)

Willy Duitt
07-10-2005, 08:23 AM
It is completely beyond me how what I describe could be construed as "malicious."

This is for a content management system. When the user goes onto the "edit article" page, a "locked" flag is set in the database to indicate that that article is in use, so that another user cannot edit it at the same time. When the user navigates away from the page -- whether he's going to another page within my application or not -- I want to transparently load a PHP page that causes the article to be "unlocked" so that others can work on it.

Sheesh.

Sheesh...

This should be done serverside...
Javascript is NOT your solution...

Good Luck;
.....Willy

Jalenack
07-10-2005, 09:03 AM
Willy Duitt, how exactly do you propose to do it server-side?

You would have to rewrite all links to pass through a silent page first. That would destroy the usability of the links. PHP can't tell when a page has stopped being viewed.

I still see some sort of AJAX implementation as your cleanest option.

Willy Duitt
07-10-2005, 09:29 AM
Willy Duitt, how exactly do you propose to do it server-side?

You would have to rewrite all links to pass through a silent page first. That would destroy the usability of the links. PHP can't tell when a page has stopped being viewed.

I still see some sort of AJAX implementation as your cleanest option.


What the heh do any of the links have to do with anything??
If anything, change the link to the edit page each time it is visited and an entry is created...
If you wish to pay me to create such an anti-leaching script... Show me the money!!

Elsewise, I'm only saying that the solution is certainly not clientside using javascript... Then again, what the heh do I know other than AJAX cleans my toilet real good... If you have a cleaner solution, feel free to freely share it...

.....Willy

babadi
07-10-2005, 07:33 PM
What the heh do any of the links have to do with anything??
If anything, change the link to the edit page each time it is visited and an entry is created...
If you wish to pay me to create such an anti-leaching script... Show me the money!!

Elsewise, I'm only saying that the solution is certainly not clientside using javascript... Then again, what the heh do I know other than AJAX cleans my toilet real good... If you have a cleaner solution, feel free to freely share it...

.....Willy

I really have no idea what you're talking about. There's no way this could be done not on the client side. The goal is to detect when the client has navigated away from a page. The server doesn't have the foggiest idea when the user navigates away from the page. So I'm clueless as to what you're suggesting here.

I will investigate the AJAX solution that was suggested. Thank you.

glenngv
07-11-2005, 06:10 AM
Try this:

onunload=function(){
var php = new Image();
php.src="unlock.php?id=<? id ?>";
alert('You chose not to update the article. All entered data was lost.'); //you have to do this to enable the php script to be loaded.
}I don't know PHP so the syntax may be wrong. But you get the idea.

babadi
07-11-2005, 03:09 PM
glenngv,

Very interesting. My only question would be, is there a chance that the unload event could occur before the unlock page loads? For example, what would happen if the server stalls and takes 5 seconds to load the unlock page? Would the unload be delayed until the request goes through or times out, or would it just unload anyway, leaving the article locked?

jbot
07-11-2005, 03:24 PM
The goal is to detect when the client has navigated away from a page. The server doesn't have the foggiest idea when the user navigates away from the page.

on every internal click and every form submission set a value to say that the user is still using the app. then onunload, check for the existence of said value, if it doesn't exist then, call your serverside script by opening a new window which itself closes on load. on the otherhand if the boolean does exist, then return false on the unload script. ok! :thumbsup:

SpirtOfGrandeur
07-11-2005, 03:49 PM
babadi,


I would like to start off by saying that this is the wrong way to go about this. You should NEVER lock a record from editing. Letís say USER1 goes to the page and locks the record. USER1's boss then comes over for an impromptu meeting and has to leave his PC for an hour or two. In the mean time USER2 needs to update the record. This blocks him from doing it for hour(s). Ok so letís say that you implement one step further to say that after 5 minutes you have a process that goes through and unlocks all the pages that have been locked for 5 minutes or more. What happens if USER1 is in the middle of an edit. It might take some one 10 minutes to edit a page. USER2 gets the edit page because the 5 minutes have passed. There is no correct way to handle this other then storing the information before it has changed and then checking if it has changed before updating the database. But, this is usually unreasonable.


I will offer my advice on this, take it or leave it as you will. In all databases there is a field called TIMESTAMP. This is a special field used by the DB to keep a record of when the row was last updated. Every time the row is updated it updates the timestamp, if it is a field in the row. Just do a DB convert to change this binary into an integer. Put it in a hidden field on the page. Now when you get all the information for the save you check the TIMESTAMP against the one on the page. And if it matches you update. If it does not match you display both rows and have the user decide on which one he wants to update the DB with. The user can do this by either keeping the one already in the DB or overwriting with his information. As a next step on this page you could even allow the user to decide which fields he wants to update with his information and which one he wants to keep from the original record.


I hope this all helps. And I hope that I did not step on any toes by writing this up.

babadi
07-11-2005, 05:54 PM
babadi,


I would like to start off by saying that this is the wrong way to go about this. You should NEVER lock a record from editing. Letís say USER1 goes to the page and locks the record. USER1's boss then comes over for an impromptu meeting and has to leave his PC for an hour or two. In the mean time USER2 needs to update the record. This blocks him from doing it for hour(s). Ok so letís say that you implement one step further to say that after 5 minutes you have a process that goes through and unlocks all the pages that have been locked for 5 minutes or more. What happens if USER1 is in the middle of an edit. It might take some one 10 minutes to edit a page. USER2 gets the edit page because the 5 minutes have passed. There is no correct way to handle this other then storing the information before it has changed and then checking if it has changed before updating the database. But, this is usually unreasonable.
*snip*

I see where you're coming from with this, but given the circumstances, I feel that a locking mechanism is necessary. The app is to be used for writing/editing articles, and any given article may be edited by 5 or 6 people. I find it to be imperative that no more than one user be able to access the article a time, because if this is not the case, there is too good a chance that somebody will lose work, possibly hours of work.

It seems to me that if two users edit the same article at once, there must be one of two outcomes:

1) Person B's changes overwrite Person A's changes. Person A loses his work.
2) Person B is prompted, "This article has been edited by both you and Person B, whose changes do you want to keep?" Depending on the response, either Person A or Person B loses work.

For this application, neither of these outcomes is acceptable. So unless there's something I'm missing, I feel that a locking mechanism is a necessary evil here.

Thanks,
Martin

SpirtOfGrandeur
07-11-2005, 08:03 PM
But what happens if person A opens it for editing and then leaves for the day without closing the browser? Just leaves it in edit mode? You could even have a Hidden IFRAME or XMLHTTPRequest Object that pulls that Timestamp back to the page every few seconds to see if the article has been updated. And if it has been updated display the update. But I must plead with you not to use a Locking Mechanism. They are never necessary evils. They are small patch over a giant hole.

You also make it sound like you are not logging changes. You should be logging the field with a DB Trigger so that AuthorA can see what has changed over time.

I know that you will probably ignore all that I am telling you right now. But from my experience (10+ years in the web application world) locking never works out the way you expect it.

*EDIT*
I just thought up another GREAT Example. User A opens up an article for editing. Makes a change saves it do the database and then goes back in to edit it because he thought me missed something. He goes back to edit it and notices there is nothing wrong. His Internet Explorer (Insert whatever browser you want here, they all crash) crashes and he just closes it and never opens back up the program for 3 weeks. Therefore he has his lock for three weeks while other users are trying to edit it.

babadi
07-11-2005, 09:16 PM
But what happens if person A opens it for editing and then leaves for the day without closing the browser? Just leaves it in edit mode? You could even have a Hidden IFRAME or XMLHTTPRequest Object that pulls that Timestamp back to the page every few seconds to see if the article has been updated. And if it has been updated display the update. But I must plead with you not to use a Locking Mechanism. They are never necessary evils. They are small patch over a giant hole.


That's no good, because what if, in those few seconds, the user has already made changes? Again, you're going to lose work. Even if you prompted the user before doing this, then if two users have the article open, you're going to prompt both of them every X seconds to overwrite their work with the other person's? That'd be pandemonium. I absolutely see your point, but there's a reason why a program like MS Word doesn't allow two users to edit the same document at the same time: Data loss is not only likely, it's inevitable.

Perhaps the thing to do would be allowing the system administrator to manually unlock a locked article, for situations like the one you describe.



*EDIT*
I just thought up another GREAT Example. User A opens up an article for editing. Makes a change saves it do the database and then goes back in to edit it because he thought me missed something. He goes back to edit it and notices there is nothing wrong. His Internet Explorer (Insert whatever browser you want here, they all crash) crashes and he just closes it and never opens back up the program for 3 weeks. Therefore he has his lock for three weeks while other users are trying to edit it.

This is a very valid point, but it's not too hard to address. I put a hidden IFRAME on the page that refreshes every X seconds, each time "renewing" the lock. If the lock isn't renewed for Y seconds (Y > X), it is assumed that the browser window was closed, network connectivity was lost, etc., and the article is unlocked.

Jalenack
07-12-2005, 05:18 AM
I think this would be a good option:

Have a "timer" (setTimeout() will do) that will unlock the page after X minutes. Then, have events on changeable things like textareas. Or you could just have some mouseover stuff. Every time there is a change in one of the items (the user types into the textarea, for example), the timer is reset back to the beginning. If it ever reached your max time, then the browser will send the data to a 'temporary' database or something, or just saved.

glenngv
07-12-2005, 05:58 AM
Even if you allow one person at a time to edit an article, loss of work is still possible if a person edits it and overwrites the whole article created by another person.

jbot
07-12-2005, 09:23 AM
Even if you allow one person at a time to edit an article, loss of work is still possible if a person edits it and overwrites the whole article created by another person.

... which brings up the need for a source-control like solution.

glenngv
07-12-2005, 09:28 AM
Yeah, version control system. Something like SourceSafe.

babadi
07-12-2005, 01:51 PM
Each revision is saved as a separate database record, with an administrator-only option to revert to previous revisions.

The idea of timing out a session after a certain amount of inactivity is a good one. I'll definitely take that into consideration.

Thanks to all for your input.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum