[PHP/MySQL] Record 'locken' als 'open'

[Verwijderd]

Ik ben dus bezig met een cms, en wat ik nu wil inbouwen is een oplossing voor het volgende probleem:

Als een user een pagina gaat editen dan wil ik dat er niet tegelijkertijd een andere user ook die pagina kan editen want dan kan je krijgen dat jopie een pagina opent om te editen, een paar seconden later sjakie ook, vervolgens na 3 minuten tikken slaat jopie op. maar na 5 minuten slaat sjakie ook op. dan is dus alles van jopie weg.

Nou zou je zeggen: sim-pel. gewoon een x-tra kolom die 1 is als ie geedit wordt en 0 als ie niet geedit wordt. Dat zou ook goed bij te houden zijn als er te detecteren was of de browser wordt gesloten, maar helaas is dit niet mogelijk. dus een andere oplossing.

Toen bedacht ik het volgende:
Wel die x-tra kolom in de tabel maar dan nog bijhouden hoelang het geleden is dat er getypt is in die pagina. Dus als de tekst edit pagina wordt opgeroepen wordt die kolom op 1 gezet. In mijn tekst edit pagina loopt een timer mee (constant). Als een toets wordt ingedrukt dan wordt de timer gereset. Op het moment dat de timer meer dan n seconden aan het lopen is wordt een php pagina in een iframe dat zich onzichtbaar op de pagina bevindt gerefreshed die vervolgens de kolom weer op 0 zet. Vervolgens kan die pagina dus weer door andere geedit worden.

Mocht de gebruiker van hierboven dan weer actief worden en weer willen gaan tikken dan kijkt de pagina eerst of de kolom nog steeds op 0 staat (of dat er misschien dus ondertussen een andere gebruiker aan het editen is geslagen). zoja, dan kan de gebruiker weer verder, zo nee, dan wordt er een melding gegeven dat een andere gebruiker nu de pagina aan het editen is en wordt de mogelijkheid gegeven om de getypte tekst op te slaan op de hdd zodat de getypte tekst niet verloren gaat en later alsnog geplaatst kan worden.

Iemand nog verfrissende andere ideeen? Wat vinden jullie van mijn idee?

[Glimi]

Ik zou proberen niet te slim te doen. Klinkt heel raar, maar als jij voor de gebruiker gaat bepalen dat de boel unlockt moet worden, terwijl hij dat helemaal niet wilt, ben je volgens mij fout bezig.

Daarom denk ik dat het beter is, die intelligentie bij de gebruiker te leggen. Als iemand een bericht gaat editten, maak jij in een (lock)tabel een rij aan waarbij de je gebruiker, tijd en artikel opslaat. Als nu de persoon de browser sluit en de boel gelockt laat, laat je dat lekker zo.
Mocht hij de volgende keer inloggen en verder willen met het artikel, dan kan dat. Anders moet hij het bericht maar unlocken (denk aan een overzicht van de door persoon X gelockte berichten bij inloggen oid).
Verder is het natuurlijk logisch dat een Administrator de boel ook kan unlocken

[MisterData]

Dan moet je natuurlijk ook zorgen dat gelockte pages niet zichtbaar zijn op de site Dan kunnen users halverwege stoppen met typen. Je moet wel duidelijk tegen de user zeggen dattie iets heeft gelockt; met een geel uitroeptekentje boven je pagina met de links naar de pagina's moet duidelijk genoeg zijn.

[Verwijderd]

Maar stel dat je het bij de gebruikers legt..
Jopie locked een tekst pagina, hij komt vervolgens 1 dag niet online. maar in die ene dag moet sjakie diezelfde pagina editen. dat kan dan dus niet.
imho is het toch het beste dat mijn systeem het regeld. want mocht die persoon bijv. 5 minuten niet actief zijn dan wordt ie ge-unlocked. en mocht ie dan weer verder willen dan kan ie dat gewoon doen. mits! er ondertussen niet iemand anders aan het editen is geslagen.

[Verwijderd]

Ik zou het anders proberen te doen. Je moet dit soort processen niet volledig aan het systeem laten.

