FORUM PHP/MYSQL (EVOLUTION ASSUREE)

Commentaire de dsyann le 17/07/2008 20:52:39

malheureusement pas encore mais puisque tu l dis ca ne saurait tarder sinon c tres simple la base de donnee est deja la dans le fichier forum.sql donc il n'ya qu'a creer une base de donnee via mysql en important le fichier.

Pas de chemin absolu; En plus j viens de me rappeler que dans l'urgent je dois ajouter un lien profil pour les users.

Commentaire de dsyann le 17/07/2008 23:19:00

Merci webdev pour tes remarques.
je n veux pas faire ma mauvaise foi, ce script n'etait qu'une application q j trouve bien de partage aux autres surtt pour les novices, mais c vrai j suis conscient des efforts a faire d'ou ma conclusion.
Mais excuse moi de te derranger, je sais que c'est pas ton travail et que je pourrais t'ennerver, mais j voudrais avoir une idee ou ne fut ce qu'une page ou l'on parle en detail des ces standars en question.

Commentaire de webdeb le 18/07/2008 00:59:51

@Dsyann : j'ai ouvert quelques fichiers comme l'index.php, deconnexion.php et autres. Mes remarques sont à prendre à la légère rassure toi. C'est bien de présenter ta source et de la soumettre aux critiques des autres. Ainsi on peut voir ce qu'il se fait de très bon, plutôt moyennement bon et pas bon du tout comme source. Ta source fait partie selon moi (avis purement subjectif ^^) des sources moyennement bonnes.

@Evangun :j'appuie mes dires en te disant que mysql_*() sont des fonctions obsolètes aujourd'hui. On les voit encore beaucoup trainer sur les applications web car les développeurs ont toujours connu cette pratique, surtout ceux qui ont démarré PHP à l'ère de PHP 3 et PHP 4. Néanmoins, ces fonctions sont aujourd'hui beaucoup trop limitantes car elles ne permettent pas de profiter des spécificités d'un environnement MySQL 5 à savoir :

- Les transactions,
- Les triggers,
- Les requêtes préparées,
- Les procédures stockées...

C'est pour ces raisons que l'extension MySQLi est apparue en PHP 5 pour venir petit à petit essayer de supplanter l'extension MySQL classique. Ainsi en utilisant l'extension MySQLi, le développeur peut jouir des mêmes fonctionnalités qu'avec MySQL ainsi que des nouveautés propres à MySQL 5 avec des performances légèrement meilleures.

Quant à PDO, il est vrai que cette extension est légèrement moins performante en terme de vélocité du fait notamment de la POO mais a le mérite d'être beaucoup plus performante en terme de fonctionnalités offertes (support des transactions, procédures stockées, triggers, requêtes préparées...) et d'indépendance. Avec PDO, on dépend beaucoup moins de son SGBDR contrairement aux fonctions propres à MySQL. Dans le cadre d'une application de forum open-source, c'est un réel avantage de pouvoir offrir aux utilisateurs un support de l'application sur plusieurs SGBDR. Grâce à PDO, la difficulté de cette tâche est largement réduite puisqu'il n'est pas nécessaire d'avoir à écrire soit même les connecteurs pour chaque base. Il suffit juste d'adapter les requêtes SQL. Il est bon de noter qu'en PHP, seul PDO est capable de se connecter à une base de type SQLite 3 par exemple.

Je tiens à préciser également qu'une version 2 de PDO est en cours de réécriture et devrait paraître avec PHP 6 si je ne montre pas (à vérifier). Toujours est-il que c'est un chantier en cours du côté de l'équipe de développement de PHP. Le succès de PDO grandit de jour en jour, grâce notamment aux frameworks. Il suffit par exemple de constater combien d'applications d'ORM intégrées aux frameworks PHP 5 actuels s'appuient sur PDO. C'est le cas par exemple de Propel 1.3 et Doctrine 0.9 intégrés à Symfony ou bien encore le composant Zend_Db du framework Zend. C'est grâce notamment aux différents feedbacks des développeurs concernant les performances et la potentielle lourdeur de PDO que l'équipe de développement a ouvert un chantier pour améliorer tout ça dans les mois à venir.

