onbeforeunload and onunload

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Senior, Medior and Junior SAP HANA Developer

Vacature details Vakgebied: Software/IT Opleiding: Medior Werklocatie: Veldhoven Vacature ID: 12696 Introductie Our client is the world's leading provider of lithography systems for the semiconductor industry, manufacturing complex machines that are critical to the production of integrated circuits or chips. Our purpose is “unlocking the potential of people and society by pushing technology to new limits”. We do this guided by the principles “Challenge”, “Collaborate” and “Care”. Wat verwachten we van jou? SAP Certified Application Associate - SAP HANA Cloud Modeling (training and/or certification) Bachelor degree or higher Excellent understanding of SAP HANA (2.0 / Cloud), Data Modelling and writing

Bekijk vacature »

Pagina: 1 2 volgende »

Jasper

jasper

28/05/2009 11:41:00
Quote Anchor link
Ik zit met een probleem. Ik moet bij het afsluiten van mijn browser of bij het veranderen naar een andere pagina een php pagina uitvoeren. Dit doe ik a.d.h.v. een ajax_do. Nu is het zo dat hij dit soms doet en soms ook niet. Dus soms voert hij het script uit maar 1/5 keren doet hij het niet. Hoe kan ik dit eventueel oplossen?
 
PHP hulp

PHP hulp

01/11/2024 05:24:11
 
RvW Of toch niet

RvW Of toch niet

28/05/2009 11:47:00
Quote Anchor link
wat is je script dat je daar voor gebruikt
en weetje de reden waarom het soms niet werkt
 
Thom nvt

Thom nvt

28/05/2009 12:29:00
Quote Anchor link
Met welk doel wil je dit doen?
kun je niet gewoon op de volgende pagina je script uitvoeren?
 
Jasper

jasper

28/05/2009 12:55:00
Quote Anchor link
Neen het is een locking systeem dus wanneer een bepaald iets gewijzigd wordt moet het gesloten worden voor andere users en wanneer men dan uit de pagina gaat moet dat script altijd worden uitgevoerd op gelijk welken pagina en ook moet bij het sluiten van de browser het scriptje worden uitgevoerd

dit zet ik in de body:

onbeforeunload="close();" onunload="close();"

---- dit is de javascript vandiezelfde pagina ------
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
        function close()
        {  
            
            ajax_do("close.php?id="+<?php echo $reqidedit; ?>);
            ajax_do("close.php?id="+<?php echo $reqidedit; ?>);
        }
      



------ pagina close -----
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php include('inc_connect.php');
    $id = $_GET['id'] ;
    $query= "UPDATE requirements SET req_opened='0' WHERE req_id='".$id."'";
    mysql_query($query) or die (mysql_error());
?>



erg groot is de code niet
 
Thom nvt

Thom nvt

28/05/2009 14:24:00
Quote Anchor link
als je nou eens in je stukje i.p.v. dit

onbeforeunload="close();" onunload="close();"

dit zet:

onbeforeunload="return false; close();" onunload="return false; close();"

dan breek je alle andere bewerkingen af die normaal uitgeoverd worden. dan kun je net even wat makkelijker debuggen (kijken welke waarde terug wordt gegeven bijvoorbeeld.)
 
Jasper

jasper

28/05/2009 15:03:00
Quote Anchor link
niets werkt er, heb al vanalles geprobeerd. Is er niemand die hier een andere manier weet om een locking systeem op te zetten!?

thx
 
Thom nvt

Thom nvt

28/05/2009 15:58:00
Quote Anchor link
wat ik doe in mijn CMS is gewoon het document laten unloacken bij het opslaan of sluiten via de web interface. als men de borwser (of het tabblad) sluit word het document niet geunlocked. Dat is geen probleem want de persoon die hem heeft gelock kan nog gewoon toegang krijgen.
Je kunt mijn code van google code af halen. source code
 
Jelmer -

Jelmer -

28/05/2009 16:20:00
Quote Anchor link
Je kan ook de pagina iedere 30 seconden o.i.d. een melding laten doen dat het bestand nog steeds gelockt moet zijn. Bij die requests update je dan een regel in je database met de huidige datum/tijd. Is die datum/tijd meer dan 60 seconden geleden, dan wordt het document op dat moment blijkbaar niet bewerkt, en is het geünlockt.
 
Sam Smekens

Sam Smekens

28/05/2009 16:22:00
Quote Anchor link
Wat wil je bereiken met het script?
 
Thom nvt

Thom nvt

01/06/2009 19:26:00
Quote Anchor link
Jelmer schreef op 28.05.2009 16:20:
Je kan ook de pagina iedere 30 seconden o.i.d. een melding laten doen dat het bestand nog steeds gelockt moet zijn. Bij die requests update je dan een regel in je database met de huidige datum/tijd. Is die datum/tijd meer dan 60 seconden geleden, dan wordt het document op dat moment blijkbaar niet bewerkt, en is het geünlockt.


Is niet handig. Dat creëert enorm veel server load, zeker met meer gebruikers.
 
Jelmer -

Jelmer -

01/06/2009 20:03:00
Quote Anchor link
termination schreef op 01.06.2009 19:26:
Is niet handig. Dat creëert enorm veel server load, zeker met meer gebruikers.


Apache en PHP hebben er niet zoveel problemen mee, grootste zorg is al de UPDATE queries die MySQL moet verwerken. Op een server waar ik deze methode gebruik was dat het probleem, en ik heb het opgelost door een daemon in PHP te schrijven (ja, het kan echt! :P) en dat lijkt erg goed te werken. Gemiddeld handelt hij 100 gebruikers tegelijkertijd (met 10 of minder seconden interval) af en dat is geen enkel probleem.
 

