JeuWeb - Crée ton jeu par navigateur
Gestionnaire de feedback - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Gestionnaire de feedback (/showthread.php?tid=4005)

Pages : 1 2


Gestionnaire de feedback - rwk - 27-05-2009

Salut à tous,

Aujourd'hui, je me demande comment vous gérez vos feedbacks sur les jeux...
Parce que pour ma part, j'ai de gros soucis.

En général, j'utilise un système à 3 varibales dans l'url
- Succes=texte à afficher => Ca me sort un joli texte en VERT
- Alerte=texte à afficher => Le joueur a fait une action qu'il ne peut pas faire pour des raisons d'incapacités : joli texte en Orange
- Erreur=texte à afficher => ça se sont toutes les erreurs que je juge "tentative frauduleuse" genre modification de l'url avec des params qui ne correspondent pas aux valeurs attentues... ca me fait un joli texte en rouge.

Pour cela, j'utilise la fonction header();

Code PHP :
<?php 
header
("location:jouer.php?Succes=Vous avez attaqué machin qui perd Xpv et blablabla");
header("location:jouer.php?Alerte=Vous ne pouvez pas marcher sur cet élément du décor");
header("location:jouer.php?Erreur=Cette action est invalide");

Bon... Déjà, c'est pas super, car on se retrouve parfois avec des URL plus longues qu'un élastique de pyjama...
Ensuite, j'ai toujours un problème...

Je vous montre un exemple

Code PHP :
<?php 
//on vérifie que le joueur peut payer.
if($PJ->Pe_Caracs->Pe_Thor < $Prix)
{
header("location:boutique.php?boutique_id=1&a=entrer&Alerte=Vous n'avez pas assez d'argent pour acheter l'objet");
}

[
SUITE DU SCRIPT]

On s'attendrait à ce que si le joueur n'a pas assez de tune, on rentre dans cette condition et hop redirection...
Et bah non ! on va à la suite du script.
J'ai testé les 2 variables, aucune des deux n'est nulle, jusqu'à preuve du contraire -5 est bien plus petit que 5...

La fonction header appelée met fin au script, pas besoin d'un exit derrière... (et même en en foutant un derrière, la condition est parfaitement ignorée...

Du coup... j'ai du remplacé mon code par ça

Code PHP :
<?php 
if($PJ->Pe_Caracs->Pe_Thor < $Prix)
{
exit(
'Vous n\'avez pas assez de thor. <a href="jouer.php">retour</a>');
}

Remplacer les "headers" qui buguent par un exit.

Par contre...
Code PHP :
<?php 
//on vérifie la distance
if(!$Batiment->EtreAPortee($PJ->Pe_Caracs->Pe_PosX,$PJ->Pe_Caracs->Pe_PosY,$PJ->Pe_Caracs->Qu_Id))
header("location:jouer.php?Erreur=Ce batiment n'est pas à votre portée");

... Celle là n'est pas ignorée et est prise en compte normalement...

Bref. J'vous avouerais que je ne cherche pas à résoudre mon header...
Mais je cherche à gérer mon feedback plus simplement et aussi plus proprement.

En gros, dans mon code j'ai des :
- header => quand ça marche, j'ai ma jolie redirection sur une page avec son feedback
- des exit => bah ceux là, tu te retrouves avec un texte moisi sur une page au fond blanc

Comment gérez-vous vos feedbacks ?
Comment gérez-vous vos interruptions de scripts ?

J'aimerais en gros que quand un mec fait quelque que chose qui mérite que je lui crache du texte à l'écran, ça s'affiche dans une des nombreuses pages prévues pour ça.

Voilà pour mon soucis ^^


RE: Gestionnaire de feedback - Sephi-Chan - 27-05-2009

Dans CakePHP, les contrôleurs ont une méthode baptisée flash(string $message, string $url, integer $pause) qui génère (à la place du rendu habituel) une page qui contient un message. Ce message est un lien vers l'URL qu'on indique. On peut également spécifier une durée en secondes comme troisième argument, la page contiendra alors une redirection par meta vers l'URL demandée.

/* On utilise cette potion dans un contrôleur. */
$this->flash(
"Le message a bien été édité.",
"/posts/",
3
);

Dans Ruby on Rails, les contrôleurs proposent également méthode flash, qui cette fois utilise une session. La particularité de cet espace de session est qu'elle est vidée à chaque requête.
# Dans le contrôleur.
if @user.save
flash[:notice] = "Votre compte a bien été crée."
redirect_to @user
else
flash[:error] = "Une erreur est survenue."
render :action => "new"
end