Enfin, je rappelle que la nouvelle extension native MySQLnd, dédiée à MySQL, sera packagée avec PHP 5.3 au moment de sa sortie en version bêta dans le courant du mois d'août et en version stable à l'automne. Donc entre MySQL, MySQLi, PDO, MySQLnd et PDO 2, le choix des connecteurs pour MySQL est large et on peut affirmer aujourd'hui que le driver simple MySQL est obsolète. D'autant plus que PHP 4 ne sera plus supporté à partir du 08 août prochain et MySQL est à l'origine une extension PHP 4 destinée à interagir avec des bases de données MySQL 4. Elle a rendu de très bons services aux développeurs jusqu'à maintenant et je pense que ça continuera encore malgré tout, mais il est temps de montrer aux développeurs d'aujourd'hui qu'il existe des solutions plus fiables, plus "performantes", plus pratiques, plus fonctionnelles et plus pérennes. :)

Commentaire de Evangun le 18/07/2008 11:57:23

Mon troll aura au moins servi à provoquer un commentaire très intéressant :p Donc déjà merci Webdeb.

Je comprends la démarche, PDO (puisque je l'ai plus utilisé que MySQLi) va dans le bon sens. Je suis complètement d'accord, moi aussi je sens bien que PDO est propre et efficace, j'aime beaucoup, mais... je vais prendre 5 lignes pour donner mon expérience.

Perso mon problème c'est que je n'ai pas l'usage de toutes ces nouveautés. Je n'ai pas votre niveau et je ne travaille que sur des projets simples, c'est-à-dire que je n'ai pas à prévoir de changement de SGBD, je n'ai jamais utilisé le framework Zend, etc. Quand j'ai vu PDO j'ai dit chouette, et j'ai passé du temps à mettre des scripts à jour. Et puis ensuite les bonnes vieilles fonctions comme mysql_num_rows (puisque ce n'est pas commun à tous les SGBD, elles ne sont pas conseillées) m'ont manqué. Ensuite j'ai essayé MySQLi qui dispose de plus de fonctions sympathiques pour les bases MySQL. Sympa, même si tout n'était pas toujours évident. Et puis j'ai benchmarké les deux et je perdais 10 à 20% de perfs. Alors au final je me suis un peu demandé pourquoi j'avais passé autant de temps à apprendre (les bases) de PDO. Oui, hypothétiquement, ça pourrait servir à faire évoluer mes sites plus tard si je veux les complexifier, mais bon... quel est le pourcentage de sites qui ont besoin de transactions, de triggers ?

Bref, la tendance générale de php c'est d'être de plus en plus professionnel. J'essaie moi aussi d'y aller parce que je suis passionné de programmation et j'aime les choses bien faites. Mais j'ai peur qu'en faisant ça, par exemple en décourageant les gens d'utiliser le procédural au profit de la POO, etc, on enlève le côté "accessible à tous" du php qui a contribué à tant le démocratiser auprès des amateurs. Ceux qui resteront programmeront peut-être comme des dieux, mais si c'est pour que tous les autres abandonnent en cours de route... j'aimerais qu'on trouve un équilibre entre les deux, voilà tout :)

Et désolé pour le code, moi non plus je ne l'ai pas regardé :/

Commentaire de neigedhiver le 18/07/2008 14:17:13

"quel est le pourcentage de sites qui ont besoin de transactions, de triggers ?"
Bien plus que tu ne le penses. C'est juste que c'est pas utilisé. La raison essentielle, à mon sens, ce sont les applications "portables" comme les blogs, les forums, les CMS, qui sont conçus pour s'adapter à toutes sortes de bases de données et qui donc doivent utiliser ce qu'il y a de plus standard. Tout le monde n'a pas forcément un hébergement MySQL 5 (encore que... ne fréquentant plus les hébergeurs, je ne me rends pas compte des proportions).
Alors qu'un trigger et une procédure stockée, ce serait tellement efficace même pour un simple blog...
Exemple :
J'ai un blog, avec des billets, chaque billet ayant des commentaires.
Comme compter, pour chaque billet, le nombre de commentaires est couteux, je vais stocker cette valeur dans la table des billets. Sachant que je peux mettre à jour facilement avec une simple requête SELECT COUNT(*) (depuis l'admin pour regénérer ce "cache", avec un cron...). Pour incrémenter ce compteur, quand j'insère un nouveau commentaire, rien de mieux qu'un trigger qui déclenche une procédure stockée, dont l'unique paramètre est l'id du billet commenté et qui incrémente la valeur du nombre de commentaires dans la table des billets. Idem pour la suppression. La procédure stockée étant gérée par le serveur, celui-ci optimise son exécution (sans oublier les index bien pensés).

Ce n'est donc pas parce que les triggers semblent peu utilisés que leur intérêt est réservé à des sites de grande envergure.

Désolé d'avoir poursuivi le HS, mais la discussion me semble intéressante ;)

Commentaire de webdeb le 18/07/2008 15:58:02

@Evangun :

C'est clair, les triggers et les procédures stockées sont encore méconnus des développeurs débutants (c'est normal) mais également de développeurs plus confirmés. Les applications web dynamiques actuelles utilisent aujourd'hui de plus en plus de technologies (MySQL 5, PHP 5, Ajax, Flash, Perl, Python, Java...). On peut même très bien combiner plusieurs langages serveur en même temps sur une même application. Les procédures stockées et les triggers sont très performants dans le cadre d'applications critiques et très spécifiques. Ils permettent de gagner de précieux temps de réponse puisque ce n'est plus PHP qui traite certaines données mais le serveur de bases de données lui même. De ce fait, Apache et PHP sont libérés pendant ces tâches fastidieuses de calcul. D'autant plus qu'une procédure stockée ou un trigger sont des fonctionnalités compilées et mis en mémoire sur le serveur. Ils sont donc très performant contrairement aux requêtes traditionnelles qui doivent être analysée, compilées, exécutées puis optimisées par leur serveur. Les temps d'analyse de la requête sont coûteux, notamment lorsque le cache de requêtes n'est pas activé sur le serveur. Et à mon avis, sur beaucoup de serveurs MySQL c'est le cas puisqu'il est désactivé par défaut. Les procédures stockées ainsi que les triggers sont quant à eux analysés et optimisés une bonne fois pour toute puis compilé pour être prêts à être uniquement appelé.

On peut également évoquer les requêtes préparées, qui lorsqu'elles sont appelées plus d'une fois dans un script avec des paramètres différents deviennent beaucoup plus performantes que le N appels à la requête avec la méthode traditionnelle. Là encore, les requêtes préparées sont analysées et compilées à la première passe puis mises en mémoire pour le reste du script. Au second appel de la requête, seuls les paramètres de la requête changent mais pas sa structure. De ce fait, il n'est plus nécessaire de l'analyser et de la recompiler à nouveau. Il suffit seulement de lui founir ses nouveaux paramètres. Une requête préparée est donc semblable à une fonction. On la déclare une fois et on l'appel autant de fois que l'on veut avec des paramètres différents.

Enfin, concernant les transactions, figures toi qu'il y'a de plus en plus d'applications qui les utilisent. Notamment les ORM et les frameworks afin de pouvoir travailler avec les contraintes d'intégrité référentielle (contraintes de clés) et ainsi assurer l'Atomicité, la Cohérence, l'Isolation et la Durabilité de la base de données. Les transactions sont le seul et unique moyen efficace pour assurer ces 4 composantes qui forment la norme ACID des SGBDR.

Dans une table MyISAM traditionnelle, si tu supprimes un article d'un blog, tu es obligé de supprimer manuellement les commentaires qui y sont associés dans l'autre table. Que se passe-t-il si entre les deux actions il y'a un problème ? Tu vas à la fois perdre et conserver des données qui ne seront plus cohérentes dans ta BDD. Avec le moteur InnoDB de MySQL qui gère les transactions et l'intégrité référentielle, si tu supprimes ton article dans une transaction alors MySQL se chargera de lui même de supprimer les commentaires associés (si demandé dans le modèle physique avec le onDelete Cascade) en une seule passe grâce à la contrainte de clés qui lie les deux tables. Si une seule requête échoue dans la transaction, alors tout le processus s'arrête et rien n'est supprimé. On conserve donc la cohérence des données d'origine dans la BDD.

Tu peux étendre cet exemple du blog à l'application de forum en te disant : qu'est-ce qui se passe si je supprime un Forum ? Les sous-forums, topics, réponses, sondages... associés seront ils détruits en même temps ? Qu'est-ce qui m'assure de la cohérence de ma base lorsque j'aurais plusieurs centaines de milliers d'enregistrements ? Avec InnoDB pas de problème, alors qu'avec MyISAM ça peut vite devenir difficile à gérer à terme.

Par ailleurs (et pour finir), j'ajoute qu'InnoDB permet de récupérer une base de données en cas de crash grâce à des points de sauvegarde que le serveur fait. En MyISAM, si le serveur crash, tu risques de perdre toutes tes données si aucune sauvegarde antérieure n'est faite... Donc quand tu dis que très peu de sites ont recours aux transactions,c'est faux. On ne peut pas faire un site professionnel pour une application critique sans passer au moins par ce mécanisme qui assure cohérence et intégrité des données dans la BDD. Pour une application qui gère des flux monétaires (banques, e-commerce...), c'est plutôt conseillé sinon on aurait du soucis à se faire.

@DSYANN : oui elle devrait rester mais à ma connaissance ne sera plus compilée par défaut avec PHP. Il faudra explicitement l'installer soi même si l'on fait une installation manuelle de PHP depuis les sources sur son serveur.

++

Commentaire de zeguizmo le 18/07/2008 22:52:50

Salut à tous,

Je trouve la discussion hors sujet très intéressante, aussi j'aimerai partager mon point de vue.

Je suis d'accord avec Evangun sur un point : les performances. J'ai également réalisé quelques bench entre PDO et les requêtes en mysql_* ben même pour des transactions, des requêtes préparées etc.. le gain n'est pas évident ! En théorie, oui, ça devrait mouliner x fois plus vite, mais en pratique bof bof ... on trouve parfois quelques applications mais la majorité des requêtes qui partent sont quand même des basiques, et sur les basiques, ben les perfs sont moins bonnes avec du PDO par exemple. Parfois on n'a pas besoin de sortir le marteau pilon pour écraser une mouche, surtout au niveau d'un débutant. Maintenant moi j'utilise MDB2 en driver MySQLi :)

Par contre la ou mon avis diverge et rejoins complètement neige et webdev, c'est sur la professionnalisation de php. Je crie haut et fort que heureusement qu'il y ait des gens qui tirent php vers le haut ! Je comprend ce que tu penses Evangun, mais le but de l'amateur n'est-il pas de se rapprocher du travail du professionnel ? Si personne ne m'avait dit "eh oh, pense à passer à MVC" ben je serais encore en train de patauger dans mes projets ! Si personne ne m'avait dit "php5 c'est pas fait pour les chiens" (véridique :) ) ben je serais encore en procédural ! Donc oui, il y a des gens pour qui la programmation version rustine est utile et fonctionnelle, mais je ne saurais qu'inciter ces gens à programmer du mieux possible, quel que soit leur niveau ! Rien n'est hors d'atteinte. Et entre nous, ici on parle de la programmation d'un forum, c'est peut-être le type de logiciel php le plus utilisé sur terre :) Donc être exigeant est un minimum.