01/06/2009 20:03:00
Quote Anchor link
termination schreef op 01.06.2009 19:26:
Jelmer schreef op 28.05.2009 16:20:
Je kan ook de pagina iedere 30 seconden o.i.d. een melding laten doen dat het bestand nog steeds gelockt moet zijn. Bij die requests update je dan een regel in je database met de huidige datum/tijd. Is die datum/tijd meer dan 60 seconden geleden, dan wordt het document op dat moment blijkbaar niet bewerkt, en is het geünlockt.


Is niet handig. Dat creëert enorm veel server load, zeker met meer gebruikers.

Dat valt reuze mee, je hoeft ook echt niet gigantisch veel data te versturen, en die server hoeft ook niet gigantisch veel uit te voeren (misschien wel als de gebruiker weg is).
 
Thom nvt

Thom nvt

01/06/2009 20:05:00
Quote Anchor link
je kan van mij aannemen dat ik heel wat systemen heb zien dichtlopen op redeneringen zoals deze.
Je weet nooit, maar dan ook NOOIT of je iets uitbereid.
ook al is het niet veel data, en hoeft de server niet veel te doen ,het blijft load.
En met 1 gebruiker zal het geen probleem zijn, met 100 misschien ook niet maar met meer zal je het toch gaan merken.
 
Jelmer -

Jelmer -

01/06/2009 20:14:00
Quote Anchor link
Je hoeft niet altijd uit te breiden, je kan ook verbouwen. Mocht je meer bezoekers trekken, dan wordt het ook tijd voor een eigen server in plaats van shared hosting, en dan kan je na gaan denken over een aparte andere server onder een ander subdomein zodat je voor het pollen heel Apache en PHP omzeilt.

Je kan ook een andere techniek gaan implementeren, maar ik zou geen alternatief weten dat beter werkt voor deze toepassing (bijhouden of iemand nog op je website zit)
 
Thom nvt

Thom nvt

01/06/2009 20:18:00
Quote Anchor link
beter meteen goed doen dan later moeten verbeteren zeg ik altijd.
Toch blijf ik het vreemd vinden dat onbeforeunload niet werkt.
Als ik het hier probeer met dezelfde code word alles netjes weggeschreven.
misschien iets vaags in de server of client????
 
Jelmer -

Jelmer -

01/06/2009 20:26:00
Quote Anchor link
Op zich maakt het niet zoveel uit of het tijdens het testen wel of niet werkt, het legt bepaalde verantwoordelijkheid bij het meest onbetrouwbare deel van een internet-applicatie: de client. Je weet niets over je client, hoe kan je hem dan vertrouwen dat hij meldt dat hij z'n venster sluit? Wat als ik mijn browser force-quit? Wat als de stroom uitvalt?

Normaal, omdat HTTP stateless is, is dat geen probleem. Maar de TS wil hier 'state' introduceren, namelijk het locken van een document. Het lijkt mij vrij essentieel dat dat document weer geopend wordt, zo essentieel dat je daarvoor niet afhankelijk van wilt zijn van de client.

Daarom lijkt mij polling in plaats van zo'n event-achtige opbouw een veel veiliger idee. En zolang de website klein blijft, is dat geen probleem. Dat is aan de TS om te beslissen. Hoe groot is de kans dat zijn website zo groot wordt dat hij moet gaan nadenken over load? Ik denk dat maar een heel miniem deel van alle websites die hier met de hulp op PHPhulp worden gemaakt bekend zullen worden.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 
Thom nvt

Thom nvt

01/06/2009 20:29:00
Quote Anchor link
ik ben het deels met je eens, maar laten we niet verder offtopic gaan.
Als je voor de oplossing met polling gaat doe ht dan alsjblieft maar eens in de zoveel minuten met een cronjob. gewoon een PHP file op de server uitvoeren, scheelt een hoop requests.
 

01/06/2009 20:32:00
Quote Anchor link
Waarvoor door de server? Waarvoor niet door de client? De client kan best wel iets sturen en dat opslaan in een db ofzo.
Als iemand anders dat document dan wilt gebruiken, dan kan de server kijken of de tijd groot genoeg is.
 
Jelmer -

Jelmer -

01/06/2009 20:44:00
Quote Anchor link
Dat bedoel ik: de client pollt, hij vraagt, of beter gezegd, meldt om de zoveel seconden dat hij er nog is. Je kan het wel combineren met zo'n onunload-event trouwens, dan kan je het pollen wat minder vaak doen, omdat het dan vooral nog dient om de foute clients die niet melden dat ze gaan stoppen niet schadelijk te laten zijn.

Stel dat de client iedere 5 minuten tegen de server zegt dat hij nog bezig is, en ook probeert om bij onunload te melden dat hij klaar is. In het beste geval hoeft de volgende gebruiker die datzelfde bestand wil bewerken zo goed als niet te wachten. In het ergste geval moet hij 5 minuten wachten, totdat de tijd die de eerste client had gereserveerd door te pollen is verlopen.
 
Thom nvt

Thom nvt

01/06/2009 20:45:00
Quote Anchor link
maar waarom zou de client elke zoveel minuten de server moeten pollen??
 

01/06/2009 20:48:00
Quote Anchor link
Om te kijken of ie er nog is.
Dat is toch het hele punt.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.