Reprise du message précédent :
ah merde. bon, ben merci.

il manque un  !very-important

Et un aussi un !not-so-important-but-could-be-usefull ?
 
   
 
==> [ ]

!more-important-than-nraynaud's-stuff pour le futur mainteneur

Because we know you want more z-index.

c'est un peu comme les mecs qui placent des objets à 10000px du bord de l'écran, ça doit être marrant dans les centres de conférence.

En PHP/JS/CeQu'IlFautPourQueCaMarche, je dois gérer des locks : un utilisateur identifié ouvre une page, personne d'autre ne dois accéder à cette page tant qu'elle est ouverte par cet utilisateur.
 
Je ne vois pas trop comment gérer ça précisement. L'ouverture du lien est facile à gérer et je peux stocker les infos dans une table pour savoir quelles pages sont ouvertes par quels utilisateurs, mais la fermeture est beaucoup plus problématique.
J'ai pensé à un JS qui chope l'event de fermeture de page, puis qui envoie une requête Ajax pour notifier mon appli mais il reste les cas du crash du browser, du pc, de la déconnexion utilisateur, et peut-être d'autres.

socket ? reactphp  + socket.io
 
tu auras un event côté serveur à la deconnexion

Heu c'est quoi le besoin exact en fait ?
Je trouve chelou ta demande, cela signifie que ton user doit faire des appels serveur qu'un autre utilisateur ne peut pas faire en même temps ?  
Essaye plutôt un système de jeton toutes les 5 secondes, c'est plus propre nan ?

En gros des users traitent des dossiers et lorsqu'un dossier est en cours de traitement il faut empêcher certaines actions et notifier les autres utilisateurs.

Ben tu mets un flags sur ce dossier en DB, et tout user qui essaye s'y accéder en même temps recevevra un petit message en ajax pour dire : nan tu peux pas pour le moment, un utilisatuer est en cours de blabla....

Et dans la page, tu mets aussi en place un système de jeton toutes les 5 secondes qui est envoyé en JS, et si le user n'envoie plus de jeton, il est déco.
Détecte aussi les mouvements de la souris ou autre, et si au bout de 5 minutes, aucune utilisation n'est faite dans la fenêtre, tu bloques la fenêtre et envoi un flag au serveur comme quoi la fenêtre est libérée et donc ta fenêtre n'envoie plus de jetons.

C'est foireux ton approche
Le gars peut bien ne pas bouger pendant plusieurs minutes et toujours bosser dessus, ou clôturer le dossier et dire a Josiane qu'elle peut y aller. Josiane ne supportera pas d'attendre x secondes

Le plus propre c'est websocket (ou tout autre connexion permanente équivalente)  avec un fallback vers du polling si les sockets ne sont pas supportees . donc reactphp si il veut du php

je sens que y'en a un qui va rigoler avec des belles machines à état et des vector clock.

j'ai écrit à l'arrache hein, mais spo faux, après pour websocket, il a quoi comme parc de machine à supporter ?

 
Un truc large

J'ai monté (et c'est en prod dans plusieurs hôpitaux) un dossier patient aux urgences en mode "c'est le dernier qui dit qui gagne", j'ai jamais eu aucun pb. Et les prospects qui voulait du verrouillage, une fois leur avoir exposé les emmerdes possibles, ça passait tout seul

Sachant que pour faire du verrouillage je partirais davantage sur une approche où tu stockes dans tes formulaires les valeurs initiales et tu compares ça avec les valeurs en base avant de mettre à jour.
On avait dû faire ça pour de la mise à jour de nested set qui n'aime pas du tout la concurrence en écriture. Du coup dans le form d'édition on remontait le timestamp de modif de l'arbre. Et à la mise à jour on vérifiait que c'était toujours le même.

trop facile, t'as un serveur avec une source de temps unique

Google ils foutent des GPS dans leurs datacenters pour la synchro du temps

c'est même plus compliqué que ça

À peine

hello les gens
 
bon, juste pour être clair : si je sanitize un input client (eg : un commentaire de blog, qui peut donc contenir du html, voir du html avec du JS pas catholique) en utilisant html.escape qui escape donc '&', '<''>', '", '\'', on est d'accord que si j'affiche ce texte "escapé" dans une page web je m'expose a rien de méchant ?
 

Oui.

Mais bon normalement c'est ta sortie (template) qui nettoie par défaut, et t'es surtout pas censé stocker does données altérées.

Si les utilisateurs sont "éducables" , un bouton "bloquer le dossier" qui permet à un utilisateur de "prendre" un dossier, et un bouton "libérer le dossier" pour quand il a fini, rien de plus simple. On a un système de ce type sur une de nos applis, et une fois le concept expliqué aux utilisateurs ya pas de problème.

Même si les mecs sont pas cons, suffit d'un seul qui oublie de délocker le truc avant de partir en vacances et c'est le bordel.

