Discussion :

[Climoo]

Bonjour

Mon site propose d'éditer des articles (remplissage d'un textarea). Quand un utilisateur est en train d'éditer un article, personne ne doit pouvoir l'éditer au meme moment. C'est pourquoi, lorsque l'utilisateur entre sur la page d'édition, je passe un drapeau à 1 pour signaler que l'article est en édition. Lorsqu'il la quitte, ce meme drapeau repasse à 0, et ainsi d'autres personnes peuvent éditer l'article.

Mon problème est le suivant :
Si l'utilisateur quitte la page brutalement (fermeture du navigateur, panne de courant ?), je ne sais pas comment détecter cet événément. Autrement dit, dans ce cas, je ne peux pas remettre le drapeau à 0, et l'édition de l'article est bloquée pour toujours...

Quelle serait la possibilité pour gérer ce cas précis ??
Merci de votre aide, j'espère être parvenu à me faire comprendre...

[RunCodePhp]

Salut

Une coïncidence, peut être, mais dans un autre topic il était question justement de savoir quand un utilisateur quittais le site.
Pour ma part, je considère qu'il y a rien permettant de le savoir très précisément.
Bon, c'était une petite parenthèse.

Concernant ton problème, j'ai bien une idée. Donc à toi de voir.

A fonctionnalité particulière, traitements particuliers je dirais.
De plus, ne pas pouvoir éditer un article est une contrainte pour celui qui tente d'éditer l'article verrouillé, du coup, je me dis qu'il faudra aussi reporter une certaine contrainte à l'éditeur.

Donc mettre un drapeau sur l'article édité me semble aussi nécessaire, mais je verrais bien une date d'édition plutôt qu'un 0 ou 1.
Ensuite, une config (genre constante) qui définira le temps Max d'une édition (genre 5 minutes, 10 min., peu importe).
Donc au-delà de ce temps, tout article pourra être éditable.

Du coup, tout éditeur pourra déjà savoir si un article est éditable ou pas, de plus, si l'article est verrouillé, savoir à quelle moment il pourra être édité.

Tout tient sur la date d'édition et le temps Max d'édition.
Dès qu'un article est édité, la date d'édition est mise à jour.

Coté client, on pourra même imaginer toute sorte de trucs pour qu'un éditeur soit au courant quand prend fin le verrouillage de son article.

C'est la contrainte pour tout éditeur pour éviter de bloquer un article trop longtemps.
Et si un éditeur quitte prématurément un article, ou tout autre problème technique, un article pourra être édité au-delà du temps Max.

On pourrait tout de même imaginer qu'un éditeur puisse reconduire ce temps Max si par exemple il arrive à la dernière minutes et qu'il n'a pas fini (via un Ajax).


En somme, c'est assez proche du fonctionnement des sessions.
C'est une idée.

[Climoo]

Je te remercie beaucoup pour ta réponse (rapide en plus) RunCodePhp.
J'avais pensé à pas mal de choses, mais pas à ça, et je trouve que c'est une excellente idée. Elle me permet, dans tous les cas, d'être qu'un article ne sera jamais bloqué éternellement.

Seulement, dans mon cas, je pense la coupler avec autre chose.
En effet, j'ai un problème pour un cas assez normal. La personne édite l'article, puis, plutot que de cliquer sur "enregistrer" ou "annuler", elle clique sur un autre lien de la page, ou alors, entre une autre adresse, et donc quitte la page, sans pour autant enlever le verrou. Il serait peut être dommage de devoir attendre un certains temps, alors que d'autres personnes pourraient éditer l'article.

Je connais l'évenement "onunload" en Javascript.
J'avais pensé alors, lorsque cet événement ce déclenche, executer une requête en Ajax, pour enlever le verrou dans la base de données.
Le problème est que, sur cette page, il peut cliquer sur un lien qui permet encore d'éditer l'article, mais d'une autre manière (je vous passe les détails). En d'autres termes, s'il quitte la page, je veux enlever le verrou, sauf dans certains cas, ou je veux laisser ce verrou.
J'ai donc besoin de connaître la page sur laquelle l'utilisateur se dirige, à priori, lorsque j'effectue l'appel Ajax.
Mais je ne sais pas si c'est une information que je peux connaître, et si oui, comment.
Ai-je vu les choses d'une bonne manière, ou bien exiterait-il d'autres solutions pour réaliser cela ?

[RunCodePhp]

Effectivement, déverrouiller un article si un éditeur quitte un article peu être nécessaire, pour éviter de trop bloquer d'article.

