Gestionnaire de feedback

[rwk]

faudra relire le manuel de header() 34

sans vérifier, pour moi header() sert pas à envoyer quelque chose, mais à mettre dans le buffer d'en-tête http, ton élément d'en-tête (traduction, temps qu'il n'a pas été envoyé tu peux même rappeler header() pour écraser un appel fait précédement avec de nouveau paramètre, genre une redirection sur une toute autre page); de plus il ne stop pas l'exécution du script.
Je sais pas d'oû te viens cette idée (imagine si à chaque fois qu'on utilise cette fonction pour définir le charset fallait que le script s'arrête y aurait comme un sushi 1).

1) ce que tu as mis en header ne partira que lors du premier echo, ou toute autre sortie de contenu (flush()). Qui va forcer l'envoi de contenu et donc va envoyer en premier ton en-tête http.

2) et donc logique que pour arrêter l'execution du script; faut faire suivre ton header() d'un exit.

--
tu peux aussi utiliser une redirection javascript; mais franchement pas ce qu'il y a de plus élégant.(autant utiliser header())
--

le plus élégant, une redirection interne dans ton moteur de jeu. Faut pour ça que ton moteur de jeu supporte ce genre de "redirection". La plupart du temps si tu travailles en POO tu auras donc une classe de dispatching. Et tu vas donc réinitialiser celle-ci avec ta "redirection" plutot que l'URI "originale" envoyée par le client.(Si t'es en procédural, c'est aussi faisable a priori; mais faut adapter ton système en conséquence)

Ca m'avait paru logique au début aussi qu'il faille un exit, vu que header justement ne permet qu'à définir les entêtes...

Sauf que que j'ai pris surement la mauvaise habitude de ne pas mettre de exit; vu que header trainait en général en fin de script... Plus rien derrière.

Surement que dans ma tête, l'amalgame s'est fait : header n'a pas besoin d'exit.
J'viens de relire la doc... et effectivement, faut exit;

Mais bon, l'idée surtout était de voir comment chacun a son approche de la gestion du feedback.

Les forums utilisent le "action réussie, vous allez être redirigés dans X secondes". D'autres calent une page intermédiaire...
D'autres te laissent des pages blanches avec l'erreur et un gros "démerde toi".

@Holy, tu utilises un gros tableau $erreur dans lequel tu stockes toutes les erreurs possibles puis tu appelles celle que tu veux ? Ou alors, tu enregistres au fur et à mesure tes erreurs dans le tableau !?

genre dans ton fichier de config tu as un

$erreur['machin1'] = 'truc1';
$erreur['machin2'] = 'truc2';
$erreur['machin3'] = 'truc3';
$erreur['machin4'] = 'truc4';
$erreur['machin5'] = 'truc5';

et tu as une fonction affiche_erreur(numéro de l'erreur) ?

Autant j'y vois clairement un avantage pour de la gestion multilangue...
Ca s'rait pas con comme système ça non plus.

le plus élégant, une redirection interne dans ton moteur de jeu. Faut pour ça que ton moteur de jeu supporte ce genre de "redirection". La plupart du temps si tu travailles en POO tu auras donc une classe de dispatching. Et tu vas donc réinitialiser celle-ci avec ta "redirection" plutot que l'URI "originale" envoyée par le client.(Si t'es en procédural, c'est aussi faisable a priori; mais faut adapter ton système en conséquence)

J'ai carrément rien compris. Je sais pas si c'est du à ma digestion après le repas.
Tu appelles quoi "redirection interne" ?