Pour finir, l'esprit php dont parles Evangun est un peu révolu ... php5 est clairement orienté objet, php6 encore plus, je pense qu'il serait temps de tourner la page. La programmation objet n'est pas beaucoup plus difficile en soit ... Il y a quelques syntaxes à apprendre et on peut très bien s'en sortir au bout de quelques heures de tutoriaux. Je la trouve même beaucoup plus ludique que la programmation procédurale !

Voilà c'est mon avis, un peu entre les deux avis exposés ici,

Bonne soirée,

Guizmo

Commentaire de cmoidhen le 19/07/2008 23:23:38

Bonjour a tous,
Cela fait prés de deux ans que je suis enregistré sur ce site, et je passe mon temps à lire vos commentaires, trés techniques de surcroit.
En tant que newbie j'aimerais juste faire une remarque: Dans la plupart des cas les codes postés ne fonctionnent pas. Ben voui c comme ça.
Alors si vous me le permettez, mais ce n'est qu'une remarque, moi je préférerais des discutions moins pointues mais permettant de réaliser des codes qui sont portables et qui fonctionnent.
Toutes ces discussions ditirambiques pour des codes que l'on doit reprendre et éplucher ???
J'ai beaucoup de mal à comprendre que l'on puisse perdre du temps àcommenter un code qui ne soit pas au minimum portable..
Pardonne moi DSYANN si je poste ce message sur ton code mais les commentaires m'ont fait réagir.
Pour les admins je dirais juste que votre site est trés bien fait, que les tutos sont trés moyens, et que poster des commentaires techniques sur du code non portable me semble innutile.
Mais encore une fois, je suis un newbie.
Je prends mes codes sur d'autres sites, dans les tutos et cela fonctionne, alors je reste perplexe quand je prends un code noté 8 au minimum et qu'il ne fonctionne pas.
Suis-je maladroit, n'ai-je pas tout compris?( ça c sur)
Ou tout simplement votre site n'est-il pas fait pour moi?
Désolé pour le coup de gueule, mais depuis deux ans chaque codes téléchargé sur ce site n'a fonctionné qu'aprés des heures de modifs, alors que sur le site du zéro pour ne pas le citer ça marche nikel.
Je vous prie tous de bien vouloir m'excuser mais vos commentaires sur tel ou tel détail m'ont exacerbé, pour moi un code posté doit d'abord fonctionner, quelque soit la configuration du serveur, et aprés seulement aprés l'on doit s'interesser aux détails.
Combien de codes sont postés sur votre site concernant l'upload de fichier, et combien fonctionnent réellement? Zéro.
Faites du tri, sur un certain site que je ne citerais pas un seul tuto et il fonctionne.

