Accès concurrent à une page php

Citation:

---

Envoyé par marcha

Cette solution a l'avantage d'être simple mais il y a un risque:

Si pour une raison de surcharge du réseau ou du serveur, la requête n'aboutit
pas, l'iframe se retrouve avec une page d'erreur et s'en est fini du refresh.

Si on veut vraiment éviter d'utiliser XmlHTTPRequest on pourrait toujours
utiliser la technique de l'iframe met en changeant sa source depuis la page
principale à intervalles réguliers. ex: (page.php?user=...&stamp=...)

---

C'est vrai ! je n'y avait pas pensé.
Toute solution à ces bonnes et ces mauvaises raisons d'être implémentées, ou non, le tout étant de les déterminer ; )

Soit dit en passant, n'utilisez vous pas, je m'adresse à tlm, un environnement de contribution distinct de l'environnement de prod ?
Qui par conséquent évacuerait ce défaut.

Citation:

---

Citation:
Et j'en viens donc à mon idée de la chose sur ces questions d'ajax et autre requêtes asynchrones.
Il y à qd même une solution technique multi navigateur, simple et efficace.. Une bête iframe avec meta refresh.
Et c'est cette iframe qui va signifier que l'utilisateur Y est entrain de modifier la ressource Z.
Je n'ai jamais expérimenté cette technique. J'ai cru lire que l'on obtenait pas le même résultat en fonction des navigateurs.
De plus, est-ce que cette technique ne provoque pas un effet visuel désagréable ? Ce qui risque d'être un peu lourd si le refresh est effectué régulièrement.

---

Hm, je pense que le tag iframe est correctement implémenté partout, et une iframe caché avec la tripotée d'attribut qui va bien ne sera pas visuellement intrusive.

a plus

Citation:

---

Envoyé par kaymak

Soit dit en passant, n'utilisez vous pas, je m'adresse à tlm, un environnement de contribution distinct de l'environnement de prod ?
Qui par conséquent évacuerait ce défaut.

---

Je comprend pas ta question :aie:

Citation:

---

Envoyé par deY!

Je comprend pas ta question :aie:

---

Hm un environnement de contrib est environnement dans lequels les utilisateurs type gestionnaire, viennent contribuer.
C'est un peu comme un environnement de dèv, sauf qu'ici c'est fait pour contribuer, cela permet au gestionnaire de modifier le contenu de l'application sans impacter immédiatement la prod.
Une fois qu'il à contribuer, vérifier, valider, il envoi tout en prod via un système de copie/publication.

Je posais la question par rapport à la remarque de marcha qui me semblait valable uniquement dans un environnement de production qui peut être amené à être surchargé, à contrario un environnement de contribution ne sera jamais surchargé puisqu'il est à accès restreint.
Et j'ai pensé, mais c'était peut être présomptueux, que la question de départ était pour un bo à accès restreint.

Citation:

---

Envoyé par kaymak

Je posais la question par rapport à la remarque de marcha qui me semblait valable uniquement dans un environnement de production qui peut être amené à être surchargé, à contrario un environnement de contribution ne sera jamais surchargé puisqu'il est à accès restreint.
Et j'ai pensé, mais c'était peut être présomptueux, que la question de départ était pour un bo à accès restreint.

---

Oui, en effet on ne sait pas les contraintes. C'est pour ça que mon point 2
commence par "Suivant la probabilité d'édition simultanée" :-)

Pour en dire un peu plus sur les contraintes, je désire développer de manière personnelle une application de gestion des exigences (donc lié à la gestion de projet) et ce sont ces fameuses exigences ainsi que les attributs liés à celles-ci qui ne doivent pas être accessible en même temps par plusieurs personnes.

Concernant l'environnement de travail, pour l'instant je travaille seulement en local mais l'application est destinée au Web. Dans l'idéal, le nombre d'utilisateurs pourrait donc être important.

Je réfléchis aussi à l'idée de travailler en équipe pour ce projet, si quelqu'un sur ce forum est intéressé il peut me contacter.