# Dans la vue (dans mon cas, le layout).
- if flash[:error]
%p.message.error= flash[:error]

- if flash[:notice]
%p.message.notice= flash[:notice]

Si la procédure se passe bien, dans Ruby on Rails, on arrivera donc sur la page qui montre le profil de l'utilisateur crée (car Ruby on Rails préconise les architectures RESTful), on aura donc :
<p class="message notice">Votre compte a bien été crée.</p>

Si on actualise ou que l'on change de page, le message disparaît.

Désolé d'être moins complet sur l'exemple de CakePHP, mais j'ai un peu oublié. ^^


Sephi-Chan


RE: Gestionnaire de feedback - keke - 27-05-2009

Coucou,

Je n'ai pas la même notion de Feedback que toi :
http://fr.wikipedia.org/wiki/Feedback

J'ai donc un peu de mal à comprendre ce que tu indiques ^^. N'hésites pas à me remettre dans le droit chemin si je m'écartes du sujet.

>>>> J'ai testé les 2 variables, aucune des deux n'est nulle, jusqu'à preuve du contraire -5 est bien plus petit que 5...
Hum, il me semble que tu ai des soucis dans ta programmation. Se peut-il que le joueur ai -5 Thor en poche ? Ne pourrais-tu pas faire une fonction dans ta classe qui évalue l'argent de ton joueur ? Bon, tu ne demandes pas de solution ... alors je te donne juste des idées ^^

Pour en revenir à tes headers, je ne fonctionne pas du tout ainsi. J'utilise des formulaires (<forms>) qui me renvoie vers des fichiers .php dans lequel je traite toutes mes conditions.
L'usage que tu fais des header me semblent un peu trop permissif à la fraude...

kéké


RE: Gestionnaire de feedback - rwk - 27-05-2009

Avec des sessions, effectivement y a moyen...

Mais dans c'cas là, comment peut ton "terminer" le script et faire une redirection sans utiliser header...

genre
Code PHP :
<?php 
if($YaUneErreur)
{
$_SESSION['Erreur'] = 'Vous avez merdé';
//redirection=>comment ? exit ne le permet pas... et header et moi sommes en plein divorce
}

Citation :La rétroaction (on utilise aussi couramment le terme anglais feedback), est, au sens large, l’action en retour d’un effet sur le dispositif qui lui a donné naissance, et donc, ainsi, sur elle-même. C’est-à-dire que la valeur de sortie (à une date antérieure) fait partie des éléments de la commande du dispositif.

Bah ma notion du Feedback est la même... c'est une valeur de sortie à chacune de mes instructions qui méritent une sortie.

Pour ce qui est que le joueur peut avoir -5 thor...
Bah à partir du moment ou ma fonction header (que je pensais juste) n'a pas effectué la dose de contrôle qu'elle devait faire... les joueurs sont arrivés à acheter à perte...

Donc maintenant, je gère ça avec le exit...
Mais la condition de test y était... C'est bien l'exécution du header qui chie.

Donc c'est pas un soucis dans ma programmation... Ca serait presque vexant


RE: Gestionnaire de feedback - wild-D - 27-05-2009

faudra relire le manuel de header() ^^

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 Big Grin).

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)


RE: Gestionnaire de feedback - Holy - 27-05-2009

Un problème classique. Faut bien structurer ses pages pour pouvoir faire le tout gaiement ^^

Perso ma structure est toujours la même:
Code :
inclusion de fichier config et autre
- Si traitement à faire, je traite + gestion des erreurs éventuels
- Si le traitement est réussi, je peux rediriger sur une autre page éventuellement.
- Inclusion de l'header de ma page
- Corps de ma page
- Footer

Et en synthétique en PHP, ça me donne ça:
Code PHP :
<?php
require('./config.php');

// J'instancie plusieurs variables "génériques"
$erreur = ARRAY();
$titre = 'Modification du pseudo';