Commentaire de neigedhiver le 20/07/2008 12:38:34

Salut,

La discussion prend une tournure très intéressante, bien que toujours hors sujet. Comme cela a été dit, il n'est pas facile d'avoir ce genre de discussion sur phpcs, d'autant que je trouve que le forum ne se prête pas du tout à des discussions "persistantes" (pour reprendre l'expression de Malalam). Le forum, je ne le consulte que d'après les messages en page d'accueil. Pour le reste, je le trouve totalement inadapté. Donc, parfois les sources donnent naissance à des discussions comme celle-ci. C'est à la fois dommage et une bonne chose. Dommage, parce que c'est hors sujet dans ce contexte, et que la discussion n'est pas facilement accessible (qui irait imaginer qu'une petite source de forum sans prétention abrite une discussion sur la professionnalisation de PHP et les procédures stockées et autres triggers en MySQL 5 ?).
Mais c'est aussi une bonne chose, parce que la discussion existe quand même et est suivie.

Concernant la "professionnalisation de PHP", je rejoins ce que Webdeb et zeguizmo : PHP était au départ un petit langage de développement web sans grande prétention qui a évolué pour faire face à son colossal succès et sa démocratisation fulgurante. Il s'est enrichi de concepts qu'il n'avait pas à ses débuts (POO), a été amélioré dans les performances, etc.
C'est aujourd'hui un véritable langage de programmation objet utilisé professionnellement, avec des certifications du même niveau que les certifs Microsoft. C'est un langage qui nécessite une part d'analyse dans les projets, au même titre que les autres langages.
Les débutants et les profanes en général ont tendance à ne pas vouloir faire plus que ce qu'ils pensent être leur limite. On le comprend : parfois, un ouvrier veut faire un petit site web pour échanger avec sa famille et quelques amis : il veut alors un petit forum, un livre d'or, une galerie... Et il veut le faire lui-même, parce que c'est plus gratifiant, comme un informaticien pourrait vouloir construire lui-même sa terrasse avec son barbecue.
Seulement j'ai l'impression que si un informaticien veut faire sa terrasse et son barbecue, il est admis qu'il devra faire ça dans les règles de l'art, s'informer, s'équiper également (bétonneuse, règle de maçon, niveau, peut-être un niveau à laser, etc). Personne ne comprendra vraiment qu'il souhaite faire ça à l'arrache, avec une simple gâche et quelques cailloux pour paver.
Par contre, il est presque intolérable qu'un développeur web puisse recommander à un ouvrier de développer en objet son site web famillial, sous prétexte que ce n'est pas sa formation ni son métier. Il faudra le laisser faire du code pourri qui ne pourra pas évoluer et le laisser héberger tout ça chez Lycos avec des pubs de partout. Pardon, mais j'aime pas les injustices...