Deze oplossing heb ik ooit toegepast maar dit betrefte in een origanisatie waar meerdere personen evenveel recht hadden op een bepaalde content te editen. Je zou (vooral als information engineer ) eerst moeten kijken waar het word toegepast en hoe het zit met de policities binnen zoeen bedrijf.

Ik probeer eerst ff uit te leggen wat ik bedoel en dan probeer ik een het in een real sitautie te laten zien zodat misschien mijn denkfouten gecorrigeert kunnen worden:

database velden: [titel] - [inhoud] - [auteur] - [TijdDatum] - [useredit] - [timeedit] - [locklevel]

Neem aan dat 5 users zelde [locklevel 3] rechten hebben om de content te wijzigen, en in de database staat het volgende gevult

[nederland is groen] - [De nederlandse ...] - [Kees] - [10-12-2002 15:00] - [Kees] - [10-12-2002 15:00] - [3]

Jan probeert nu de inhoud te wijzigen en krijg de bericht dat de bericht laatste gewijzigd is gisteren door Kees op x. useredit == auteur.

Jan gaat door met editen => laaste 3 velden wijzigen [Jan] - [11-12-2002 12:39] - [3]

Piet probeert nu de inhoud te wijzigen useredit != auteur. Piet krijg een bericht dan Jan bezig is met wijzigen. En word geadviseerd om niet te wijzigen. (worst case senario) Piet negeert en gaat verder. De laatste database velden wijzigen [Kees] - [11-12-2002 12:40] - [3]. (er word een email gestuurd naar Jan over de event)

Bij het editen worden in de html code 5 hidden velden meegenomen met de inhoud van de laatste auteur, Tijddatum, inhoud, useredit, timeedit.

Nu kunnen er 2 dingen gebeuren of Jan submit eerder of Piet Submit eerder of een van de 2 sluit zijn scherm. Bij het sluiten van de scherm kun je een java popup maken die uitlogd maar we gaan ervanuit dat javascript is uitgeschakeld.

2 situatie:

[useredit] != Jan (en de rest van de verborgen velden kloppen ook niet)
Jan submit eerder en krijgt een melding dat Piet ook wijzigingen probeert te maken (piet krijgt geen waarschuwing meer als het eerder submit). Hij word geadviseerd zijn wijzigingen op te slaan als xml document. (kun je makkelijk een php script voor maken die dat doet). Jan/Piet kiest om wijzigingen door te voeren en op te slaan. Alles word overschreven ook de laatste velden.

[auteur] != [laaste auteur in html verborgen veld] [useredit] != Piet (en zo de rest controleren)
Daarna submit de 2de persoon hij krijgt een venster te zien met het oude bericht en het nieuwe bericht van Jan en zijn eigen bericht. De persoon krijgt dan een optie om zijn bericht aan te passen of de wijzigingen niet door te voeren (eventueel wijzigingen opslaan als xml bestand). En (was optie op private messsage te sturen / email) waar werd gevraag hoe het verder moest. En als de wijzigingen toch werden doorgevoerd werd de gebruiker op de hoogte gesteld.

naja ik had zoeen flow diagram maar die ben ik kwijt . Maja binnenkort ga ik aan een nieuwe cms werken en dan komt alles weer tot leven.

als je meer wilt weten moet je ff contact opnemen op msn of email [e-mail]

btw het systeem hield rekeing mee dan des te minder het recht niveau van de gebruiker was des te minder meldingen hij kon negeren. Dus locked is ook locked op een bepaald niveau. Dus auteur != useredit en dan voor een aantal uurtjes locken. (tijd kun je natuurlijk zelf bepalen)

[ Voor 7% gewijzigd door Verwijderd op 11-12-2002 16:11 ]

[Erik Jan]

Ik zou het zonder fancy JavaScriptjes doen, ongeveer zoals Glimi. Gewoon zorgen dat User1 een bericht kan locken. Als tegelijkertijd User2 het bericht wil wijzigen, krijgt diegene een vriendelijke melding voor z'n neus: Daarin staat dan de naam (en tel.nummer + instant-message gegevens eventueel) van diegene die de huidige lock in zijn bezit heeft, de tijd tussen nu en de laatste activiteit van User1 (een session iets dus, geen rare JS) en de optie om User2 de lock van User1 over te laten nemen. Meld daarbij bijvoorbeeld dat wanneer User2 voor minder dan X minuten geen activiteit heeft getoond, het niet verstandig is om de lock over te nemen.

