Apprendre Ajax et bien choisir ses outils

[djidi]

Mais la ça vient plutôt d'un problème (oubli) de vérification côté serveur non ?

[Akira777]

Ah oui carrément.

Mais de part la structure de xajax, le fait d'enregistrer ses fonctions, pour le développeur débutant, ça pousse le type à se dire : "Ah, ces fonctions faut que je fasse attention à les proteger par is_admin(), ...".

Enfin c'est un peu capilotracté, mais en essayant de me mettre dans la tête du débutant, je me dit que xajax pousse à avoir se déclic. Bon d'accord, c'est minime mais je pense que c'est véridique. Faire de l'AJAX avec jQuery est beaucoup plus souple, on peut faire tout et n'importe quoi, si on est pas habitué à travailler de cette manière on se pose peut-être pas les bonnes questions quand on aborde l'asynchrone.

D'ailleurs, je le vois bien quand je donne mes cours. Certain se disent que l'AJAX c'est comme un simple GET sauf qu'on capture la page avec jQuery, chacun à son approche. Alors j'ai droit à dû :

- je charge une URL lambda de mon site, je récupéres les infos dont j'ai besoin avec un selecteur et je met à jour sur ma page actuelle.
- une URL correspond à une fonction, et j'ai du retour HTML et je remplace

Moi je vois surtout le truc en me disant, j'ai un modèle MVC solide, sans avoir à ré-écrire un seul bout de mon code, en étant bien dans le REST, c'est mon code qui détecte si je fais de l'AJAX (ou alors je lui envoi l'info en suffixant mon URL par /json, /xml, ...) et traite le format dont j'ai besoin sans aller jusqu'au chargement de la vue. Si j'ai besoin d'une div en particulier d'une page, je lui envoi une requete qui va faire que mon moteur va me renvoyer seulement la bonne div extraite de mon template. Faut que ce soit souple.

[Damocorp]

Je suis pas sur d'avoir tout compris.
Mais niveau php, je vérifie toujours tout. J'espère ne jamais avoir rien oublié, sachant très bien que la sécurité en dépend.
Je passe un temps fou à chercher les petites erreurs ou toute chose qui se pourrait d'être non fiable. Mon côté parano qui ressors.

[Sephi-Chan]

Oui, il faut le faire.

Un bon moyen pour ça est d'encapsuler toute la logique d'une interaction dans une classe dédiée à ça, puis d'isoler les différents cas et d'écrire un test automatisé pour ça.

Par exemple, pour Conquest on Rails, j'ai isolé l'action d'attaque d'un joueur sur un territoire dans la classe CharacterAttacksTerritory. J'ai d'abord écrit des tests unitaires pour décrire son comportement, puis au fur et à mesure, j'ai écrit l'implémentation (dès qu'un test passait, je l'affinais ou j'en écrivais un autre, qui me poussait à changer l'implémentation que je venais d'écrire). Comme tu peux le voir, les premiers tests servent à vérifier les cas limites (et l'implémentation est là).

[Damocorp]

Ha j'en suis pas encore la
Puis je code pas encore en ruby.

J'aime bien la clarté du code, qu'est ce qui fait cette clarté ? la POO ?

[Akira777]

Dans un premier temps, une bonne séparation du code. Le HTML avec le HTML, le CSS avec le CSS, le JS avec le JS, le PHP avec le PHP.
Du code bien indenté, des classes PHP cohérentes, du code réutilisable, des fonctions qui font une seule chose de manière simple et concise, des messages d'erreur pertinents, des variables qui ont du sens, entre autre.

[Maks]

Oui, il faut le faire.

Un bon moyen pour ça est d'encapsuler toute la logique d'une interaction dans une classe dédiée à ça, puis d'isoler les différents cas et d'écrire un test automatisé pour ça.

Par exemple, pour Conquest on Rails, j'ai isolé l'action d'attaque d'un joueur sur un territoire dans la classe CharacterAttacksTerritory. J'ai d'abord écrit des tests unitaires pour décrire son comportement, puis au fur et à mesure, j'ai écrit l'implémentation (dès qu'un test passait, je l'affinais ou j'en écrivais un autre, qui me poussait à changer l'implémentation que je venais d'écrire). Comme tu peux le voir, les premiers tests servent à vérifier les cas limites (et l'implémentation est là).

Quand tu disais l'autre fois que tu ne programmais plus de la même façon et que tu voulais faire un "reboot" de ton jeu, c'est parce que maintenant tu développes par les tests d'abord ?

[Sephi-Chan]

Ha j'en suis pas encore la
Puis je code pas encore en ruby.

J'aime bien la clarté du code, qu'est ce qui fait cette clarté ? la POO ?

Je ne peux pas te dire. Ça doit venir de la syntaxe de Ruby et du découpage du code.

Quand tu disais l'autre fois que tu ne programmais plus de la même façon et que tu voulais faire un "reboot" de ton jeu, c'est parce que maintenant tu développes par les tests d'abord ?

Pour la première version, j'écrivais des test a posteriori, en ce sens j'ai changé, mais c'est plutôt pour la partie API et client que je souhaitais recommencer. Et l'air de rien ça me permet d'essayer de nouvelles choses (par exemple, la stack de test utiliser Test::Unit plutôt que Rspec, et j'ai pu essayer les fixtures, bien que je sois revenu aux factories pour créer les données de test).

[Plume]

Les fixtures sont sympas. Et elles peuvent être générées par Rails. Le problème, c'est la maintenance des fixtures. Donc je suis d'accord avec l'utilisation des factories.

[Sephi-Chan]

Exacte. Pour mes cas d'utilisation, les fixtures se sont révélées impossible à maintenir.
Mais quand on peut s'en servir sainement (pour la plupart des applis bidons), autant en profiter pleinement, car ça trace !


PS : mais ça me fait penser qu'on dévie bien. xD