Bonjour
Comme je ne suis pas encore très habitué, ni à php, ni à Xoops je souhaite savoir ce qu'est cette fonction "redirect_header" que tout le monde utilise.

C'est une fonction d'apache ou c'est un fonction, class de xoops?

Ce que je souhaite C savoir où elle se trouve et si je peux modifier ce truc.

Ce que je souhaiterais faire c'est une page qui gérerait les blocages au niveau de la base. pour être sûr de ne pas bloquer undéifiniment une page je souhaite utiliser la fonction de redirection disons au bout de 30 où 45 secondes et d'afficher ce décompte. Voilà pk je souhaite en savoir plus pour savoir si C possible ou non


Merci
Cdl
William

C'est une fonction de xoops. La fonction ce trouve dans include/functions.php

Le template car c surtout la que tu vas voir ce qui se passe reellement se trouve lui dans modules/system/system_redirect.html.
La ligne importante etant celle là

c'est une balise meta dans le head de la page html qui effectue un raffraichissement (http-equiv="Refresh") qui va se lancer dans le $time et qui va redirige vers l'adresse $url.


La dessus tu peux gerer le fait que la page reste a l'ecran 30 40 s ou se ce que tu veux en modifiant le temps
<meta http-equiv="Refresh" content="40; url=www.toto.fr" />

Merci
Maintenant je vais pouvoir creuser gentillement pour voir si je peux lui faire faire ce que je veux.

L'idée est que lorsque on ouvre en mode "edit" de bloquer le req mais surtout de pouvoir le libérer s'il n'y a pas de validation dans le temps imparti pour le reste des users. En fait, je voudrais faire un environnement multi user avec blocage des recs.

Bonne journée

Cdl
William

Si je comprends bien ce que tu veux faire, tu veux bloquer l'acces a une donnee lorsque un utilisateur est dessus, pour ne pas que les autres puisse la modifier etc...

Si c'est bien cela, la solution la plus simple n'est pas ici...
Techniquement le client/serveur et donc tout ce qui est web etc (car c'est du client serveur) ne peut pas gerer ce genre de truc facilement (Il me semble que J2EE le fait mais bon...) ou en tout cas pas de façon automatique. Le faire au niveau du client ne sert a rien (la page html pour nous) et c'est pas la bonne voie.
La solution la plus simple c'est de gerer cela de façon logique c-a-d a chaque fois que tu recuperes une ligne en table tu recuperes une donnee sous forme de sequenceur ou timestamp et quand tu veux mettre a jour cette ligne tu fais le where en fonction de cette donnee que tu mets à jours... si la donnee ne correspond pas c que quelqu'un a deja mis a jours donc avertissement a l'utilisateur...

Re
oui tu as partiellemant raison.
La difficulté n'est pas debloquer le rec ou de le laisser ouvert, de faire ou non apparaitre un message.

La difficulé, c'est de ne pas bloquer toute la base parce que les user ne pense pas à valider une fiche.

Imagine l'ouverture pour une modification d'une fiche et que le user ne valide jamais pour qq raison que ce soit....
connerie, coupure de courant, bref il ne valide jamais....
Ma solution est de dire qu'au bout de X seconde l'ouverture en mode modif, bloqué se ferme et rend le rec de nouveau dispo.

Cdl
William

Oui mais en client/serveur et donc en techno web par defaut tu n'as jamais de lock sur ta donnee.
C'est a dire que c par parce que j'ai une donnee X d'afficher sur ma page, que les autres utilisateurs ne pourront pas la voir, ni meme la modifier.
Donc tu ne peux pas avoir ton pb, de donnee bloquee pendant x temps suite a coupure de courant etc...

Re
Mais si lol avec un un controle de flag quitte à ajouter dans la base un bool de blocage ou un timer ou n'importe quoi qui sera controlé pour savoir si le rec est déjà en modif ou pas.


Si libre en base de donnée => ok acces et on met un flag dans la base
sinon
message refaire un essai dans une minute car pas libre

Cdl
William

Oui on est d'accord c ce que j'ai explique au dessus
Mais ca ne te bloque pas une donnee en base (ni la base d'ailleurs).
Ca s'appel un lock logique et ca verifie juste que entre ton flag que tu as et celui qui est sur la base, la donnee n'a pas ete modifie. Car si tu n'as pas la meme valeur de flag c que la donnee a ete modifie et dans ce cas message d'erreur etc... Mais ca n'empechera jamais quelqu'un de charger la page apres toi et de modifier la donnee avant toi.

Par contre si tu veux empecher que une autre personne accede a une donnee lorsque tu as deja quelqu'un dessus dans ce cas c pas exactement comme ca qu'il faut faire. Au moment de la lecture de la donnee tu verifie si un hcamp X est vide, tu le mets a jours avec une donnee, et tu charges cette donnee. Tant que cette donnee n'est pas revenue a null, personne ne peux la charger. Et la effectivement tu risque d'avoir unpb en cas de deco etc... de la personne qui l'a chargé en premier. Et la, la seule soluiton pour t'en tirer c'est de renseigner ce champ X par un timestamp ou date et de verifier lors d'un nouvel acces la difference de date avec la date actuel. Si y a plus de 15 min par exemple, on peut la reprendre sinon non. Mais il faut pas oublier de gerer le fait que le premier utilisateur peut revenir et remodifier...
C un peu plus complique... non?

Re
On est donc d'accord.
C pour cela que pour avoir plus de faclité et moins de code à taper je souaite regarder avec redirect_header ou tout du moins qqch qui s'en rapprochera.

ne pourrait on pas charger toute une page avec redirect_header-02 qui redigera la page si la page n'est pas fermée dans un délai imparti.

en partant du fait que la base soit adaptée

On demande l'accès au rec
si libre
On met un flag en base
on charge la page

Si la fiche est validé par action C bon et on libére la fiche

Si on ne valide pas la fiche
redirect_header-02 redirige et redonne l'accès au rec.

Voilà pk je cherchais à comprendre le fonctionnement de cette fonction.

il faudrait en faire un double, changer le template ou ne pas en utiliser du tout, je ne sais pas encore. Tu crois que nous pouvons arriver à qqch de ce genre?

Cdl
William

redirect_header te renvoi sur une page apres un temps que tu definis... ca c ok.
Par contre je sais pas si tu as remarque que de 1 ca fonctionne pas toujours cette fonction, mais ca c pas un pb serveur mais client. Et de 2 si le mec a une panne de courant ou reboot de son poste la page ne sera pas relance...

Donc pas a gerer sur le client ...