Als je maar voor de user duidelijk maakt wat de gevolgen van hun acties kunnen zijn, kunnen ze best zelf inschatten of zijn/haar wijziging het plegen van een telefoontje o.i.d. waard is.

[Creepy]

Verwijderd schreef op 11 december 2002 @ 16:02:
Ik zou het anders proberen te doen. Je moet dit soort processen niet volledig aan het systeem laten.


database velden: [titel] - [inhoud] - [auteur] - [TijdDatum] - [useredit] - [timeedit] - [locklevel]

Neem aan dat 5 users zelde [locklevel 3] rechten hebben om de content te wijzigen, en in de database staat het volgende gevult

[nederland is groen] - [De nederlandse ...] - [Kees] - [10-12-2002 15:00] - [Kees] - [10-12-2002 15:00] - [3]

Jan probeert nu de inhoud te wijzigen en krijg de bericht dat de bericht laatste gewijzigd is gisteren door Kees op x. useredit == auteur.

Jan gaat door met editen => laaste 3 velden wijzigen [Jan] - [11-12-2002 12:39] - [3]

Piet probeert nu de inhoud te wijzigen useredit != auteur. Piet krijg een bericht dan Jan bezig is met wijzigen.

Op het moment dat Jan wil gaan wijzigen, wil piet dit ook. Eerst worden de laatste 3 velden gelezen voor Jan.
Dan worden diezelfde velden gelezen door Piet.
Dan worden de velden aangepast dat Jan gaat wijzigen.
En daarna worden de velden aangepast dat Piet gaat wijzigen (want deze velden waren al gelezen door het proces van Piet!!)

Diegene die het laatste op save ragt heeft mazzel, want zijn veranderingen zijn doorgevoerd. (lost update)
*OOPS*

Dit soort dingen los je echt alleen maar op door eerst de boel te laten locken door het DMBS, dan te lezen en wijzigen, en dan pas te unlocken (en dan het liefts ook nog het locken en lezen in 1 transactie).

[Olaf van der Spek]

Verwijderd schreef op 10 December 2002 @ 23:59:
Nou zou je zeggen: sim-pel. gewoon een x-tra kolom die 1 is als ie geedit wordt en 0 als ie niet geedit wordt. Dat zou ook goed bij te houden zijn als er te detecteren was of de browser wordt gesloten, maar helaas is dit niet mogelijk. dus een andere oplossing.

Wat is er met OnUnload (JS) gebeurd?

[Verwijderd]

Creepy schreef op 11 December 2002 @ 16:38:
[...]

Dit soort dingen los je echt alleen maar op door eerst de boel te laten locken door het DMBS, dan te lezen en wijzigen, en dan pas te unlocken (en dan het liefts ook nog het locken en lezen in 1 transactie).

Uiteraard lock je eerst de table voer je de 2 query's uit (lezen en schrijvenen) dan unlocken.

[Freee!!]

Een oplossing (die her en der gebruikt wordt) is voor de update eerst kijken of wat er staat nog steeds hetzelfde is als oorspronkelijk gelezen. Indien niet, dan degene die dit treft waarschuwen (eventueel wijziging laten zien).

[Verwijderd]

OlafvdSpek schreef op 11 december 2002 @ 16:48:
[...]

Wat is er met OnUnload (JS) gebeurd?

zo min mogelijk van de client side uitgaan....

[Verwijderd]

Mr. Liu schreef op 11 december 2002 @ 17:05:
Een oplossing (die her en der gebruikt wordt) is voor de update eerst kijken of wat er staat nog steeds hetzelfde is als oorspronkelijk gelezen. Indien niet, dan degene die dit treft waarschuwen (eventueel wijziging laten zien).

kort maar krachtig.. dan had ik ook beschreven alleen iets langer.. moet toch eens leren kort van stof te zijn

[Verwijderd]