A coté de ça, ma réaction était que, si on a besoin une telle fonctionnalité, c'est qu'en 1er les éditeurs doivent être parfaitement au courant, et être surtout d'accord sur le principe, sinon, le codeur/Webmaster risque de provoquer une manif
J'imagine bien la scène suivante :
"Qui c'est se co* qui qui me bloque mon article"
En faite, dans ce fonctionnement je vois inévitablement une certaine responsabilité de la part des éditeurs, car de toute manière, un article volontairement édité bloque tous les autres qui souhaitent éditer le même article.
Pour moi, un éditeur se doit de ne pas faire du n'importe quoi.
Enfin, c'est ce que je me dis.


A coté de ça, on peu prendre les choses un peu différemment, comme ne pas automatiquement verrouiller un article quand un article est édité, mais de donner à un éditeur la possibilité de le verrouiller lui même.
En somme, un article édité serait considéré comme "consulté" par défaut (donc toujours éditable), et un bouton "verrouille/déverrouillé" serait présent dans l'édition.
Ceci par Ajax par exemple, et en prenant toujours le même principe sur les dates, vu que ce principe à l'air de te convenir.
Ca peu s'étoffer en proposant plusieurs durée sur le temps Max (le Max serait toujours celui défini dans la constante).

On reporte toute la responsabilité du verrouillage sur les éditeurs.


Mise à par ça, et si le "verrouillage/déverrouillage" manuel n'est pas possible, je ne vois pas trop.
L'évènement "onunload" je le connais de nom (j'ai jamais rien fait la dessus), du coup, je ne sais pas s'il y a moyen de l'exploiter.
Par contre, le peu que j'en ai lu, son comportement serait assez différent selon les les navigateurs. Attention donc.

Sinon, peut être faudrait il empêcher de quitter un article sans l'avoir déverrouillé. En gros, surveiller les évènement JS, et n'autoriser que le submit du formulaire de l'article ou le déverrouillage.

Utilise tu un FrameWork JS ?
Ca peu aider ici, car en jQuery, il me semble que ça ne devrait pas être si compliqué à refuser tout évènement click sur des liens (par exemple), et surveiller tout évènement "submit".
En gros, un éditeur click sur un lien (peu importe lequel), et on lancerait une alerte du genre : "Veuillez déverrouiller l'article ou le valider. Merci "


Ca se complique un peu ton truc.


