15-12-2015, 10:50 AM
Par exemple:
Coté serveur
Et on surcouchise:
En pratique, je ferai 1 classe par contenu "if", implémentant toute la même interface (IOutputable par exemple) et j'instancierai la bonne classe en fonction des paramètres de la requête (surement dans une factory), pour utiliser l'instance à la fin du code PHP.
Et coté client, du JS qui masque le bouton (dans un .js séparé):
Si un block de code est "trop complexe à gérer", tu peux alors utiliser des libs qui le facilite (typiquement jQuery, mais faut en avoir besoin, faut pas se ruer dessus juste parce que le nom commence par jMachin).
L'avantage est d'avoir alors un site plus sécurisé (puisque t'as codé les checks PHP ou autre langage d'abord, et mis la couche client JS après; même si ce n'est pas forcément suffisant), modulaire (si chaque "couche" a été codée sans exploser les précédentes) donc interchangeable et évolutif (si une couche est rendue obsolète par une nouvelle norme, genre CSS3 qui a rendu pas mal de JS de présentation inutile, il suffira de supprimer cette couche, sans se traîner de bouts de code mort).
<form action="sorts/jeter" method="POST" class="jeter-sort">
<input type="hidden" name="token" value="..."/> <!-- CSRF mais à voir après -->
<select name="sort" required="required" class="choix-sort">
<option value="geler">Geler</option>
<option value="noyer">Noyer</option>
</select>
<input type="submit" value="Jeter le sort!" class="envoyer-sort"/>
</form>
Coté serveur
<?
// Check CSRF
// Check si le joueur peut lancer le sort
// Lancer le sort
// Renvoyer le résultat
?>
<html>
...
</html>
Et on surcouchise:
<?
// Check CSRF
// Check si le joueur peut lancer le sort
// Lancer le sort
// Renvoyer le résultat
if (responseJson) { // On me demande une réponse JSON
header('application/javascript'); // Pas sûr de celui-là
echo "{ success: true, duration: 100 };";
// Ou false, suivant si le sort a été lancé, et d'autres data si besoin
// Duration = temps d'attente avant le prochain sort
return;
}
if (responseHtml) { // Réponse HTML directe
echo "<html>...</html>";
}
if (postRedirectGet) { // Post Redirect Get
header('Localtion: ...');
}
?>
En pratique, je ferai 1 classe par contenu "if", implémentant toute la même interface (IOutputable par exemple) et j'instancierai la bonne classe en fonction des paramètres de la requête (surement dans une factory), pour utiliser l'instance à la fin du code PHP.
Et coté client, du JS qui masque le bouton (dans un .js séparé):
document.querySelector('.jeter-sort').addEventListener('submit', function () {
var callback = function (data) {
document.querySelector('.envoyer-sort').setAttribute('disabled', 'disabled'); // Grisé, on peut aussi le faire sur le select suivant ce qu'on veut
setTimeout(data.duration, function () {
document.querySelector('.envoyer-sort').removeAttribute('disabled'); // dégrisé
}); // Je ne suis jamais sûr de l'ordre des paramètres
};
// Gérer soi-même l'envoie et la réception du formulaire via XHttpRequest natif
// sinon y'a du jQuery qui le fait (j'aime mieux le natif, ça évite les codes "rétro" qui trainent)
});
Si un block de code est "trop complexe à gérer", tu peux alors utiliser des libs qui le facilite (typiquement jQuery, mais faut en avoir besoin, faut pas se ruer dessus juste parce que le nom commence par jMachin).
L'avantage est d'avoir alors un site plus sécurisé (puisque t'as codé les checks PHP ou autre langage d'abord, et mis la couche client JS après; même si ce n'est pas forcément suffisant), modulaire (si chaque "couche" a été codée sans exploser les précédentes) donc interchangeable et évolutif (si une couche est rendue obsolète par une nouvelle norme, genre CSS3 qui a rendu pas mal de JS de présentation inutile, il suffira de supprimer cette couche, sans se traîner de bouts de code mort).
)