Erik Jan schreef op 11 December 2002 @ 16:31:
Ik zou het zonder fancy JavaScriptjes doen, ongeveer zoals Glimi. Gewoon zorgen dat User1 een bericht kan locken. Als tegelijkertijd User2 het bericht wil wijzigen, krijgt diegene een vriendelijke melding voor z'n neus: Daarin staat dan de naam (en tel.nummer + instant-message gegevens eventueel) van diegene die de huidige lock in zijn bezit heeft, de tijd tussen nu en de laatste activiteit van User1 (een session iets dus, geen rare JS) en de optie om User2 de lock van User1 over te laten nemen. Meld daarbij bijvoorbeeld dat wanneer User2 voor minder dan X minuten geen activiteit heeft getoond, het niet verstandig is om de lock over te nemen.

Als je maar voor de user duidelijk maakt wat de gevolgen van hun acties kunnen zijn, kunnen ze best zelf inschatten of zijn/haar wijziging het plegen van een telefoontje o.i.d. waard is.

ok, ga ik dan denk ik maar op deze manier doen

thanks allemaal!

[jsiegmund]

Mwa kweet niet, anderen de lock ontnemen is vragen om problemen denk ik. Krijg je weer van de situaties dat jantje iets aan het editen is, vrij veel werk gedaan heeft en dan even een bakje koffie gaat halen (toch niet geheel ontdenkbaar ). Tegelijkertijd logt pietje in, ziet dat jantje al zeker 5 min niets meer gedaan heeft, unlockt de file en gaat zijn eigen ding zitten doen. Jantje komt na 10 minuten anti-RSI training terug en al zijn wijzigingen zijn voor noppes geweest.

Mijn idee: timer laten lopen zoals je al doet, als de pagina een half uur niet meer gebruikt is een popup erin gooien... Daar moet de gebruiker binnen 1 minuut op "ingelogd blijven" of iets dergelijks klikken, anders wordt hij automatisch uit het systeem gegooid. Zorgen dat je gebruikers van deze regel afweten en dan houden ze er wel rekening mee. Jan kan nu rustig even koffie gaan halen en z'n polsen relaxen, en daarna zijn wijzigingen doorvoeren, Piet moet gewoon even wachten.
En het browser afsluit probleem vang je dan op door bijvoorbeeld je sessie een max. tijd van een uur te geven waarbinnen wat activiteit (een nieuwe pagina openen of iets dergelijks) getoond moet worden. Is dit niet zo dan wordt de sessie verwijderd. Voor de gelockte bestanden houd je bij door welke sessie ze gelockt zijn. Bij openen checken of het bestand gelockt is... ja => check of het gelockt is door een bestaande sessie => nee, lock opheffen en meteen een lock aanmaken voor de gebruiker die het bestand opvraagt. De andere gevallen kun je zelf ook wel bedenken denk ik.
Dit lijkt me een beter systeem waarin in ieder geval moeilijker misverstanden kunnen ontstaan. Opmerkingen hoor ik graag

[CyberSnooP]

Ik zou voor de Erik-Jan oplossing gaan (dus ander lock laten overnemen als de huidige locker een tijd inactief is).

• Probeer het de gebruiker aantrekkelijk te maken zijn werk vaak tussentijds op te slaan. (altijd belangrijk i.v.m per ongeluk verkeerde backspace (vorige in browser) en dergelijke)
• Zorg dat de bewerker een seintje krijgt zodra zijn lock verloopt (of dreigt te verlopen) Dit moet te doen zijn met een automatisch refreshend frame e.d.
• Maak je waarschuwingen compact en helder, waarschuw diegene die de lock overneemt nadrukelijk en leg hem uit dat ie boos moet worden op die geen die de pagina is vergeten vrij te geven.

Oja: Volledig vertrouwen op client-side truukjes is natuurlijk not done. Denk aan crashende systemen en dergelijke. De mogelijkheid tot gefoceerd unlocken moet je dus altijd bieden.

[ Voor 13% gewijzigd door CyberSnooP op 11-12-2002 21:39 ]

[Verwijderd]