Quant à la qualité des sources sur phpcs, ça me rappelle étrangement une discussion que j'ai eu il y a quelques temps avec Malalam sur le sujet. Le problème de phpcs, c'est que tout le monde peut poster tout et n'importe quoi. L'avantage, c'est que tout le monde peut poster tout et n'importe quoi. C'est à double tranchant. Et il faut tenir compte de ça quand on vient sur phpcs pour se documenter. Zeguizmo l'a me semble-t-il parfaitement analysé, et l'analyse pourrait même être encore plus poussée (mais bon, pas dans les commentaires de cette source, ce serait vraiment abuser). Néanmoins, les faits sont là : des sources de tous niveaux, de qualité très variée jonchent phpcs. Elle sont là pour des raisons très diverses également. Toutes ne sont pas facilement intégrables dans des sites déjà existants, parce que mal conçues (exit MVC, du CSS généré par le PHP, etc). A côté de ça, certains tentent tant bien que mal, de proposer des sources qui respectent quelques règles élémentaires de développement Objet (MVC notamment) ce qui a deux conséquences :
- elles sont facilement intégrables, parce que ne produisant aucune mise en forme des données produites, et laissant ça à la charge de l'intégrateur
- elles sont considérées comme difficiles d'accès car le code obéit à une logique qui n'est pas celle du développement procédural, qui reste le plus répandu, même sur phpcs. Alors que justement, le fait qu'elles soient orientées objet, leur confère une facilité d'utilisation que n'ont pas les sources procédurales.

