[Split] Créer des briques pour les jeux

[pascal]

Au lieu de faire des briques on écrirait des tutoriels ?

[Sephi-Chan]

Ouais !


Sephi-Chan

[pascal]

Ouais !


Sephi-Chan

vite, les chapitres 2 & 3 !

[atra27]

Hm… C'est goret comme code… Mais comme je ne suis pas que méchant, je vais expliquer ce qui ne va pas.

Déjà, tu n'es pas homogène : parfois tu mets des espaces, parfois non, tu sautes des lignes là où t'en as envie, etc.

$data = $db->fetch('SELECT id, pseudo, password, block FROM `'.$config['db_prefix'].'user` WHERE pseudo=\''.$_POST['pseudo'].'\'');

Déjà ça commence mal : la requête est illisible avec les points, les slash, etc. Ensuite, tu utilises un paramètre sans la protéger. Risque d'injection SQL.

Extrait de mes logs:

Connexion refusée pour mauvais mot de passe (Pseudo: ' OR 1=1 /*/ Mot de passe:dsqds)

Tout ça pour dire que les sécurités sont inclues dans la lib...
Un exemple qui prouve qu'on doit étudier les libs utilisées AVANT de pouvoir discuter sur/reprendre un code (+1 pour l'idée de l'utilisation du php natif? ^^)

Ensuite pour l'indentation, je reconnais que c'est pas super super clair... mas c'est destiné a mon usage a l'origine... je peut réindenter avant de distribuer...

Au lieu de faire des briques on écrirait des tutoriels ?

Hum, j'ai cité un exemple plus haut qui est un tuto... sauf que y a du code illustrant le tuto... donc sa règle pas la question de comment faire le code :p


Bref, pour les partisans du "avec framework", ok très bien, lequel? (la avec cette question c'est bon je fini de diviser les pro-framework, vive les anti-framework! :p)

[Sephi-Chan]

Tu n'as aucune rigueur quand tu codes pour toi ? Je souligne simplement qu'il faudra vraiment soigner le travail pour que le lecteur ai envie de soigner son code, à son tour.

Comme tu l'as justement signalé, je suis allé lire la documentation de la librairie. Ça a été vite fait tant c'est maigre (et pas à jour). Je doute qu'il soit pertinent de se baser là dessus alors que PHP prône PDO, une solution standard, robuste et très bien documentée.

Bref, pour les partisans du "avec framework", ok très bien, lequel? (la avec cette question c'est bon je fini de diviser les pro-framework, vive les anti-framework! :p)

La majorité des anti-frameworks n'en sont pas vraiment ; c'est plus souvent de la méconnaissance et/ou de l'ignorance, contrairement à la majorité des pro-frameworks qui ont déjà travaillé sans.

Tu peux tout à fait essayer de faire des articles avec du code quick & dirty, mais c'est pas vraiment de la vision à long et moyen terme. Les lecteurs débutants risquent de prendre ça pour argent comptant et continuer de développer comme ça. Alors qu'en se basant sur un framework assez simple et léger (comme Code Igniter, par exemple) on peut déjà les orienter vers un travail de meilleure qualité.


Sephi-Chan

[Anthor]

Tout ça pour dire que les sécurités sont inclues dans la lib...
Un exemple qui prouve qu'on doit étudier les libs utilisées AVANT de pouvoir discuter sur/reprendre un code (+1 pour l'idée de l'utilisation du php natif? 34)

J'ai bien regardé le code de la librairie, et question sécurité comme tu l'affirmes, il ne risque pas de se passer grand chose si tu ne passe pas les paramètres dans la deuxième argument de fetch.

$data = $db->fetch(

    'SELECT id, pseudo, password, block FROM ? WHERE pseudo = ?',

    array(

        $config['db_prefix'] . 'user',

        $_POST['pseudo']

    )

);

[atra27]

Simplification a tord --'

Je viens de vérifier, je sais pas pourquoi j'ai pas fait comme ça sur cette page.
Et après un rapide coup d'œil, j'ai deux autres pages qui n'utilisent pas les arguments.

Bon alors pour recentrer, quel framework?

[Allwise]

Y a pas mal de sujets qui parlent des frameworks, si tu veux te faire un avis complet sur la question, je te conseille de faire une recherche sur le forum.

N'ayant utilisé que Zend, j'aurais du mal à conseiller autre chose. L'avantage de Zend est qu'il reste à mon avis assez accessible et qu'il permet de paramétrer / d'adapter le processus de dispatching à ses besoin sans trop se prendre la tête, et de faire certaines choses rapidement. L'identification / gestion des droits / la gestion du cache, ou par exemple j'ai mis en place pour un projet full ajax un controlleur avec les méthodes get / getall / save / delete super rapidement, ça fait office de mini crud et fonctionne avec toutes les tables dont le nom apparaît dans un fichier de config prévu à cet effet.
Zend permet de construire des applications robustes et dispose d'un code clair et intelligible pour bon nombre de ses librairies et on prend donc facilement la main dessus.
Symfonie me parait plus costaud et plus long à prendre en main... Mais ses utilisateurs te donneront plus d'infos à son sujet

[Sephi-Chan]

Pour l'avoir utilisé quelques mois, je ne pense pas que ZF puisse être envisagé par des débutants. Rien que quand il vont vouloir créer un formulaire (d'inscription, par exemple), ils vont partir en courant. C'est un très bon framework, très professionnel, mais vraiment pas fun à utiliser, et donc à apprendre. :heuuu:

Je pense que si on va dans du gros comme ça, autant prendre un framework full stack.

Pour ma part, je traite de la création d'un jeu avec Rails (cf. le PDF joint plus haut), car il n'y a pas des tonnes d'alternatives en Ruby.

Mais pour PHP… Il y a Symfony, ZF, CakePHP, Jelix, Code Igniter, etc. Est-ce que les gens auront la foi d'écrire pour autre chose que leur framework habituel ?

Ce choix est très important, mais il incombe aux futurs contributeurs.


Sephi-Chan

[Allwise]

Est-ce que les gens auront la foi d'écrire pour autre chose que leur framework habituel ?

Je pense pas, pour ma part ça me ferait ch*** de devoir apprendre "yet another framework", ça prend trop de temps que je n'ai pas, et je pense que c'est pareil pour tous ceux qui ont un job ou une vie bien remplie

J'aime bien l'idée des tutos de Pascal. Même si les tutos sont écrits sur la base de frameworks différents et de code maison, s'ils sont bien écrits et suffisamment abstraits ils devraient pouvoir être facilement intégrés aux projets des uns des autres, quelqu'en soit le socle.