Ten eerste: Dit is natuurlijk het klassieke probleem, en je kan je afvragen hoe vaak het zich voor zal doen, en of er als het zich voor dit niet iets organisatorisch fout zit. Maar dat terzijde.

Ik zou toch wat meer verantwoordelijkheid aan de gebruiker geven, en het systeem zeker niet iets keihard voor 1 iemand editable zetten.

Dit zou ik (ongeveer) doen:
• Gebruiker gaat editten, sla op wie dat is en hoe laat hij daarmee begonnen is (en set die datumtijd opnieuw bij het opslaan.
• Wanneer een andere gebruiker gaat editten, geef je een melding van 'Gebruiker die is toen aan het editten gegaan, doorgaan?'.
• Eventueel kan je zeggen dat het binnen een half uur een melding is, en daarna een vraag.

Of te wel, laat de keuze bij de gebruikers en maak ze duidelijk dat goed afsluiten erg belangrijk is (leg ze bij een introductie eventueel een situatie voor (wel in taal die begrepen wordt)).

offtopic:
Het kan zijn dat iets wat hier op lijkt al verteld is.

[Verwijderd]

En dan heb ik een beetje een rare oplossing maar het werkt wel aardig. Ik sla alle 10 laatste versies van 1 persoon op en de laatste is zichtbaar voor edit. Nu kan de beheerder in 'de prullenbak' kijken en weer wat terug zetten etc. en uiteraard heb ik ook een timer die op een half uur staat zodat de meeste ergenis voorkomen wordt.

[B-Man]

Hebben jullie al eens naar Macromedia's Contribute gekeken? Zij lossen dit soort problemen erg handig op m.b.v. CVS: er kunnen dus meerdere versies tegelijkertijd bestaan, waarvan er natuurlijk maar een zichtbaar is.
Dit moet er -lijkt me- altijd inzitten. Stel je voor dat je per ongeluk een lap tekst verwijderd. Oeps. Toch handig als je dan terug kunt gaan.
Ook erg handig in het geval dat er meerdere gebruikers tegelijkertijd een document bewerken. Je kan dan
a) ze beiden op laten slaan, en een content admin laten beslissen welke van de twee on-line gaat ofzo...
b) de login met de meeste rechten melden dat er tevens wijzigingen doorgevoerd zijn door een ander, en de mogelijkheid bieden om ze te bekijken en eventueel te "mergen" met zijn eigen updates.

[djluc]

content admin laten beslissen welke van de twee on-line gaat ofzo...

Als je die een hebt natuurlijk.

Het ligt er natuurlijk maar net aan hoe de situatie is en wat de gebruiker wil. Misschien is het idee van MSn toch nog niet zo slecht. Zet gewoon neer dat je ff weg bent, wil iemand anders worden de wijzigingen opgeslagen en krijgt de ander het recht om te editten, wil de gebruiker zijn recht terug klikt hij ergens op, er verschijnt een melding bij diegene die nu bezig is. Ze vechten dan zelf wel uit wie nu de meeste macht heeft.

[ Voor 65% gewijzigd door djluc op 12-12-2002 15:30 ]

[Verwijderd]

djluc schreef op 12 December 2002 @ 15:28:
Het ligt er natuurlijk maar net aan hoe de situatie is en wat de gebruiker wil. Misschien is het idee van MSn toch nog niet zo slecht. Zet gewoon neer dat je ff weg bent.

Dat is een goede.
Hoe groot is de kans dat dat echt gebeurt, dat ze echt altijd hun status instellen?

Nooit? Bijna nooit?

[Verwijderd]

ik heb het gemaakt!
alsvolgend:
als een pagina ge-edit wordt (dus die pagina opgeroepen wordt) wordt een lock op die pagina gezet. als je m vervolgens opslaat wordt ie weer ge-unlocked. als je niet opslaat maar op de 'scherm sluiten & unlock' knop klikt dan unlocked ie ook. maar als je op 'x' of F4 klikt dan unlocked ie niet.
als vervolgens een andere user die pagina opvraagt krijgt ie de melding dat de pagina ge-locked is. hij kan dan kiezen om geforceerd te unlocken of om het scherm te sluiten en de pagina op een ander moment te editen. in die melding staan ook de gegevens (naam,email,telefoon) van de persoon die de pagina gelocked heeft. ze kunnen dus ook nog even contact opnemen.
de persoon die de pagina gelocked heeft kan altijd in die pagina ookal is ie nog gelocked.