//=====================
// Traîtement POST-formulaire
//=====================
// Une simple condition pour savoir si un formulaire a été activé
if(isset($_POST['action'])) {
// Si un formulaire a été déclenché, je le traite ici, je commence directement par un "gestionnaire" d'erreurs
// (l'exemple qui suit est complètement factice)
if($x > 0) {
$erreur['x'] = 'C\'est pas bien t\'as fait une erreur!';
}
elseif(
$y >= 8) {
$erreur['y'] = 'J\'ai dit non!';
}

// Je vérifie qu'il n'y a pas eu d'erreurs pour aller plus loin dans le traitement du formulaire
if(count($erreur) == 0) {
// Je fais le traitement du formulaire ici, exemple rapide avec une requête SQL factice
$sql = "UPDATE player SET pseudo = 'LULINSUPERSTAR' WHERE idPlayer = '99999'";

if(
query($sql, __FILE__, __LINE__) === TRUE) {
// Fonction de redirection
succes('Votre pseudo a bien été changé', './exemple.html');
}
}
}
//=====================
// Fin traîtement POST-formulaire
//=====================

// inclusion de l'header
require('./header.php');

echo
'
<p class="title">Changement de pseudo</p>
<form action="" method="post">

<br />
<label for="pseudo">Nom du héros:</label>
<input type="text" id="pseudo" name="pseudo" size="15" maxlength="14" value="'
,$pseudo,'" />
'
,affiche_erreur($erreur['pseudo']),'<br />

<input type="submit" value="S\'engager" class="bouton" />
<input type="hidden" name="action" value="subscribe" />

</form>'
.n();

require(
"./footer.php");

?>

Comme ça il me suffit d'avoir un tableau "$erreur" dans ma gestion d'erreur. Et je les affiche au-dessus de mon formulaire (affiche_erreur()), sans aucune redirection en cas de "problème". J'ai même pas besoin de buffer du coup (qui peut être une bonne solution).


RE: Gestionnaire de feedback - rwk - 27-05-2009

Citation :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.

Citation :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" ?


RE: Gestionnaire de feedback - Holy - 27-05-2009

Bah c'est un peu comme tu veux.

Personnellement je gère les messages d'erreur au cas par cas. Mais donc oui, j'ai un tableau $erreur que je remplis en fonction des erreurs possibles. Donc si les conditions sont remplies pour qu'il y aie une erreur, j'instancie $erreur['quelquechose'].

Ce qui me permet très facilement de vérifier si il y a eu une erreur. Si je dois exécuter le script, il me suffit de faire count($erreur) == 0.

Après pour l'affichage, j'ai une fonction affiche_erreur qui me permet d'afficher le message de l'erreur qui est passé en paramètre (et qui ne l'affiche pas si la valeur passée en paramètre est vide).

Donc en gros et par exemple, si $x ne peut pas être plus grand que 10:
Code PHP :
<?php
if($x > 10) {
$erreur['x'] = 'Votre x est trop grand. Veuillez désigner un x de valeur maximale 10.';
}

if(
count($erreur) == 0) {
// Ici j'exécute le script vu qu'il n'y a eu aucune erreur
}


echo
affiche_erreur($erreur['x']); // N'affichera rien si pas d'erreur
// Ici mon formulaire

?>

Ca permet aussi d'afficher plusieurs erreurs en même temps, et d'ignorer les erreurs qui n'ont pas eu lieu (puisque $erreur['x'] serait vide).


RE: Gestionnaire de feedback - wild-D - 27-05-2009

ce que je propose de faire ce que fait holy, mais en plus compliquer Smile

on va prendre la cas basique pour expliquer le concept; vas surtout pas l'appliquer tel quel :

t'as un fichier central index.php
dans tes url tu utilise une variable action, qui défini en fait le fichier-action à "executer".
et hop tu execute cette action.



//include
include_once 'configuration.php';
include_once 'fonctions.php';

//input
$action = isset($_GET['action'])?$_GET['action']:'actionpardefaut';

//
include $action.'.php';

ça marche bien sur les lien de tes page suffit de faire des liens type index.php?action=UNEACTION et pour faire une redirection interne sur une autre action; ça peut ce faire;

tu force la définition des variables $_GET, tu lance l'action désirée, et tu exit pour pas continuer sur l'action initiale;

dans un fichier-action tu pourra avoir une redirection interne

....
//
if(xyz){//oups y a une erreur ou que sais-je

$_GET['action'] = 'UNEAUTREACTION';

include 'index.php';
exit;
}

//l'action normale si pas xyz
...

dans la pratique on fait rarement ça de manière aussi rusto-procédurale (mais on utilise de jolie classe pour faire joli), mais reste que le principe de base c'est juste ça.


RE: Gestionnaire de feedback - rwk - 27-05-2009

Oui, bah du coup, ça change pas beaucoup de ce que je fais pour gérer mes évènements.
Faut juste que j'arrête de passer le feedback en GET ^^