oui c'est bien ce que je compte faire :
- stockage du markup (j'utilise markdown/textile, etc...)
- lors de l'affichage, sanitization du contenu puis affichage. Par contre je comprends de ton message que c'est Jinja2 ou autre qui va le faire pour moi ?

Tu rajoutes une fonctionnalité de break-lock

Oui, faut juste activer l'extension autoescape: http://jinja.pocoo.org/docs/api/#autoescaping

/kick Josiane
You've been kicked by Jean Killian
 

 
Voilà. Et tu peux facilement coller des alertes ailleurs dans l'appli pour les mecs qui ont pas délocké un dossier depuis un temps douteux, ce genre de conneries...dans la pratique ça marche pas mal sur l'appli qui fait ça, ici, et ça coûte pas bien cher à mettre en place, sans websockets ou bordels de ce genre.

La solution d'une query envoyée en ajax toutes les X secondes à ReactPHP et react qui unlock le dossier si au bout de 3x il n'a pas eu de nouvelles, ça me semble pas mal moi

C'est toi qui vois si c'est une option faisable dans ton contexte...si oui c'est effectivement un bon moyen d'implémenter un truc relativement transparent pour tes utilisateurs.
 
Après il faut gérer les cas improbables mais pas impossibles, genre le mec qui perd la connexion alors qu'il est en train d'éditer un dossier mais qui la récupère avant de valider, ce genre de blagues...ce sera fatalement plus compliqué à implémenter qu'un lock/unlock explicite via des boutons dédiés.

Non mais t'as vraiment *besoin* du lock ?

 
On va fixer une réunion pour en discuter plus longuement
Actuellement c'est déjà en place mais ça ne fonctionne pas

Question JS : vous voyez des inconvénients à faire de la délégation d'event de click directement sur document ?
C'est pour faire du tracking de clic dans Google Analytics (aujourd'hui on a des onclick en dur dans le code...), à base de data-attributes.

Si c'est ce dont tu as besoin, non

J'ai vu ça mais j'ai pas trop compris les arguments : http://stackoverflow.com/a/9711252

Ça te concerne pas trop comme problème.
Dans la délégation typique de jQuery, le handler sur document va comparer ton élément avec tous les selecteurs "fils" sur lesquels ont été enregistrés des callbacks pour voir quels callbacks doivent être appelés.
Dans ton cas, si tu va directement chercher l'élement concerné via event.target/event.srcElement pour aller chercher les attributs, t'as pas de comparaison de selecteur à faire donc c'est super rapide.

Par contre, si l'élément avec le data-attribute est potentiellement un parent de l'élément clické, il faut remonter explicitement jusqu'à le trouver, avec le risque de remonter jusqu'au document sans en trouver, donc le click sur un élément non concerné sera un peu plus long à gérer. Je doute que ce soit très significatif cela dit, le temps dispo pour bosser après un click est assez large, vu que typiquement on est plutôt parti pour charger une page entière ensuite, contrairement à un événement de scroll par exemple où il faut garder le rendu fluide.

Si tu avais bindé directement un callback sur chaque élément tu aurais pu inclure l'élément dans la closure et éviter la remontée manuelle pour retrouver l'attribut, mais tu augmente l'usage mémoire si y'a pleins de callbacks à enregistrer, la délégation sur document me semble plus légère du coup.

Ceci dit, avec l'arrivée du shadow dom, je sais pas trop comment se passe le bubbling d'évènement, peut-être que tu pourras moins facilement tracker des clicks dans un web component, m'enfin c'est le futur lointain ça.

On est bien d'accord. Typiquement nous on va tracker des clics sur des liens (qui seront du texte ou des images). Vaut mieux partir sur :

ou ça (ou autre si vous avez mieux) :

 
Dans la solution 1, si je me goure pas, je risque de pas avoir le bon target, genre si j'ai un lien avec des span dedans et qu'on clique sur le span c'est lui qui sera dans la target alors que mes data-attributes seront sur le <a>. Vous me confirmez ? Auquel cas seul la solution 2 me semble fonctionnelle.

En effet à cause des span la solution 1 ne marchera pas comme tu le veux.

Y'a aussi une solution 3 de la forme:

$(document).on('click', function(event) {
  for (var el = event.target; el != document.documentElement; el = el.parentNode) {
    if ($(el).data('tracking-enabled')) {
        // le code de tracking GA
    }
  }
});

Savoir lequel est le mieux dépend de la profondeur du DOM pour la solution 3, et du nombre et de la complexité des autres handlers attachés à document pour la solution 2.
La solution 3 a l'avantage de ne pas nécessiter de classe en plus de l'attribut.
La remontée me semble aussi un bon mécanisme si ensuite tu veux exploiter les attributs pour choisir la catégorie de l'évènement analytics dans un élément DOM parent de celui qui est cliqué (genre Category:toolbar,Action:add-user).

Et ça aussi ça fonctionne aussi bien, puisque dans tous les cas : 1 seul event, et la détection de l'élément est entièrement géré par jQuery,
Donc utiliser ".track-me" ou utiliser "[data-tracking-enabled]" est exactement la même chose au niveau selecteur.

Ça a l'avantage d'être court et de ne pas avoir besoin de la classe en effet.

Par contre ça veut dire qu'il y a quand même le match à faire par jQuery pour vérifier que l'élément cliqué (ou un de ses parents) match bien le selecteur "[data-tracking-enabled]", ce qui veut dire un querySelector natif sur une plateforme récente, et l'implé en js de swizzle un peu plus lourde pour les autres (contrairement à ".track-me" où y'a un raccourci possible via getElementsByClassName).  de plus, le "ou un de ses parents" veut dire que la tartine d'appels à querySelector sera faite pour l'élément cliqué et chacun de ses parents, pour chaque handler attaché à document, ça commence à faire beaucoup.

(Donc en fait je m'étais planté au début, la profondeur du DOM impacte aussi le coût de la délégation, pas seulement de la remontée manuelle.)

Enfin, petit truc rigolo, le sélecteur "[data-tracking-enabled]" ne matche que les éléments qui ont le tracking écrit dans le HTML ou via el.attr('data-tracking-enabled', 'true'), mais pas ceux ajoutés via el.data('tracking-enabled', true), à cause de la distinction entre attribut et propriété.

Je suis arrivé à quelque chose de plutôt correct avec React, sauf que maintenant j'ai besoin de faire des traitements en bdd, et là je suis plutôt bloqué
 
J'ai cru comprendre qu'il fallait utiliser quelque chose du genre de ZeroMQ, mais je me demandais s'il n'y avait pas plus simple ?