FORUM PHP/MYSQL (EVOLUTION ASSUREE)
viki53
Messages postés
31
Date d'inscription
samedi 9 février 2008
Statut
Membre
Dernière intervention
11 septembre 2008
-
17 juil. 2008 à 20:46
tronch Messages postés 5 Date d'inscription dimanche 24 mai 2009 Statut Membre Dernière intervention 24 août 2009 - 24 août 2009 à 10:39
tronch Messages postés 5 Date d'inscription dimanche 24 mai 2009 Statut Membre Dernière intervention 24 août 2009 - 24 août 2009 à 10:39
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/47343-forum-php-mysql-evolution-assuree
https://codes-sources.commentcamarche.net/source/47343-forum-php-mysql-evolution-assuree
24 août 2009 à 10:39
Pour préciser l'action qui est faite,
1 ) Quand je rentre des informations dans le formulaire (nouveau sujet( fichier insert_sujet.php)) et ensuite je veux poster ce nouveau sujet ( poster (fichier trt_sujet)) j'ai ce message d'erreur Erreur:Column 'id_quest' cannot be null,
Auparavant je me suis connecté,
Merci de ta réponse et de ton explication et si une solution se présente de pouvoir comprendre comment rectifier ce problème,
tronch
19 août 2009 à 20:17
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? ...).
19 août 2009 à 12:51
Sur ce FORUM PHP/MYSQL (EVOLUTION ASSUREE)j'ai une erreur comme celle decrite ci-dessous :
Erreur:Column 'id_quest' cannot be null
l'un d'entre vous auait il une exlication,
Merci à tous,
Tonch
8 août 2008 à 10:09
7 août 2008 à 18:13
J'avais à une époque un excellent bouquin sur la POO en PHP5, mais j'ai (à cause de mon grand âge) oublié l'éditeur et le titre (ah bravo !).
J'ai acheté dernièrement un bouquin qui s'appelle "UML et Designs Patterns", de Craig Larman, chez Pearsons Education (03/2005). Je l'ai pas encore ouvert lol
Pour apprendre les méthodes de conception, je préconise aussi tout ce qui touche à Merise. Les bouquins sur le sujet n'étant pas légion à la FNAC, le choix est assez facile à faire... Celui que j'ai s'appelle "L'essentiel sur Merise", de Dominique Dionisi, chez Eyrolles, et me sert régulièrement comme référence pour modéliser mes projets (parce que je ne connais pas toutes les règles par coeur)
Enfin, il existe aussi des bouquins passionnants sur l'eXtreme Programming, les Méthodes Agiles, etc.
7 août 2008 à 17:35
7 août 2008 à 17:07
Sinon je peux t'inciter à te procurer le livre PHP 5 Avancé aux édition Eyrolles qui dédie un gros chapitre sur la POO en PHP, ce qui te permettra de bien démarré. Par contre, je travaille actuellement avec Cyril et Eric (les deux auteurs) sur la cinquième édition qui paraîtra d'ici le mois de septembre ou octobre. Et il y'a eu pas mal de modifications sur ce chapitre dédié à la POO afin de le remettre au goût du jour.
A+
Hugo.
7 août 2008 à 16:26
à+
7 août 2008 à 13:30
En effet grace a cette discussion j'ai vu toutes les erreurs que je faisait mais cela apres que j'ai decide d'apprendre tous les termes et methodes, bref pousses la recherches sur tout ce que j'ai appris ici mais aussi desormais seul grace a moi meme.
Du coup je peux me classer moi aussi desormais mm si j n suis pas encore pro dans ce domaine un Pro de PHP 5 et autres coe tu l'as dis (surtt l MVC).
Donc fait coe moi ca ira, tu veras a quel point c beau d'avoir un programme en module qui facilite enormement la maintenance (a moins de faire des programmes ou site sans maintenance) mais aussi la comprehension du code par les autres, le fait de te retrouver toi mm aussi trop facilement ac ton code, les erreurs surtt si tu doubles cela ac un systeme d'erreurs notes sur cahier de charges...).
Alle fais le tu le trouveas moins complexe que c'en a l'air et c plutot cool.
Je comptais propose ce forum plus corrige que j'avais deja fait mais j ne le ferais pas car j'en proposerais un aux normes et modules tres bientoy (car je suis tres occupe par un emploi ces jours ci).
7 août 2008 à 11:41
"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.
7 août 2008 à 11:16
La discussion hors sujet est interressant (déjà dit) mais il y a un point sur lequel j'aimerais appuyer.
Il y a deux parties ici, les Pro PHP5 avec PDO, MVC et autres appellations que je ne connais pas. Et il y a les noob (si on peut dire) et 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.
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.
Je rejoint également cmoidhen sur le fait que la plupart des codes ne marches pas. J'ai vu notamment des codes (a retravailler un minimum car moche ou obsolètes) qui faisait appelle a une BDD MySQL mais on avait pas la structure de la BDD qui accompagne le code.
Pour le reste, je verrais plus tard, là j'ai pas le temps.
24 juil. 2008 à 14:02
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!
24 juil. 2008 à 13:56
Sinon, google est ton ami.
en effet tu peux avoir plusieurs requetes que tu peux garder et adapter le code, exemple :
$oPdo = new Pdo ('...');
$oTaRequete = $oPdo->prepare ('DELETE FROM matable WHERE id=?');
ensuite un :
foreach ($_POST['id'] as $iValue) {
$oTaRequete->execute (array ($iValue));
}
Et le pire dans tout ca c'est que tu n'a même pas besoin de te soucier de si $iValue est bien une valeur correcte et pas une tentative de sql injection, car la fonction execute se charge d'empecher ce type d'attaque !
Du coup avec Pdo, du gagne en sécurité !
24 juil. 2008 à 10:04
24 juil. 2008 à 09:58
24 juil. 2008 à 09:47
24 juil. 2008 à 09:10
Visiblement, tu n'as pas compris ce que sont MySQLi et PDO. Ce ne sont pas des requêtes mais des extensions permettant respectivement de manipuler les SGBDR MySQL ou tous types de SGBDR. MySQLi (i pour "improved" => amélioré) est l'extension qui est née avec PHP 5 pour remplacée l'extension MySQL actuelle afin de supporter ces nouvelles fonctionnalités de MySQL 5 (transactions, procédures stockées, requêtes imbriquées que je n'avais pas mentionné) et des performances bien meilleures. Tu peux donc (et c'est vivement conseillé) utiliser tes applications actuelles qui fonctionnent en MySQL 4 via le driver MySQLi. Tu auras juste dans ton code à remplacer tes fonctions mysql_*() par mysqli_*() et supprimer la fonction mysql_select_db() qui est maintenant gérée en interne dans la fonction mysqli_connect(). Mais au final, tes requêtes ne changent absolument pas, tout comme sur PDO.
Quant à PDO, ce n'est qu'une interface "standard" qui permet de se connecter à plusieurs types de SGBDR en utilisant toujours la même syntaxe. Par exemple, si j'ai une table "membre" dans ma base de données "monsite" et que ma base soit en MySQL ou SQLite par exemple, j'exécuterai ma requête de la même façon pour les deux. C'est à dire :
$pdo = new PDO('mon DSN de BDD');
$stmt = $pdo->query('SELECT login, email FROM membre');
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);
foreach($results as $member) {
echo $member['login'] .' : '. $member['email'] .'
';
}
La seule à adapter est la requête SQL en fonction du SGBD. Imagine l'intérêt que l'on peut avoir à utiliser PDO dans le cas d'applications open-source portables. Prends l'exemple de PHPBB qui fonctionne sur MySQL, PostGreSQL et MySQL Server je crois. Pour permettre cette interopérabilité, ils ont développé une classe d'abstraction de bases de données à eux complètement imbuvable et chaotique (mais c'était l'époque de PHP4 donc ça se comprend) qui les a obligé à écrire les adaptateurs pour chaque base. Un adaptateur étant une classe ou plusieurs par SGBDR. Ensuite ils ont du également écrire les requêtes non standard propre à chaque SGBDR. Avec PDO, la couche d'adaptation est déjà gérée en offrant des performances bien meilleures qu'une application maison. Pour construire une application open-source portable sur plusieurs SGBDR, l'utilisation de PDO est d'une grande aide.
Mais ce cas ne s'applique pas qu'aux applications open-source. Prends l'exemple d'une société (agence web par exemple) qui édite et vend son CMS aux clients. Avec PDO, elle pourra faire en sorte de facilement porté son CMS sur plusieurs SGBDR et s'offrir ainsi une clientèle plus large. Si un client possède une base de données SQL Server, PostGreSQL ou Oracle car l'ensemble des logiciels de sa société repose dessus. Si ce dernier souhaite intégrer un extranet interne ou un site Internet grand public exploitant directement les données de sa BDD, le fait de pouvoir lui proposer une solution qui peut se greffer facilement dessus est un véritable point fort. Alors que si l'on doit lui dire :
"Notre application n'est que disponible sur MySQL, c'est soit vous acceptez que l'on vous installe MySQL en plus de votre architecture ou alors on triple le prix de notre produit pour compenser la perte que l'on aura à l'adapter pour être intégré à votre SGBDR".
Avec PDO, résoudre cette problématique n'est qu'une question de secondes si l'application est bien faite, voire de quelques heures s'il faut adapter les requêtes spécifiques aux SGBDR.
++
24 juil. 2008 à 02:54
23 juil. 2008 à 16:24
La source officielle : http://news.php.net/php.pdo/1
La source officielle résumée en français : http://www.phportail.net/news/1188-pdo2-lance.php
Concernant MySQLnd qui sera intégrée à PHP 5.3, il faut savoir que ce futur driver a été écrit par la société MySQL AB. Qui mieux que l'éditeur du logiciel est le mieux placé pour développer un pilote propre à son logiciel ? Je vous laisse lire ce billet de Romain Bourdon (auteur de Wamp Server) concernant les nouveautés offertes par MySQL ND.
http://blog.wampserver.com/index.php/2007/12/04/mysqlnd-un-driver-mysql-optimise-pour-php/
Hugo.
23 juil. 2008 à 15:43
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)
20 juil. 2008 à 22:49
Moi aussi je remercie ceux avec qui on a discuté sur cette page. Pour info, vous m'avez redonné une sérieuse envie de me replonger dans la doc pour approfondir ma POO, parmi tant d'autres choses. Je programme tellement que je n'ai plus vraiment le temps de me lancer dans de nouveaux tutos, mais je m'y remettrai quand je pourrai.
PS pour les nouveaux : allez courage le php c'est pas dur :p Et si vous voulez m'aider à refaire ma terrasse, vous êtes les bienvenus aussi, ça c'est trop compliqué pour moi ;)
20 juil. 2008 à 13:11
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...).
20 juil. 2008 à 12:39
Au 1, faut aussi lire les commentaires que postes les auteurs de codes. Je ne sais pas pour les autres mais chez moi c bien ecrit en noir et blanc que c pas standard. Par la j'entends que les traitements ne sont pas pour l'instant assez portable ou pas du tt.
Au deux si tu lis le titre j'ai ecrit evolustion assuree pour simplement signifie que c'un code qui date de mars si tu vois ma base de donnees mais que je soumets a la critique et que je veux que ca evoluee et ca le sera.
Au trois ce debat hors sujet coe tu le dis au depart aurait pu m'ennerve aussi. Au 1 on pourrais dire aucun rapport avec mon code. Au deux a la lumiere de ce que je lis du fait qu'a peine je commence a comprendre le PHP simple que l'on me dis "Connais tu C# ou java? eh beuh PHP aussi les suis".
Mais a tt te dire c le contraire ce debat m'a beaucoup appris et je tiens a remercier ceux qui l'on fait je me demande bien s'il y'a deja des debats ainsi sur l site sinon il faut qu'il y en ai car nous novice on apprends les infos plus ou moins techniques historiques... sur des codes que nous pendons sans tantot connaitre ou s'interresse a tel historique, evolution et autre.
Mais c peut etre pas de ta faute aussi car tu n'as pas suivi l debat relis tous les messages et tu troiuveras interressant tout ce dont ils ont dis sinon si tu connais deja ca oui ca pourra t'ennuyer.
Alors moi aussi je justifie ce que je dis qd je dis que je te trouve coe ces gens que tu ne veux pas:
Tu dis les codes ne fonctionnent pas.
Je ne crois pas que ce forum est une entreprise qui pond des RAD (a la windev) pour etre immplante directement dans X sites ou Y devoir. Il y'a des milliers de codes qu'a mon niveau je juge tres bien fait coe:
[PHP5] - SIMPLE CLASSE D'ENVOI D'EMAIL par codefalse
mais voila fute de temps et autre et en plus ct pas urgent pour moi j'ai pas executer, alors si un jour j'arrivais a importer chez moi ce beau travail et que ca ne marche pas, eh beuh je verrais ou es l pb et arrangerais simplement.
Or a force de critiquer les codes de DEBUTANTS (lis ma classification) tu les poussent a ne plus poster de peur d'etre assailli de partt par des commentaires du genre ca ne marche pas ton code, parfois pb du a la plate forme utilisee (easyphp 1,8 contre 2,0 ou je ne sais quel WAMP....).
Mais en gros je resume mon code n'est pas encore standard mais d'ici peu je penderais une version a la WEBDEV (lol) version PHPOO (faut que j'apprennes dabord pour ca) mais aussi standartd barde de fonttion simple globales et facilement manipulable.
En core une fois je tiens a vs remercier tous webdev neigedhiver EVANGUN... continuer a nous partager cette connaissance sans critique(pb de la des gens qui connaissent et oublies que eux aussi avant etait coe nous debutants) coe vs le faites j'ai apprecie vos coms et beaucoup appris!!!
20 juil. 2008 à 12:38
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 :)
20 juil. 2008 à 01:48
Le point que tu soulèves est très pertinent, je pense également qu'il faudrait débattre pour trouver une solution qui permette d'épurer la base de codes de phpcs. J'avais avancé l'idée de "membres élites", connus par les admins, qui pourraient trier les codes en un clic, je ne sais pas si c'est la meilleure idée, mais je suis d'accord sur le fait qu'il faudrait trouver une solution.
Maintenant venir raler dans les commentaires n'est peut-être pas une solution. Il y a un forum dédié à cela qui s'appelle la boite à idées. Ce forum est destiné à faire progresser le site en y déposant nos idées. Tu peux y retrouver mon post, et y apporter ta contribution :
http://www.phpcs.com/infomsg_MEMBRES-ELITES_1038683.aspx#2
Ou entammer ton propre post et mener une croisade pour faire changer les choses.
Ensuite, les commentaires - et particulièrement le mien - sont ici quasiment hors sujet. Je n'ai même pas regardé de près le code de ce forum, la discussion est partie en live... C'est peut-être un peu incorrect pour l'auteur du code, qui trouve des messages qui ne lui sont pas directement destinés, mais en même temps, c'est très intéressant - pour ceux qui arrivent à suivre, je te l'accorde - de trouver expliquées en détails les positions des différents programmeurs. La programmation est loin d'être une science figée, et chacun possède sa propre interprétation de la chose. Parfois on ne comprend pas l'intérêt de certaines méthodes, et lire des commentaires comme ceux ci peuvent nous éclairer sur les pourquois du comment de ces méthodes.
C'est pourquoi nous ne notons pas les sources que nous n'avons pas regardé en détail. Si tu regardes bien, la seule note motivée par des commentaires déposée par webdev est de 6/10, ce qui est bien, mais loin d'être parfait. Comme je l'ai dit plus haut, ce n'est peut-être pas très correct, mais les discussions intéressantes en français ne sont pas légions sur le sujet, aussi nous prenons plaisir à y participer, peut-être à tort.
Enfin, le but de phpcs n'est pas, à mon sens, de fournir une source clé en main. Les sources se classent en de nombreuses catégories : les expérimentations soumises à critique, les coups dans l'eau, les sources rad (rien à redire :) ), les demandes d'avis du public ... bref, personne ne garanti que la source va fonctionner sur tous les serveurs avec toutes les versions (ce qui est quasiment impossible ... certaines versions sont maintenant complètement obsolètes). Les codes sont ici pour t'aider à faire le tiens, et non pas pour être intégralement repompés. Trouver un code qui fonctionne sera un grand coup de pouce dans ta quête, mais à moins de le réécrire correctement, il y a fort peu de chances pour qu'il s'insère en gardant toute son intégrité dans ton projet.
Voilà, j'espère t'avoir éclairé sur les points qui semblent te poser problème.
Bonne soirée,
Guizmo
19 juil. 2008 à 23:23
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.
19 juil. 2008 à 02:14
Dans mes remarques, ce que j'essaie de faire comprendre, c'est qu'il faut prendre conscience de toutes ces avancées technologiques et ne pas rester sur des pratiques ancestrales de programmation PHP. L'objectif est de progresser et d'apprendre de nouvelles choses. Je me doute bien que pour son petit forum, il ne va se prendre la tête avec des procédures stockées, des triggers, des requêtes préparées... Mais dans l'idéal, il le faudrait. Au final, je dis juste qu'utiliser MySQLI (au pire) ou PDO (au mieux), c'est déjà avoir à l'esprit que lorsque l'on souhaitera mettre en pratique ces notions avancées de SQL ce sera possible. Alors qu'avec les vieilles fonctions mysql_*(), ce sera mort dès le début.
18 juil. 2008 à 22:52
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
18 juil. 2008 à 18:14
Néanmoins tu confirmes ce que je disais plus haut, c'est que tu penses le php comme un professionnel. Les transactions pour l'intégrité de la BDD c'est bien, mais ce n'est pas la priorité pour tout le monde. Tu penses aux banques et à leur système monétaire, mais le programmeur lambda pense à son forum et ce qu'il veut en premier lieu, ce sont de bonnes performances. Tu penses à relationnel pour un système parfait, il pense à rapide pour un système qui marche. Pour un forum quelconque, InnoDB est moins adapté que MyIsam parce que les développeurs de ce dernier ont pensé avant tout à accélérer la vitesse en lecture, pas à garder l'intégrité de la base. La probabilité qu'un problème survienne au milieu d'un ensemble de requêtes n'est pas très élevée, et quand bien même, avoir des lignes orpheline dans une table ne gênera pas monsieur tout le monde.
Bref, au risque de me répéter: dans l'absolu je reconnais tout à fait les avantages des transactions/triggers/procédures et autres avancées de php. Ce qui me gêne c'est que la rigueur de pros comme toi ou Neige (qui est une bonne chose dans l'absolu hein) finit par modifier la philosophie du php. D'un langage simple et pragmatique qui a séduit des millions de personnes, on passe à un php plus complet mais aussi plus complexe. Moi j'essaie de tenir la cadence et d'évoluer avec lui, mais je ne sais pas si les futures générations continueront d'avoir le coup de foudre pour notre cher éléphant...
18 juil. 2008 à 15:58
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.
++
18 juil. 2008 à 15:53
18 juil. 2008 à 14:17
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 ;)
18 juil. 2008 à 13:34
18 juil. 2008 à 11:57
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é :/
18 juil. 2008 à 10:24
Juste un petit message pour dire que j'abonde totalement dans le sens de Webdeb.
On est encore libre (et heureusement ^^) d'utiliser l'extension mysql pour accéder à ses bases MySQL. Cependant, je suis parfaitement sur la même longueur d'onde quand il dit : "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."
J'entends aussi très bien Dsyann quand il dit : "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"
C'est une démarche louable que de vouloir partager ses connaissances avec les autres.
Cepedant, et c'est mon principal cheval de bataille ces temps-ci, il existe déjà tellement de sources de niveaux moyen à médiocre, que comme "exemple", il serait préférable que ce soit des sources de bonne qualité. J'entends par là des sources orientées objet (PHP5 quoi, il serait temps), qui respectent des design patterns tels que MVC (Modèle-Vue-Contrôleur), qui innovent dans la conception, etc (je ne prétends pas que cette source ne fait pas tout ça, je parle dans l'absolu)
Bon sinon, j'ai pas du tout regardé le code, donc je ne commenterai pas plus avant et ne mettrai pas de note ^^
18 juil. 2008 à 00:59
@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. :)
18 juil. 2008 à 00:31
je voudrais pas faire mon troll mais Webdeb quand tu dis que mysql_* est obsolète, tu y vas fort... mysql_ est simple et rapide, bien plus rapide que PDO et MySQLi. Pour avoir testé et benchmarké ces deux méthodes, j'en suis revenu (bon, je bossais sur un site à fort trafic aussi). La préparation des requêtes complexifie un peu le code et le rend moins lisible, et n'augmente que très peu les performances même en cas d'un grand nombre d'itérations. C'est sûr que c'est plus sécurisé, mais si on ne commet pas d'imprudence, je ne vois pas réellement de raison de laisser tomber les bonnes vieilles requêtes directes. à+
17 juil. 2008 à 23:19
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.
17 juil. 2008 à 22:36
1/ Tu réinventes la roue pour certaines pratiques (récupération d'extensions, formatage de date...) alors qu'il existe une foultitude de fonctions natives en PHP pour réaliser ces tâches facilement.
2/ Ce n'est pas optimisé du tout. Tu fais des SELECT * à gogo...
3/ Tu continues d'utiliser l'extension MySQL obsolète (fonctions mysql_*()) à l'aube de la mort de PHP 4. Tu ferais bien de te tourner vers MySQLi ou bien encore PDO pour accéder et manipuler tes BDD MySQL.
4/ Tu fais des duplications de variables inutiles du genre : $var = $_POST['var']. D'une part, ça ne sert à rien et d'autre part, tu ne filtres même pas ces données.
5/ Le code HTML généré ne respecte pas les standards W3C et WAI.
Bref, au final le travail est assez satisfait mais très loin d'être parfait et d'être mis en production finale sur un site critique... Je n'ai pas regardé du côté de la sécurité mais à mon avis, il doit y'avoir quelques failles de sécurité qui doivent trainé au vue du code.
++
17 juil. 2008 à 20:52
Pas de chemin absolu; En plus j viens de me rappeler que dans l'urgent je dois ajouter un lien profil pour les users.
17 juil. 2008 à 20:46
Ça pourrait être pas mal pour ceux qui veulent tester. ;)
Et ça me permettrait de comparer rapidement avec mon forum, sans avoir à regarder toutes les sources...