Concernant les tutos, c'est exactement le même problème. Partout, on trouve de tout et n'importe quoi. Et un script trouvé sur un site, n'est pas nécessairement de bonne qualité sous prétexte qu'il tourne : ça n'a rien à voir. Un script de qualité peut nécessiter des adaptations.

Voilà mon point de vue sur tout ça, en gros (j'ai résumé). La discussion est vraiment intéressante, et je remercie tous les protagonistes pour leurs interventions : avoir plusieurs points de vues tous motivés, c'est très agréable.

Bon dimanche :)

Commentaire de webdeb le 20/07/2008 13:11:41

@cmoidhen : comme le disent zeguizmo et neigedhiver, on peut trouver de tout et n'importe quoi sur PHPCS. Aussi bien d'excellents codes procéduraux ou orientés objets que de codes complètement crades, inutilisables... qu'ils soient eux aussi procéduraux ou objets. J'ajoute également qu'aucun développeur qui poste une source ici n'est contraint et forcé de produire un code qui fonctionne. Il n'y a aucune obligation de résultat viable quand on dépose une source.

Malgré tout, on ne peut pas pour autant critiquer PHPCS et les sources comme ça. Si tu observes bien, le réseau Codes-Sources dont fait partie PHPCS c'est une communauté de plusieurs milliers de développeurs de niveau très hétérogènes. Il y'a des des professionnels, des confirmés, des débutants et des nouveaux avec PHP. Tous essaient de proposer leur aide et leur critique sur les sources qu'ils voient et parfois testent. Néanmoins, avec le nombre d'informations postées chaque jour par toute cette communauté, il est clairement impossible par l'équipe d'administration de tester les sources diffusées.

Et finalement, que certaines sources ne fonctionnent pas, ce n'est pas plus mal par moment. Cela oblige le développeur à s'approprier intellectuellement le code pour le comprendre et le débugguer lui même. De cette manière, on apprend beaucoup mieux. Par ailleurs, il est bon de montrer et de critiquer les codes de mauvaise facture car cela permet à l'auteur de comprendre où sont ses erreurs et comment les corriger. D'autres part, cela permet aux autres membres de la communauté de s'informer sur la qualité et la sécurité des codes présentés grâce aux avis des membres confirmés et experts de ce PHPCS. On n'apprend pas uniquement en montrant ce qu'il est bien de faire. On apprend beaucoup également en diffusant et critiquant des sources de mauvaise qualité. Avec de tels contre exemples, on sait que telle ou telle pratique est mal et que l'on a aucun intérêt à la reproduire dans des développements ultérieurs.

Quant au risque de frustrer les débutants de poster leurs sources parce qu'ils craignent de se les faire torpiller à coups de critiques un peu rudes ou sévères, c'est le risque à prendre pour apprendre davantage. Personnellement, je me suis permis de critiquer cette source de forum car :

1/ J'avais analysé quelques bouts de code
2/ Parce qu'il y'avait beaucoup de choses intéressantes à y dire pour le faire évoluer

Mon commentaire, je l'ai écrit de manière constructive pour l'auteur de la source. En revanche, je ne cautionne pas les critiques virulentes non argumentées du genre "ton code il est naze, il ne sert à rien...". Critiquer, c'est savoir expliquer et argumenter ses propos et non torpiller quelque chose ou quelqu'un par plaisir.