Par pure curiosité, dans quel cadre ça se passe ? (si c'est pas indiscret)
Un éditorial ? journal, presse, blog ...

[Climoo]

Encore merci !
Hé bien il s'agit en fait d'une plateforme de capitalisation de connaissances. Les gens qui y ont accès ont été inscrits, et travaillent en collaboration, et ont accès à un nombre restreint de concepts (selon leur organisation), sur lesquels ils écrivent des articles.
Les articles sont en fait des pages wikis.
On peut donc supposer que ce ne sont pas des personnes qui veulent couler la plateforme qui l'utilisent. En revanche, ils peuvent être maladroits.

A propos de l'événement onunload, j'ai cherché, et je ne trouve rien qui permette de savoir la page sur laquelle il se dirige. Quand on y pense, c'est peut être impossible à faire. Car imaginons dans le contraire, je pourrais pister les gens comme je veux et pourquoi pas, enregistrer les sites qu'ils visitent et faires mes petites statistiques dessus (enfin ça me parait pas très réglo de pouvoir avoir accès à cette information).

JQuery est effectivement installé sur la plateforme.
Ton idée est très intéressante. Je crois que je vais y réfléchir...
Je reviendrai surement plus tard pour dire ou j'en suis....

[Climoo]

Je viens d'avoir une idée, peut être bonne.
En fait, sur ma page, il y a plusieurs boutons qui permettent d'enregistrer/annuler l'article et autres.
Quand je click sur un de ses boutons (événément onclick), je vais positionner une variable (à priori globale) de Javascript à 1.
Lorsque l'événement onunload est appelé, je vais vérifier
la valeur de cette variable.
Si elle vaut 0, alors la personne essaie d'accéder à une autre page que je ne veux pas.
Si elle vaut 1, alors la personne peut continuer à naviguer.

Est ce que cela vous (te ?) semble réalisable ? Correct, propre ?

[RunCodePhp]

J'ai fais un petit essai vite fait en pure JS (sans jQuery), et dans FF, apparemment cet évènement onunload serait déclenché sur tout évènement click (lien, bouton).

Du coup, oui, l'idée me semble bonne.
Mais que compte tu faire suite à un click sur un lien.
Lancer un Ajax qui déverrouille l'article ? (qui modifierait la date en faite).
Ou alors faire un tout un shmilblik : Rendre inactif le click (on ne suit pas le lien) ?


Ce qui me dérange un peu, c'est que tout est coté client, du coup, il y aura toujours un risque potentiel.
Un simple "ouvrir le lien dans un autre onglet" par exemple. (s'ils font ça souvent, c'est un peu la merd* d'ailleurs)
Il y aurait il pas moyen d'avoir une variable de session (genre article_verrou), qui par défaut vaut false.
Dès qu'un éditeur édite un article, on y stock l'ID de l'article.
- Si l'éditeur valide le formulaire, on la remet à false, sans plus.
- Si cette session vaut quelque chose est que la page est autre que la page d'édition, alors c'est qu'il se balade ailleurs, faut déverrouiller l'article.
- Ou alors, cette session vaut quelque chose, il se trouve dans la page d'édition, mais d'un autre article, alors faut déverrouiller le précèdent article.
Le test devra ce faire tout le temps, toutes pages confondues normalement.


Ceci peu paraitre lourd, mais si on la cumule avec ta dernière solution (onunload), théoriquement le cas devrait être rare, très rare même.
Donc ça s'arrête à faire 1 seul test, qui retournera false dans quasi tous les cas.
Enfin, c'est une autre idée.

[Climoo]

Effectivement, quand je clique sur un autre lien, et que l'événement "onunload" apparait, je comptais déverouiller l'article via Ajax (s'il va sur une autre page qui n'est pas pour l'édition). Peut etre ajouter un confirm() avant aussi, pour le prévenir.

Et oui, c'est une solution un peu plus risquée. Si l'utilisateur trouve la moyen de faire passer cette variable à 1 sans cliquer sur le bouton (et ca doit pas etre très difficile).
Cependant, que se passe-t-il s'il essaie de tricher ? Il va conserver le verrou pendant un certain temps, jusqu'à ce que, au bout d'un moment, le timeout (ta première solution), vienne soulever ce verrou. Comme les gens qui vont sur le site ne seront pas méchants, cela ne me dérange pas.

Si la personne fait "ouvrir dans un nouvel onglet", l'événement onunload nee devrait pas se déclencher. Mais comme il a toujours la page dans son navigateur, il continue d'éditer l'article, donc il conserve le verrou, et ça ne pose pas de problème à priori.

Ta dernière solution me plait moins. Il y a quelques inconvénients, en dehors du fait que c'est un peu lourd (et encore...). Par exemple, la personne ne peut pas éditer plusieurs articles simultanément. S'il a deux pages, qu'il édite un article dans l'une, écrit un peu dedans, puis édite un article dans l'autre page, puis essaie d'enregistrer la première, il va y avoir un problème.
Aussi, s'il tape une autre adresse de site dans la barre de navigation, il reviendra pas sur mon site, donc ma variable de session ne pourra pas changer.

Je me demande juste si l'événement onclick est bien pris en compte AVANT l'événement unload. Logiquement oui, mais si ce n'est pas le cas, ma solution ne fonctionnera pas...

Quoi qu'il en soit, un grand grand merci pour ton aide et tes suggestions !

[RunCodePhp]

Je me demande juste si l'événement onclick est bien pris en compte AVANT l'événement unload. Logiquement oui, mais si ce n'est pas le cas, ma solution ne fonctionnera pas...

En faisant d'autres (petits) essais, les onclick sont effectués avant.
Donc le onunload serait fait en dernier.
A savoir que dans mes essais, le onunlod est dans le <body>.

Puis ça à l'air de fonctionner pareil dans les 4 navigateurs que j'ai sous le coude : FireFox, Chrome, IE8 et Opera.
J'avais peut être des apriori.

Une petite remarque quand même, c'est qu'apparemment, seul Opera ne déclenche rien (pas de onuload) si je ferme le navigateur.


Pour ma suggestions des sessions, effectivement, ça à l'air de rajouter plus de problèmes que ça en résouts.


Mise à par ça, ça devrait aller je pense.

Pour le confirme(), j'ai un doute.
Par contre, le confirm() c'est pour proposer une alternative, genre : Oui, je quitte l'édition en le déverrouillant, Non je quitte sans le déverrouiller.
Donc dans tous les cas il quitte l'édition (pour suivre le lien).
Ca sous entend aussi qu'un éditeur pourra verrouiller ainsi plusieurs articles (vu que tu as précisé qu'il y a des liens vers d'autres articles).
Par contre, s'il fait cela, et qu'il fait "page précédente" (navigateur), il ne devrait pas pouvoir rééditer le précédent article, car il aura été verrouillé.
Pour pouvoir éditer plusieurs articles, faut que les éditeurs ouvrent le lien dans une autre fenêtre ou onglets.
Du coup, le confirm() ne servirait pas vraiment. Peut être juste un alerte.
Mais il y a peut être un détail qui m'a échappé.

[louperivois]

Proposition : à toutes les 5 secondes, un événement ajax vient mettre la date actuelle dans la base de données. Un autre utilisateur qui essaie de modifier la page ne peut le faire que s'il le fait 6-7 secondes après cette date. Pas de onunload imprévisible, et le tout de manière transparente.

Si l'utilisateur clique sur un lien pour modifier la page autrement, cette page doit aussi comporter l'événement ajax, bien entendu. Il n'y a alors pas de déverrouillage entre les deux pages dans la mesure où le changement prend moins de 6-7 secondes, ce qui est acquis.

Si l'utilisateur sort par un lien autre, la page est de nouveau modifiable après 6-7 secondes.

Si il annule ou modifie, la protection peut être enlevée avec PHP en reculant la date de, par exemple, 10 secondes.

[Climoo]

Concernant le confirm(), je crois que j'ai été imprécis !
En fait, je pensais plutot à "Etes vous sur de vouloir annuler l'édition de l'article ?". Oui -> il reste sur la page (comme s'il n'avait pas cliqué), Non -> il quitte la page et le verrou est enlevé via Ajax. A moins que ce ne soit pas possible de faire un confirm comme ça... Ou peut être est-ce l'événement "onbeforeunload" ??

L'utilisateur peut éditer plusieurs articles, mais pas dans le même onglet. Avec ma solution, si on clique sur "page précédente", le dévérouillage doit aussi s'effectuer.

La proposition de louperivois me semble intéressante également. Ca marcherait bien je pense. C'est peut être juste un petit peu lourd d'effectuer des requêtes toutes les X secondes. Mais ça me semble une bonne idée.

[Kohntark]

Salut,

J'allai proposer la même chose que Louperivois.
C'est à mon avis la solution la plus simple et la plus fiable, que l'on peut bien évidemment doubler d'un temps d'édition maxi qui libérerait les verrous.

Certaines approches proposées plus haut me semblent lourdes et contraignantes (blocage des liens, ...) : l'utilisateur doit pouvoir faire ce qu'il veut et de façon simple (ne pas imposer un click sur un bouton pour quitter, ...) !!
Le tout est de l'avertir si, par exemple, il clique maladroitement sur un lien qui lui ferait perdre ton son travail d'édition. Pour cela le "onunload" / "confirm" peuvent servir.

je sens que la bagarre va reprendre avec RunCodePhp
http://www.developpez.net/forums/d92...onnexion-user/


Cordialement,


Kohntark-

[Bebel]

Bonjour,

le principe de mettre un flag a jour avec un champ date et un temps limite de blocage, me semble une tres bonne idée.

Le fait de mettre à jour également est une chose nécessaire, par contre toute les 5 secondes, cela me semble beaucoup.

Personnellement j'ajouterais également l'id de l'utilisateur entrain d'éditer l'article.

Par exemple, je suis entrain d'éditer un article, mon éditeur plante, si le systeme ne sait pas que c'est moi, je vais devoir attendre la lever du verrou pour reprendre mon travail.

Si l'id est sauvegardé, je peux reprendre celui-ci tout en bloquant les autres personnes.

[Climoo]

Effectivement, je pense comme toi Rebel qu'il faut ajouter l'identifiant de l'utilisateur. Je ne l'avais pas signalé, mais c'est ce que je comptais faire en fait.

Donc si j'ai bien compris, vous me conseillez plutot de faire un boucle qui va mettre systématiquement à jour la BD via AJAX, plutot que d'utiliser l'événément onunload. Quel est l'avantage de cette solution par rapport à l'autre ?

[Bebel]

personnellement, j'en vois plusieurs a utiliser un requete ajax.

- je fais moyennement confiance a l'événement onunload
- une requete ajax permet de garder la session ouverte, vu que l'édition d'article peut prendre du temps et donc l'utilisateur peut perdre la session

[RunCodePhp]

je sens que la bagarre va reprendre avec RunCodePhp

Comment t'as deviné ?
Non, pas de duel sur ce coup là.
Même si ça me tente bien ... je peux en trouver
Je déconne.


Si j'ai bien compris, l'Ajax va à chaque fois repousser (de quelques secondes) le déverrouillage.
Ou dit autrement, on verrouille de quelques secondes seulement à chaque fois.
Du coup, faut que l'éditeur quitte l'article pour qu'il puisse être édité à nouveau (à quelque secondes près).

Il y a un petit "mais" quand même.
Si l'éditeur s'endort sur son article (grosse fatique), ça risque fort de bloquer cet article très longtemps, jusqu'à ce qu'il se réveil (théoriquement).
Ne faudrait il pas un garde fou, un temps Max qui rendra inactif l'Ajax ?

... qu'il faut ajouter l'identifiant de l'utilisateur. Je ne l'avais pas signalé, mais c'est ce que je comptais faire en fait.

Il serait mieux à mon sens de se reposer sur les sessions, question de sécurité, non ?
Il faudrait théoriquement vérifier que cette personne soit là (session), et quelle a les droits de verrouiller un article.

Le problème que ça provoque si on fait ainsi (un session_start() en faite) dans le code Php de l'Ajax, ça va reconduire la session de l'utilisateur.
Du coup (si on ne fait rien de spécial), et si il n'y a pas de garde fou (celui évoqué plus haut), un article pourra être bloqué à l'infini, tant que l'utilisateur ne quitte pas l'article ou le site.
Je ne sais pas si vous voyez le truc ?

[Bebel]

Il serait mieux à mon sens de se reposer sur les sessions, question de sécurité, non ?
Il faudrait théoriquement vérifier que cette personne soit là (session), et quelle a les droits de verrouiller un article.

Si tu perds la session, pour changement de navigateur par exemple, l'article sera vérrouillé pour personne.

Le problème que ça provoque si on fait ainsi (un session_start() en faite) dans le code Php de l'Ajax, ça va reconduire la session de l'utilisateur.
Du coup (si on ne fait rien de spécial), et si il n'y a pas de garde fou (celui évoqué plus haut), un article pourra être bloqué à l'infini, tant que l'utilisateur ne quitte pas l'article ou le site.
Je ne sais pas si vous voyez le truc ?

Pour contourner ce problème, tu peux soit mettre un nombre limité de répétition pour l'execution de l'ajax.
Ou utiliser deux marqueurs, un pour le début d'activité et un pour la dernière activité. Et limiter sur les deux. Par exemple

Si date début + 1h < maintenant on dévérouille (ou on envoie un message à l'utilisateur qui sera par exemple repris par l'ajax, pour laisser l'opportunité à celui d'éditer de garder la main.

Si date dernière activité + 5 min < maintenant on dévérouille directement.

[RunCodePhp]

Si tu perds la session, pour changement de navigateur par exemple, l'article sera vérrouillé pour personne.

Pourquoi évoquer ceci ? car même si on va jusqu'à la perte de session, il faudra attendre très longtemps avant quelle expire.
Par défaut elle vaut 24 minutes.
Donc si l'éditeur s'endort devant l'article, au minimum il faudra attendre 24 min.
C'est quand même pas un détail, car c'est le genre de truc qui risque d'être très fréquent.
Enfin, pas que les gars s'endorment, mais qu'ils éditent un article, et puis s'en vont un (bon) moment faire autre chose.
Pendant ce temps là, tout le monde attend

(ceci hormis le problème sur la reconduite de la session).


Donc dans tous les cas, un garde fou serait utile.
Enfin, c'est mon avis


Ceci dit, faudrait peut être le faire, et voir à l'usage, et avoir un retour des éditeurs.

[Bebel]

Pourquoi évoquer ceci ? car même si on va jusqu'à la perte de session, il faudra attendre très longtemps avant quelle expire.
Par défaut elle vaut 24 minutes.
Donc si l'éditeur s'endort devant l'article, au minimum il faudra attendre 24 min.
C'est quand même pas un détail, car c'est le genre de truc qui risque d'être très fréquent.

En fait, je parlais de ca sur le fait que tu préférais passer par la session plutot que par l'id en bd, enfin c'est ce qu'il me semblait avoir compris, mais maintenant je suis plus sur.

Apres c'est sur un garde fou, c'est plus sur. Mais pour avoir un bon paramètrage au niveau du temps, cela risque de prendre un peu de temps pour calibrer le tout et trouver le bon timing.

[RunCodePhp]

En fait, je parlais de ca sur le fait que tu préférais passer par la session plutot que par l'id en bd, enfin c'est ce qu'il me semblait avoir compris, mais maintenant je suis plus sur.

Hé hé, ça ressemble à un dialogue de sourd (sans arrière pensée)
Non, je n'ai aucune préférence, et j'avais juste soulevé ce problème de blocage permanent lié à Ajax cas d'inactivité sur l'édition d'un article.


Mise à part ça, pourquoi pas.
Au principal intéressé de voir si cette solution lui convient.