[chris]

FF iets wat misschien wel belangrijk is maar waarvan ik niet zeker weet of je het hebt ingebouwd:

Stel, pietje en jan willen op exact hetzelfde moment editen.
Pietje doet de query: "SELECT locked FROM pages WHERE page_id='1'";
pietje krijgt de mededeling dat de pagina niet gelockt is.
Jantje start het script op hetzelfde tijdstip.
Hij krijgt ook de mededeling dat de pagina niet gelockt is.
Vervolgens doet pietje "UPDATE pages SET locked blablabla
en jantje ook.
ze denken nou allebei dat ze een geunlockte pagina hebben.....hoe los je dit op?
misschien moet je kijken of er een affected row is na de update?

Misschien lijkt dit allemaal overbodig, en het zal normaal gesproken ook waarschijnlijk niet gebeuren, maar toch......probeer altijd fool-proof code te schrijven...

[Verwijderd]

Verwijderd schreef op 10 december 2002 @ 23:59:
Nou zou je zeggen: sim-pel. gewoon een x-tra kolom die 1 is als ie geedit wordt en 0 als ie niet geedit wordt. Dat zou ook goed bij te houden zijn als er te detecteren was of de browser wordt gesloten, maar helaas is dit niet mogelijk. dus een andere oplossing.

Je kunt toch gewoon die extra kolom weer op 0 zetten dmv javascript:
<body ... onUnLoad="zetweeropnul();">
en in de functie 'zetweeropnul()' laat je een pagina op-puppen die die ene kolom weer op 0 zet...

[Verwijderd]

/dev/null schreef op 14 december 2002 @ 17:37:
FF iets wat misschien wel belangrijk is maar waarvan ik niet zeker weet of je het hebt ingebouwd:

Stel, pietje en jan willen op exact hetzelfde moment editen.
Pietje doet de query: "SELECT locked FROM pages WHERE page_id='1'";
pietje krijgt de mededeling dat de pagina niet gelockt is.
Jantje start het script op hetzelfde tijdstip.
Hij krijgt ook de mededeling dat de pagina niet gelockt is.
Vervolgens doet pietje "UPDATE pages SET locked blablabla
en jantje ook.
ze denken nou allebei dat ze een geunlockte pagina hebben.....hoe los je dit op?
misschien moet je kijken of er een affected row is na de update?

Misschien lijkt dit allemaal overbodig, en het zal normaal gesproken ook waarschijnlijk niet gebeuren, maar toch......probeer altijd fool-proof code te schrijven...

heb je helemaal gelijk in, maar mijn systeem zal alleen op kleine schaal gebruikt worden, dus die kans is errug klein... dus dat risico ben ik bereid te nemen.

[Verwijderd]

Verwijderd schreef op 14 December 2002 @ 18:06:
Je kunt toch gewoon die extra kolom weer op 0 zetten dmv javascript:
<body ... onUnLoad="zetweeropnul();">
en in de functie 'zetweeropnul()' laat je een pagina op-puppen die die ene kolom weer op 0 zet...

En wat als explorer of windows vastloopt?

[Goodielover]

Verwijderd schreef op 15 december 2002 @ 15:08:
[...]

En wat als explorer of windows vastloopt?

Ik zou er toch er voor pleiten om het toch maar in te bouwen zoals slindenau aangaf. Je kunt nooit alles verhinderen, maar het afsluiten van het scherm met het krijsje is wel iets anders dan een vastloper. Normaal gedrag moet je zoveel mogelijk ondersteunen.

[CyberJack]

kan je doen op de volgende manier:

mysql> LOCK TABLES trans READ, customer WRITE;
mysql> SELECT SUM(value) FROM trans WHERE customer_id=some_id;
mysql> UPDATE customer SET total_value=sum_from_previous_statement
-> WHERE customer_id=some_id;
mysql> UNLOCK TABLES;