Se prétendre développeur, ce n'est pas copier / coller un code récupéré sur un site spécialisé mais c'est avant tout savoir analyser, comprendre et même reproduire ce code avec plus ou moins d'aisance. L'intégration de code n'est qu'une infime partie de la tâche du développeur. En amont, il y'a toute une phase d'analyse, de conceptualisation, de prototypage, de tests...que ce soit pour de petits projets comme pour de gros projets professionnels.

Je rebondis sur le site que tu as cité (le site du zéro). Je ne souhaite pas entrer dans un troll mais pour moi le Site Du Zéro n'a rien d'un site pour apprendre le développement PHP dans la mesure où il enseigne une grande majorité de mauvaises pratiques. Et là où c'est le plus malheureux, c'est qu'au final la plupart des mauvais codes que l'on voit ici  ont été produits par des aficionados du Site Du Zero. Pour participer de temps en temps au forum de ce dit site, je me suis aperçu que beaucoup de membres ne savait faire que reproduire ce qu'on leur présentait à l'écran sans pour autant chercher à prendre du recul et se documenter ailleurs. Donc je t'invite sérieusement à prendre beaucoup de recul avec les tutoriels et autres codes du Site Du Zéro car ils sont loin d'être des références en matière de développement informatique. Heureusement que certains membres de ce site en question comme `Haku ou Tracker réhaussent un peu le niveau avec leurs tutoriels et leurs conseils respectifs. Ce qu'il manque avant tout aux tutoriels du site du zéro c'est un écrit pour expliquer aux membres comment rechercher efficacement dans la documentation officielle, comment la comprendre, sur quels autres sites de références s'appuyer pour trouver des codes et tutoriels supplémentaires... Dans le cadre de mon site Apprendre-PHP.com j'essaie, dans la mesure du possible, de joindre dans mes tutoriels des liens vers des sources externes complémentaires pour permettre à mes lecteurs de lire autre chose que mes tutoriels et de se documenter sur davantage de sources tout aussi intéressantes (PHP.net, Developpez.com, PHPTeam.net, PHPDebutant.org, PHPFrance, blogs de spécialistes en tout genre...).

Commentaire de codefalse le 23/07/2008 15:43:47 administrateur CS

Et ben ! Quel pavés !!

Merci pour les références à ma source au passage :)

J'ai ajouté le second commentaire de WebDeb sur mon blog car je le trouve vraiment très complet, précis et vrai ! (http://blog.reflectiv.net)

Personnellement je n'ajouterai rien de plus sachant que tout à déjà été dit :)

(les commentaires traitant de la mise en place du message sur le blog ont été supprimés car vraiment trop hors sujet, j'ai laissé l'url au cas ou certains voudraient le voir, mais je peux aussi le supprimer si vous ne le voulez pas)

Commentaire de toutoos le 24/07/2008 02:54:37

apart que vous faite un magnifique déba sur les requètes futurs vous voyez je me suis amusé a tout lire et franchement j'ai commencer a codé en php3 cela fai maintenant quelque année que cleuici a disparut et nous sommes passé a php4 et un peu a php5 mais bon je suis désolé mais je pense que le type de requète a utilisé dépend de lutilité du script et dans le cas d'un simple forum je ne pense pas que coder des requète en mysqli ou pdo soit vraiment utile. Mais par contre pour les  personne utilisant des scripts vraiment particulier ( sauvegarde de base de donnée ; et transaction ) la par contre c'est plus utile! Après c'a n'engage que moi

Commentaire de toutoos le 24/07/2008 09:47:53

ouais excuse moi j'avai éffectivement mal comprix mais a 3heure du matin j'étai pas vraiment en total bonne forme! mais ou peut t'on trouvé un cours complet sur ce genre d'expension. est ce que sur http://fr.php.net on trouvera ce type de crous. enfin la documentation variables plutot?

Commentaire de toutoos le 24/07/2008 10:04:54

attend si je pense avoir compri! en faite l'avantage c'est que l'on peut lancer plusieur requète en une seul commande. En fait c'est très avantageu pour mon projet!

Commentaire de toutoos le 24/07/2008 14:02:26

j'ai vu jai vu et pour lavancement de mon projet c'est une bonne idée!
paske avec msql j'ai plis d'injection sql et tt alors je suis obliger de blinder ; sur blinder ; reblinder le site!
Alors au niveau sécurité j'en ai trop mar! amis mon projet touche a sa fin domage que je ne me soit pas intérèssé a ca plus tot!

Commentaire de neigedhiver le 07/08/2008 11:41:47

@AZQSAZQS :

"Pourtant, étant moi même noob (si on peut dire) un truc me chiffone, pas moyen de trouver un cours, un tuto qui explique correctement PHP5 et ses dérivés. Donc forcément ca peut poser problèmes quand à l'évolution des codes."

Les bons tutos n'existent pas car ils devraient être écrits par des "pros", en tout cas des personnes qui ont de sérieuses et solides connaissances en développement, si possible assorties d'une bonne expérience.
Ces tutos, en fait, ils existent. Mais pas sur le net. Dans les librairies. Ce sont ce qu'on appelle des livres. On les trouve non pas sur le net, mais dans ce qu'on appelle des librairies. Il en existe même des spécialisées.
Certes, ce ne sont pas des documents gratuits. Mais ce sont des documents de qualité.

Mais au-delà des cours, ce qui importe, c'est la volonté de chacun à vouloir progresser, produire un code propre, sécurisé, évolutif, modulaire et aisément maintenable. Or, bien souvent, cette volonté est inexistante. Le premier argument avancé afin de justifier cette lacune est que pour un petit site perso, c'est pas important... Alors que justement, c'est par là qu'il faut commencer.

"les expérimentés "modérés qui préfèrent la rapidité et la simplicité de code plutôt que des codes encombrants bien que plus aux normes."

Là, tu fais un méchant amalgame qui n'a pas lieu d'être. Je ne sais pas ce que c'est pour toi la simplicité de code.
Pour moi, un code simple, c'est un code clair, documenté, réfléchi, modulaire, réutilisable. Ca peut être un code qui utilise 250 classes pour faire ce qu'il fait, il peut être quand même très simple à utiliser. Pour ma part, je m'efforce de produire ce genre de code. Et de nombreux autres s'y efforcent également sur PHPCS ou ailleurs.
D'ailleurs, la simplicité de code n'est pas nécessairement synonyme de performance (puisque tu parles de rapidité). Et puis il faut savoir ce qu'on appelle rapidité : rapidité d'exécution, rapidité de maintenance, rapidité de développement...
Bref... Les "noobs" comme tu les appelles, ont souvent des a prioris comme ceux qui transpirent de cette phrase que tu as écrite. Pour ma part, je ne peux qu'espérer que ça aille en s'arrangeant. Encore faut-il que les "noobs" qui souhaitent vraiment développer fassent l'effort de développer correctement : parce que développer, ça s'apprend, mais ça ne s'invente pas.

Commentaire de Evangun le 07/08/2008 16:26:15

Puisqu'on parle de bouquin, je n'en ai pas trouvé à la fnac sur la POO en php. Dans celui des éditions O'Reilly (qui ont fermé il me semble, malheureusement), ça ne représente qu'une petite portion du pavé. Je n'ai trouvé qu'un seul livre entièrement consacré à la POO, et il était multilangage (Java, etc), donc si c'est pour apprendre des techniques qui ne fonctionnent pas en php, ça va m'embrouiller plus qu'autre chose. Tout ça pour dire : Neige si tu connais un bon bouquin pour la POO en php je suis preneur.
à+

Commentaire de Evangun le 07/08/2008 17:35:37

Parfait, j'attendrai jusque là alors (pas encore de temps à moi de toute façon) :)

Commentaire de toutoos le 08/08/2008 10:09:05

Je me suis penché sur le script ( il en falais bien un ) j'ai remarké énormément de SELECT ( comme énoncé plus haut c'est dailleur de la que vient tout le hors sujet ) mais aussi le nom de tes pages comme connect.php qui d'après leurs scrtip non aucun rapport avec leurs nom! après peutètre que j'ai mal compris!

Commentaire de dsyann le 19/08/2009 20:17:43

Salut
cette erreur est due au fait que tu veux inserer une valeur nulle dans un champs NOT NULL en l'occurance id_quest. Effectivement id_quest dans la table question, messages et reponses sont not null.
Logique, car chaque question a son identifiant, qui doit etre forcement dans la table dans laquelle sont contenu des questions.
Cette valeur est donnée par mysql lors de la creation de la question puis envoyer dans la table messages par mysqllastid.
Mais pour revenir au debut, ta question n'est pas precise, precises les conditions dans lesquelles tu as trouver cette erreur (fichier, quelles actions? ...).