8 berichten aan het bekijken - 1 tot 8 (van in totaal 8)
  • Q:
    Bijdrager
    MacTommy

    Javascript / AJAX: PHP uitvoeren onUnload

    Ik wil een PHP file uit laten voeren op het moment dat een gebruiker een HTML-pagina verlaat.
    Dus ik heb een Javascript functie die aangeroepen wordt onUnload.

    Nu wordt de PHP wel uitgevoerd als de pagina verlaten wordt doordat er op een link geklikt wordt, maar NIET als er op de back-knop (of backspace) wordt geklikt.

    Iemand enig idee hoe dat komt en hoe dat op te lossen..?!?

    Hartelijk dank!

    Bijdrager
    iJoost

    Waarschijnlijk treedt er dan een fout op. Even de Foutconsole openzetten en kijken wat er precies gebeurt. Desnoods wat debug-code toevoegen als het de Foutconsole niet genoeg blijkt.

    (Maar eerlijk gezegd is het wel wat dubieus. De onunload is niet echt bedoeld om op dat late moment nog veel code uit te gaan voeren.)

    Bijdrager
    MacTommy

    Nee klopt. Het gaat dan ook niet om heel veel code.
    Het betreft een database applicatie en de gebruiker moet wat records kunnen bewerken. Omdat niet meerdere gebruikers hetzelfde moeten kunnen gaan zitten bewerken zorg ik ervoor dat de relevante cellen even ‘gelockt’ zijn. En als de gebruiker er dan mee stopt dan moeten die cellen dus weer ge-unlockt worden (om het maar eens in het Nederlands te zeggen..;-) )

    En Firebug (en Javascript debugger voor Firefox) geeft geen errors. Het lijkt er ook eigenlijk niet op dat er iets fout gaat, want als je dus op een link klikt en de pagina ‘unload’ dan gaat het wel goed. Alleen dus als je via backspace/back button unload, dan niet.

    Bijdrager
    iJoost

    Mmm… Dat is volgens mij geen goed plan.

    Wat doe je namelijk als er een browser crasht? Ga je misschien ook nog een achtergrond-proces maken om de verloren locks na verloop van een timeout weer op te zoeken en verwijderen? Of ga je het met de hand doen zodra de gebruiker komt klagen?

    Denk er nog eens over na.

    In veel gevallen heb je helemaal geen expliciet lock nodig omdat de data waarop verschillende gebruikers werken in de praktijk eigenlijk nauwelijks overlapt.

    Mocht het wel een probleem zijn, dan kun je misschien beter het volgende doen: Neem de laatst gewijzigd datum van het record mee naar het scherm en op het moment waarop dat scherm gewijzigd weer teruggePOST wordt kijk je dan met behulp van die meegenomen datum of het record ondertussen niet door iemand anders gewijzigd is.

    Bijdrager
    MacTommy

    Ja, is waar. Als iemand gewoon de stekker eruit trekt ofzo dan heb je allerlei gelockte records die eeuwig blijven bestaan en dat soort ellende. Dus dan zou je iedere nacht iets moeten draaien wat ze allemaal unlockt ofzo. Niet erg elegant inderdaad.
    Maar gewoon hopen dat simultane bewerkingen niet gebeuren vind ik ook niet zo’n geweldige oplossing.

    Maar hoe dan ook, ondertussen intrigeert het me toch waarom die unload-event anders reageert bij unloaden door een link klikken en unloaden door op de back-button te klikken. Had ik gewoon nooit verwacht…

    Bijdrager
    iJoost
    ”MacTommy”

    Ja, is waar. Als iemand gewoon de stekker eruit trekt ofzo dan heb je allerlei gelockte records die eeuwig blijven bestaan en dat soort ellende. Dus dan zou je iedere nacht iets moeten draaien wat ze allemaal unlockt ofzo. Niet erg elegant inderdaad.
    Maar gewoon hopen dat simultane bewerkingen niet gebeuren vind ik ook niet zo’n geweldige oplossing.

    Reken er voor de grap eens uit hoe groot de kans is, zou ik zeggen. Het hangt grotendeels af van het soort gegevens waar het om gaat. Hoe groot de overlap is in het gebruik door verschillende gebruikers. En zoals ik al aangaf, je kunt ook “optimistisch locken”. (State is evil.;-)

    Maar hoe dan ook, ondertussen intrigeert het me toch waarom die unload-event anders reageert bij unloaden door een link klikken en unloaden door op de back-button te klikken. Had ik gewoon nooit verwacht…

    Als ik zoek met Google vind ik kreten als “notoriously unreliable from browser to browser”.

    Er is trouwens ook nog een onbeforeunload. Je zou kunnen proberen of dat beter gaat.

    Bijdrager
    MacTommy

    Ha ha. Ja, notoriously unreliable ja. Nou ok, ok, ik kap ermee.

    Het idee was alleen dat de eerste gebruiker de meest relevante gegevens zou krijgen (gesorteerd op een of andere score) en degene die het daarna probeert dus de volgende uit de rij. Dus de kans dat men simultaan gaat bewerken als je er verder niks op bedenkt is zo’n beetje 1.
    Maar goed, verder heb je wel gelijk natuurlijk, ik moet het gewoon in een hele andere hoek gaan zoeken.

    Zal wel weer goed komen, maar toch blijft het vreemd…

    Hoe dan ook, hartelijk dank voor het (mee)denken!!

    (En onBeforeUnload is trouwens volgens mij alleen voor IE, als ik het goed heb gelezen ergens vanmiddag…)

    Bijdrager
    iJoost

    Ai, zit ik hier Internet Exploder blubber voor te stellen?:-(

    Niet in vorm.;-)

    Overigens als het gaat om een workflow queue (of iets in die sfeer) dan heb je helemaal gelijk dat je iets moet doen.

    Wat denk je van het volgende:

    Zodra een gebruiker een item opvraagt (het scherm erop opent), leg je een relatie tussen de gebruikerstabel en het item. In het lijstje toon je normaal alleen de items zonder relatie en de items waarmee de gebruiker zelf al een relatie heeft. Met een vinkje is het ook mogelijk om alle items (ook die van andere gebuikers) te zien te krijgen. Als een gebruiker toch een item opent wat niet van hem/haar is of vrij is, dan geef je een waarschuwing en moet de gebruiker kiezen of ie het item wil overnemen of toch maar liever wil laten zoals het is.

    Je hebt op deze manier een lock (aan een gebruiker) en laat het aan het boerenverstand en het samenwerkingsvermogen van de gebruikers over om “verloren” locks op te lossen.

8 berichten aan het bekijken - 1 tot 8 (van in totaal 8)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.