PHP c’est mal

cdaubedaubeçaylmal · Le 06/06/2012, à 06:11

J’ai tout bien écrit le titre sans faute

Y a pas que c‑daube‑daube qu’il est trop nul tout pourri, y a PHP aussi !

Tiens, de la lecture pour toi mon coupain :
PHP: a fractal of bad design

Encore au moins que c‑daube‑daube c’est tellement nul que tu peux toujours utiliser le C à la place, qu’il est plus prévisible au moins, mais avec PHP, tu faits quoi ?! Tu peux même pas faire quelque chose pour le remplacer

Ah si tu peux, tu fais tes CGI en Ada, à partir des spécifications du CGI, sa RFC :
RFC 3875: The Common Gateway Interface (CGI) Version 1.1

Ou alors FastCGI si tu as peur des overheads résultants de la création d’un nouveau processus à chaque requête comme c’est le cas avec le CGI. Mais FastCGI est plus délicat, dans le sens ou l’application doit être très soigneusement conçue, parce que si elle foire, c’est pas comme avec le CGI où la création d’un nouveau processus à la prochaine requêtre remettra les choses en place ; quand ça foire, ça foire pour les requêtes suivantes, à moins de le redémarrer :
FastCGI Specification version 1.0

Je ne connais pas de RFC pour FactCGI, je crois que le lien ci‑dessus est bien la spécification zofficielle.

Voilà mon coupain, tu sais tout

Dernière modification par cdaubedaubeçaylmal (Le 06/06/2012, à 08:14)

Hibou57 · Le 06/06/2012, à 10:22

Also of interest: Your Language Sucks (theory.org).

Langages décriés, plus ou moins sévèrement, dans ce document :

JavaScript sucks because…
PHP sucks because…
Perl 5 sucks because…
Python sucks because…
Ruby sucks because…
Action Script sucks because…
Scripting languages (in the large) sucks because…
C sucks because…
C++ sucks because…
C# sucks because…
Objective‑C sucks because…
Java sucks because…
XML sucks because…
XSLT/XPath sucks because…
CSS sucks because…

Par contre, concernant XML, ils ont fait une erreur ou alors ils n’ont pas compris ce qu’est XML :

Le document a écrit :

It is used for data interchange when it is really just a data encoding format.

Ben évidement, XML sans modèle de document, n’est qu’une forme de sérialisation, plus uniforme et plus simple que SGML sur lequel il repose.

Le document a écrit :

It confuses metadata and content.

Ce qui est normal, sans modèle de document.

Je n’ai pas tout lu, il y a peut‑être quelques autres erreurs dans le genre, cependant l’ensemble me semble raisonnablement honnête.

Dernière modification par Hibou57 (Le 06/06/2012, à 10:26)

Mathieu147 · Le 06/06/2012, à 12:35

cdaubedaubeçaylmal a écrit :

J’ai tout bien écrit le titre sans faute
Y a pas que c‑daube‑daube qu’il est trop nul tout pourri, y a PHP aussi !
Tiens, de la lecture pour toi mon coupain :
PHP: a fractal of bad design

J'ai pas tout lu parce que c'est suuuuuper loooonnnng mais je suis d'accord avec quasiment tout ce que j'ai lu. Bon, c'est sûr, l'auteur en rajoute un peu et dit que tous les programmeurs PHP sont des connards par exemple. Ce qui, en tant que programmeur PHP, je n'apprécie pas trop . Mais bon, c'est pas faux non plus ce qu'il dit techniquement sur le langage.

Ce qui est triste, c'est que PHP et Javascript sont deux langages que je n'aime pas, et en même temps ce sont (quasiment) les deux seuls langages que j'utilise . Bon, pour Javascript je n'ai pas trop le choix si je fais du développement web (quoique, il y a Cofee Script par exemple) et puis avec jQuery c'est quand-même moins pénible que le plain Javascript.

Mais PHP… pfiou, je m'en passerais bien… Mais ça fait 8 ans que je l'utilise donc j'ai appris à maîtriser quelques problèmes, j'ai un gros projet tout en PHP que je devrais traduire si je changeais de langage, et puis je n'ai pas vraiment le temps d'apprendre autre chose même si j'adorerais apprendre Python.

tshirtman · Le 06/06/2012, à 13:00

Si tu veux te mettre au web en python simplement, je conseille http://flask.pocoo.org/ qui est vraiment éléguant et sans prise de tête. Apres, pour des trucs plus complets, y'a django (on aime ou pas), pyramide, et pas mal d'autres, mais flask est le plus simple pour les petits projets que j'ai pu trouver…

@hiboux: je pense nécessaire d'informer que toi et le créateur du sujet avez la même IP, pour que personne ne soit dupe…

Dernière modification par tshirtman (Le 06/06/2012, à 13:04)

Mathieu147 · Le 06/06/2012, à 15:54

tshirtman a écrit :

Si tu veux te mettre au web en python simplement, je conseille http://flask.pocoo.org/ qui est vraiment éléguant et sans prise de tête. Apres, pour des trucs plus complets, y'a django (on aime ou pas), pyramide, et pas mal d'autres, mais flask est le plus simple pour les petits projets que j'ai pu trouver…

Si je me mets à Python, c'est pour un moyen projet. Ce n'est pas un truc énorme, c'est «juste» un CMS, mais il a déjà pas mal de fonctionnalités puisque je le développe depuis presque 3 ans.

Ce qui me gène le plus dans PHP, c'est que j'ai l'impression que ce n'est jamais clair, net et précis. C'est sûr qu'il y a des choses comme

"foo" == TRUE
"foo" == 0
TRUE != 0

(exemple pris du lien du premier post) qui font que, dans certains aspects, il y a des choses qui sont mal pensées dès le départ. Mais ce qui m'ennuie toujours, c'est que c'est plus ou moins orienté objet mais pas tout à fait. On ne peut pas déclarer ses variables sauf si elles sont globales, auquel cas on est obligés de les déclarer. On n'a pas accès à certaines fonctions de son propre code sans faire un include() mais on a accès à des fonctions de PHP où on a envie alors qu'on a rien include() du tout. La gestion des erreurs est naze, etc.

En fait, je trouve PHP imprécis et inconsistant.

Mais quand j'ai commencé à l'utiliser, je ne savais pas tout ça et je ne savais de toutes façons pas quoi d'autre je pourrais utiliser. Et puis voilà maintenant ça fait 3 ans que j'ai commencé un projet et je sais que je n'aurai sans doute pas le temps/courage de le réécrire en Python. Déjà que je l'ai écrit en utilisant un Framework qui, au départ, m'a permis de gagner beaucoup de temps, mais maintenant j'ai l'impression qu'il me gène plus qu'autre chose dans ma progression.

Je l'ai déjà dit à mes profs lorsque j'étais toujours à l'université, je l'ai déjà dit sur plusieurs forums dont celui-ci, mais je ne le répéterai jamais suffisamment : la chose la plus importante que j'aie appris lors de mes études (master en informatique) c'est que, avant de commencer, il faut bien réfléchir, envisager toutes les possibilités, mettre des idées sur papier, tenter d'anticiper le plus possible les problèmes qui pourraient survenir, et ensuite on choisit ses outils et puis on commence le code.

Malgré tout, cette phase de réflexion demande forcément un minimum d'expérience et de connaissance des outils existants, et on finit quand-même par se faire avoir un moment…

tshirtman a écrit :

@hiboux: je pense nécessaire d'informer que toi et le créateur du sujet avez la même IP, pour que personne ne soit dupe…

Arnaque!

tshirtman · Le 06/06/2012, à 16:14

J'avais lu entièrement ce lien il y a quelques temps, et je suis d'accord sur la plupart des points, PHP est bourré d'inconsistences, d'horreurs, et de pièges qui parfois punissent les bonnes pratiques, j'en ai fait pas mal de temps, et je ferait tout pour éviter d'en refaire (sauf, vraiment, pour des scripts monopage, seul endroit ou il a son utilité je pense, mais flask remplis presque aussi bien ce rôle je trouve).

Après, je comprends tout à fait que tu n'ai pas envie de jeter 3 ans de boulot, mais avec l'expérience et un meilleur framework, peut être arriverait tu as un résultat proche en quelques semaines ? Je pense que pour un CMS, django est sans doute très adapté, et beaucoup de gens l'utilisent pour ça… c'est simple, a partir du moment ou tu a décrit ton modèle (avec des classes qui te font l'adaptation vers ta bdd), tu as une interface d'admin, automatiquement…

Après, je doute que ton framework propose des choses comme ça http://vimeo.com/6640136

Hibou57 · Le 06/06/2012, à 18:32

tshirtman a écrit :

@hiboux: je pense nécessaire d'informer que toi et le créateur du sujet avez la même IP, pour que personne ne soit dupe…

Pour parler de dupe, il faudrait qu’il y ait préjudice par tromperie. Dupe de quoi ?

Mathieu147 a écrit :

tshirtman a écrit :
@hiboux: je pense nécessaire d'informer que toi et le créateur du sujet avez la même IP, pour que personne ne soit dupe…
Arnaque!

Ne t’inquiète pas, il n’y a pas arnaque, il n’a juste pas branché le décodeur.

Je repasserai plus tard pour donner mon avis sur la question, et pour pondérer une remarque.

Sinon une chose que j’adore dans cet article, c’est son titre, il est bien trouvé (“a fractal of bad design”).

Dernière modification par Hibou57 (Le 06/06/2012, à 18:34)

tshirtman · Le 06/06/2012, à 18:54

Ben si tu a un compte fantome pour faire croire que vous êtes deux a aimer l'ada, il y a tromperie, et si c'est pour faire croire qu'en faisant du cgi avec ada, les gens vont kiffer la life et se faire trop plaisir, j'estime qu'il y a fort risque de préjudice morale oui.

Dernière modification par tshirtman (Le 06/06/2012, à 18:55)

Mathieu147 · Le 07/06/2012, à 09:06

tshirtman a écrit :

Après, je comprends tout à fait que tu n'ai pas envie de jeter 3 ans de boulot, mais avec l'expérience et un meilleur framework, peut être arriverait tu as un résultat proche en quelques semaines ?

Oui c'est sûr qu'il ne me faudrait pas trois ans pour le refaire.

Plus j'attends avant de le réécrire et plus j'aurai du travail, mais plus j'attends et plus PHP m'ennuie. Donc en fait: plus j'attends et moins j'ai envie de le réécrire, mais plus j'attends et plus j'ai envie de le réécrire .

Et puis là je sais que je vais devoir faire à court terme une amélioration assez importante pour un de mes clients, et ça va encore ajouter pas mal de complexité lors de la refonte dans un autre langage. Mais en même temps, je ne peux pas faire cette modification en même temps que la réécriture, parce que les délais sont tels que je n'y arriverai jamais.

tshirtman a écrit :

Je pense que pour un CMS, django est sans doute très adapté, et beaucoup de gens l'utilisent pour ça… c'est simple, a partir du moment ou tu a décrit ton modèle (avec des classes qui te font l'adaptation vers ta bdd), tu as une interface d'admin, automatiquement…

Dans le framework que j'utilise (Jelix) il y a aussi des générations d'interface d'admin. En fait, ce sont des classes qu'on peut hériter (ça se dit «des classes qu'on peut hériter»? ça me paraît bizarre) et il suffit de renseigner 3 champs, copier/coller quelques fichiers et on a une interface d'admin.

Mais ça fait partie de ce qui m'ennuie avec les frameworks PHP de manière générale : tu as des choses qui sont prévues pour te faciliter la tâche, mais si tu sors un peu de ce qui a été prévu au départ ça te met des bâtons dans les roues.

Exemple: avec Jelix, tu fais des modèles de tes données dans un fichier XML. Avec ce fichier, tu peux définir des champs, des jointures, etc. Ça génère automatiquement une classe PHP à laquelle tu peux ajouter des méthodes. C'est le design pattern Factory qui est utilisé : le fichier XML est utilisé pour générer une factory que tu dois instancier, et sur laquelle tu appelles une méthode qui te retourne un Objet d'Accès aux Données (design pattern DAO) qui représente un enregistrement dans ta base de données. Ensuite tu peux le update() ou le delete() etc.

On sait assez facilement ajouter des méthodes à la factory, mais parfois on aimerait en ajouter aussi aux DAO. Donc en gros, le système te permet d'économiser du temps, d'avoir des modèles de données très simples et clairs dans des fichiers XML, etc. Mais en même temps, si tu veux faire quelque chose de non prévu par le framework, tu ne peux pas. Dans mon cas, j'ai bien été obligé de déporter une certaine logique d'une classe (le DAO) vers une autre (sa factory correspondante), et donc je me retrouve avec un code, certes fonctionnel, mais moins élégant.

Est-ce que Django est fort généraliste?

Et puis ça ajoute une couche de complexité supplémentaire: il faut parfois mettre à jour le framework lui-même.

tshirtman a écrit :

Après, je doute que ton framework propose des choses comme ça http://vimeo.com/6640136

En effet!

Hibou57 a écrit :

Mathieu147 a écrit :
tshirtman a écrit :
@hiboux: je pense nécessaire d'informer que toi et le créateur du sujet avez la même IP, pour que personne ne soit dupe…
Arnaque!
Ne t’inquiète pas, il n’y a pas arnaque, il n’a juste pas branché le décodeur.

Ah…

Hibou57 a écrit :

Sinon une chose que j’adore dans cet article, c’est son titre, il est bien trouvé (“a fractal of bad design”).

Effectivement, c'est bien trouvé. Il explique pourquoi il a choisi ce titre et je trouve que ça convient bien.

tshirtman · Le 07/06/2012, à 10:02

mathieu147 a écrit :

Et puis là je sais que je vais devoir faire à court terme une amélioration assez importante pour un de mes clients, et ça va encore ajouter pas mal de complexité lors de la refonte dans un autre langage. Mais en même temps, je ne peux pas faire cette modification en même temps que la réécriture, parce que les délais sont tels que je n'y arriverai jamais.

C'est sur, je pense que c'est mieux de commencer à regarder quand tu aura un peu de temps, faut pas non plus se précipiter, surtout si tu as des clients qui attendent.

Dans le framework que j'utilise (Jelix) il y a aussi des générations d'interface d'admin. En fait, ce sont des classes qu'on peut hériter (ça se dit «des classes qu'on peut hériter»? ça me paraît bizarre) et il suffit de renseigner 3 champs, copier/coller quelques fichiers et on a une interface d'admin.

« Des classes dont on peut hériter », je dirais.

Hum, c'est un bon début, sous django tu n'a rien a faire, c'est encore mieux mais c'est pas mal.

Mais ça fait partie de ce qui m'ennuie avec les frameworks PHP de manière générale : tu as des choses qui sont prévues pour te faciliter la tâche, mais si tu sors un peu de ce qui a été prévu au départ ça te met des bâtons dans les roues.

Les frameworks font souvent ça oui, plus ils apportent une infrastructure imbriquée, plus tu a intérêt a suivre les clous, et a ne pas faire de choix qui vont a l'encontre de ceux du framework, django est un peu comme ça, pyramide et flask sont bien plus souples, mais forcément, ils font moins à ta place.

Exemple: avec Jelix, tu fais des modèles de tes données dans un fichier XML. Avec ce fichier, tu peux définir des champs, des jointures, etc. Ça génère automatiquement une classe PHP à laquelle tu peux ajouter des méthodes. C'est le design pattern Factory qui est utilisé : le fichier XML est utilisé pour générer une factory que tu dois instancier, et sur laquelle tu appelles une méthode qui te retourne un Objet d'Accès aux Données (design pattern DAO) qui représente un enregistrement dans ta base de données. Ensuite tu peux le update() ou le delete() etc.
On sait assez facilement ajouter des méthodes à la factory, mais parfois on aimerait en ajouter aussi aux DAO. Donc en gros, le système te permet d'économiser du temps, d'avoir des modèles de données très simples et clairs dans des fichiers XML, etc. Mais en même temps, si tu veux faire quelque chose de non prévu par le framework, tu ne peux pas. Dans mon cas, j'ai bien été obligé de déporter une certaine logique d'une classe (le DAO) vers une autre (sa factory correspondante), et donc je me retrouve avec un code, certes fonctionnel, mais moins élégant.

C'est pour ça que j'aime pas trop les trucs générés, si tu ne peux pas tout décrire dans le format de base ou que tu ne peux pas patcher le générateur, tu te retrouve assez vite avec des bricolages immondes. Dans le monde python (django ou pour les autres avec l'orm SQLAlchemy en général), on écrit plutot directement les classes, avec des attributs qui sont des instances de type champ, jointure, etc, et tu les manipule comme des objets classiques, avec les méthodes pour faire des select et autre.

Est-ce que Django est fort généraliste?

Techniquement, j'ai assez peu d'expérience avec, mais il me semble que les gens l'utilisent pour un peu tout pour le web oui. Après, si tu veux un truc plus "boite à outil", pyramide est sans doute moins contraignant, et bien foutu aussi.

Pour django, cette vidéo (30mn, j'ai juste survolé ça a l'air bien), montre comment faire un blog basique en 30 minutes, bien sur un blog c'est plus simple qu'un CMS complet, mais tu vois l'idée ^^.
http://www.youtube.com/watch?feature=en … rHZoj3ASmk

Et puis ça ajoute une couche de complexité supplémentaire: il faut parfois mettre à jour le framework lui-même.

Oui, bien sur, c'est vrai que les libs peuvent beaucoup évoluer dans le temps, et compliquer les mises à jours, le mieux est d'avoir des tests unitaires pour savoir ce qui casse quand tu change quelque chose.

En effet!

pyramid et flask proposent le même genre de choses… et des debuggers pas à pas dans ta page web quand tu as un crash… ce genre de choses sympa… Je pense que les outils du monde python sont vraiment bien plus sérieux que ceux du monde php…

Dernière modification par tshirtman (Le 07/06/2012, à 10:04)

Mathieu147 · Le 07/06/2012, à 19:19

tshirtman a écrit :

mathieu147 a écrit :
Et puis là je sais que je vais devoir faire à court terme une amélioration assez importante pour un de mes clients, et ça va encore ajouter pas mal de complexité lors de la refonte dans un autre langage. Mais en même temps, je ne peux pas faire cette modification en même temps que la réécriture, parce que les délais sont tels que je n'y arriverai jamais.
C'est sur, je pense que c'est mieux de commencer à regarder quand tu aura un peu de temps, faut pas non plus se précipiter, surtout si tu as des clients qui attendent.

C'est clair. Habituellement pendant les vacances d'été le business est plus calme, j'aurai peut-être l'occasion.

tshirtman a écrit :

Dans le framework que j'utilise (Jelix) il y a aussi des générations d'interface d'admin. En fait, ce sont des classes qu'on peut hériter (ça se dit «des classes qu'on peut hériter»? ça me paraît bizarre) et il suffit de renseigner 3 champs, copier/coller quelques fichiers et on a une interface d'admin.
« Des classes dont on peut hériter », je dirais.

Ah oui ça paraît mieux.

tshirtman a écrit :

Hum, c'est un bon début, sous django tu n'a rien a faire, c'est encore mieux mais c'est pas mal.

De ce que j'ai pu voir lors de ma recherche intensive d'informations d'une durée approximative de 3 minutes, c'est vrai que la génération de panneau d'administration de Django a l'air top moumoute.

tshirtman a écrit :

Mais ça fait partie de ce qui m'ennuie avec les frameworks PHP de manière générale : tu as des choses qui sont prévues pour te faciliter la tâche, mais si tu sors un peu de ce qui a été prévu au départ ça te met des bâtons dans les roues.
Les frameworks font souvent ça oui, plus ils apportent une infrastructure imbriquée, plus tu a intérêt a suivre les clous, et a ne pas faire de choix qui vont a l'encontre de ceux du framework, django est un peu comme ça, pyramide et flask sont bien plus souples, mais forcément, ils font moins à ta place.

J'ai des modules dans mon CMS qui sont susceptibles d'entrer en conflit avec les fonctionnalités d'un quelconque framework. Par exemple, j'ai fait une gestion d'utilisateurs et groupes (avec lesquels on peut mettre des permissions sur les pages) ainsi qu'un module permettant de faire des formulaires. C'est le genre de choses qu'un framework fait, mais si je m'appuie de trop sur le framework en question, alors je serai peut-être bloqué. C'est pour ça d'ailleurs que mon module de formulaire n'utilise absolument pas la gestion des formulaires de Jelix. Mon module d'utilisateurs, lui, il s'appuie sur la gestion des utilisateurs de Jelix, mais uniquement pour les administrateurs du site, les simples visiteurs étant gérés par mon module.

C'est bête, les développeurs du framework ont prévu plein de choses pour faire des formulaires, avec vérification du remplissage etc. et moi je suis en train de tout réécrire. Et donc, quel est l'intérêt, finalement, d'utiliser un framework? Vu le nombre impressionnant de framework existant, que ce soit en PHP, en Python, en Ruby ou même en Javascript (je parle du côté serveur), on dirait que tout le monde s'est fait la même réflexion, et donc chacun utilise le framework qui a exactement les fonctionnalités qu'il cherche. Problèmes : comment peut-on les connaître tous? Comment peut-on être sûr que le framework conviendra toujours après plusieurs années d'utilisation?

Je serais plus attiré par un microframework qui apporte sans doute moins de fonctionnalités. Mais autant Django j'en ai déjà entendu parler souvent depuis longtemps, autant Flask et Pyramide je ne connaissais pas. Ce sont des projets récents et pérennes?

tshirtman a écrit :

Exemple: avec Jelix, tu fais des modèles de tes données dans un fichier XML. Avec ce fichier, tu peux définir des champs, des jointures, etc. Ça génère automatiquement une classe PHP à laquelle tu peux ajouter des méthodes. C'est le design pattern Factory qui est utilisé : le fichier XML est utilisé pour générer une factory que tu dois instancier, et sur laquelle tu appelles une méthode qui te retourne un Objet d'Accès aux Données (design pattern DAO) qui représente un enregistrement dans ta base de données. Ensuite tu peux le update() ou le delete() etc.
On sait assez facilement ajouter des méthodes à la factory, mais parfois on aimerait en ajouter aussi aux DAO. Donc en gros, le système te permet d'économiser du temps, d'avoir des modèles de données très simples et clairs dans des fichiers XML, etc. Mais en même temps, si tu veux faire quelque chose de non prévu par le framework, tu ne peux pas. Dans mon cas, j'ai bien été obligé de déporter une certaine logique d'une classe (le DAO) vers une autre (sa factory correspondante), et donc je me retrouve avec un code, certes fonctionnel, mais moins élégant.
C'est pour ça que j'aime pas trop les trucs générés, si tu ne peux pas tout décrire dans le format de base ou que tu ne peux pas patcher le générateur, tu te retrouve assez vite avec des bricolages immondes. Dans le monde python (django ou pour les autres avec l'orm SQLAlchemy en général), on écrit plutot directement les classes, avec des attributs qui sont des instances de type champ, jointure, etc, et tu les manipule comme des objets classiques, avec les méthodes pour faire des select et autre.

Pour un autre projet que j'avais commencé il y a ± 1 an (et qui a périclité malheureusement), le client voulait que je n'utilise pas de framework du tout, que je fasse du PHP pur (comme conseillé par Rasmus himself, soit dit en passant). Et c'est comme ça que j'avais commencé. Non seulement je n'avais pas envie de m'amuser à faire un générateur de code, mais de toutes façons je pensais que c'était la bonne chose à faire.

D'ailleurs, de ce point de vue là, la vision Jelixienne de l'interface d'admin n'est pas mauvaise : ils ont créé une classe qui contient déjà plein de méthodes utiles, et tu n'as qu'à en hériter pour faire ton interface. Ainsi, tu utilises les méthodes qui t'intéressent, tu redéfinis certaines si tu veux, et tu fais tout comme tu as envie.

Dans le système DAO de Jelix, on peut ajouter ce qu'on veut comme méthode en PHP, même si c'est du code généré à partir d'un fichier XML. Donc ça va quand-même. Mais comme je disais, cette méthode va dans la factory et non dans le Record.

tshirtman a écrit :

Est-ce que Django est fort généraliste?
Techniquement, j'ai assez peu d'expérience avec, mais il me semble que les gens l'utilisent pour un peu tout pour le web oui. Après, si tu veux un truc plus "boite à outil", pyramide est sans doute moins contraignant, et bien foutu aussi.

Je vais me renseigner là dessus aussi alors.

tshirtman a écrit :

Pour django, cette vidéo (30mn, j'ai juste survolé ça a l'air bien), montre comment faire un blog basique en 30 minutes, bien sur un blog c'est plus simple qu'un CMS complet, mais tu vois l'idée ^^.
http://www.youtube.com/watch?feature=en … rHZoj3ASmk

Je n'ai pas encore visionné, je regarderai ce soir ou demain, merci pour le lien.

tshirtman a écrit :

Et puis ça ajoute une couche de complexité supplémentaire: il faut parfois mettre à jour le framework lui-même.
Oui, bien sur, c'est vrai que les libs peuvent beaucoup évoluer dans le temps, et compliquer les mises à jours, le mieux est d'avoir des tests unitaires pour savoir ce qui casse quand tu change quelque chose.

Ouais, les tests unitaires… J'y pense tout le temps, mais je n'en fais jamais… Et puis comment on fait pour tester des interfaces avec des tests automatisés?

tshirtman a écrit :

En effet!
pyramid et flask proposent le même genre de choses… et des debuggers pas à pas dans ta page web quand tu as un crash… ce genre de choses sympa… Je pense que les outils du monde python sont vraiment bien plus sérieux que ceux du monde php…

Tout à l'heure en cherchant un peu je me suis rendu compte qu'on pouvait en fait faire ce genre de choses avec Jelix également, mais je n'ai pas approfondi, je ne sais pas si l'un ou l'autre est plus puissant.

tshirtman · Le 07/06/2012, à 20:12

Mathieu147 a écrit :

De ce que j'ai pu voir lors de ma recherche intensive d'informations d'une durée approximative de 3 minutes, c'est vrai que la génération de panneau d'administration de Django a l'air top moumoute.

C'est l'un des points fort de django, clairement, c'est tout bête, mais ça fait gagner beaucoup de temps apparement

J'ai des modules dans mon CMS qui sont susceptibles d'entrer en conflit avec les fonctionnalités d'un quelconque framework. Par exemple, j'ai fait une gestion d'utilisateurs et groupes (avec lesquels on peut mettre des permissions sur les pages) ainsi qu'un module permettant de faire des formulaires. C'est le genre de choses qu'un framework fait, mais si je m'appuie de trop sur le framework en question, alors je serai peut-être bloqué. C'est pour ça d'ailleurs que mon module de formulaire n'utilise absolument pas la gestion des formulaires de Jelix. Mon module d'utilisateurs, lui, il s'appuie sur la gestion des utilisateurs de Jelix, mais uniquement pour les administrateurs du site, les simples visiteurs étant gérés par mon module.
C'est bête, les développeurs du framework ont prévu plein de choses pour faire des formulaires, avec vérification du remplissage etc. et moi je suis en train de tout réécrire. Et donc, quel est l'intérêt, finalement, d'utiliser un framework? Vu le nombre impressionnant de framework existant, que ce soit en PHP, en Python, en Ruby ou même en Javascript (je parle du côté serveur), on dirait que tout le monde s'est fait la même réflexion, et donc chacun utilise le framework qui a exactement les fonctionnalités qu'il cherche. Problèmes : comment peut-on les connaître tous? Comment peut-on être sûr que le framework conviendra toujours après plusieurs années d'utilisation?

Oui, on ne peut pas tout connaitre et donc faire un choix totalement éclairé, c'est aussi pour ça qu'on ne détiens pas toujours la vérité ou la meilleur solution, on a juste une bonne solution pour nous . Pour le fait d'utiliser ou pas ce que propose ton framework, ça dépends de ton mode de pensée, si tu veux réutiliser au max et juste remplir les manques pour ton besoin, un truc comme django ou rails est sans doute indiqué, si tu aime plus construire ta propre archi, avec les outils autour de toi, je pense que flask ou pyramide sont plus indiqué (j'ai une préférence pour flask, que je trouve beaucoup plus simple a maîtriser).

Je serais plus attiré par un microframework qui apporte sans doute moins de fonctionnalités. Mais autant Django j'en ai déjà entendu parler souvent depuis longtemps, autant Flask et Pyramide je ne connaissais pas. Ce sont des projets récents et pérennes?

Flask est assez récent, et était à la base une blague de premier avril, mais devant le succès rencontré, l'auteur (loin d'être un débutant) c'est dis qu'il avait sans doute touché un point sensible, alors il a continué, en fait, flask est surtout un assemblage de plusieurs composants logiciel dont il est l'auteur (jinja2 et werkzeug par exemple) et qui sont reconnus pour leur qualité, c'est minimaliste, mais ça marche bien, et la profusion de libs dispos pour le reste (sqlalchemy, formalchemy…) fait que c'est une très bonne base pour développer son truc à la mains, sans ce soucier des détails trop bas niveau, ni être encombré par une architecture qui te dis ou mettre tes fichiers et tout. Oui je dirais que c'est pérennes, beaucoup de passionnés l'utilisent, et l'auteur est connus pour la qualité de ses produits.

Pyramide est plus ancien, en fait, c'est le descendant de Pylons, qui a fusionné avec un plus petit framework, repoz.bfg qui avait l'avantage d'être entièrement testé et documenté, bien foutu, y'a une communauté assez conséquente aussi, sans doute moins grosse que django, mais c'est connus dans le monde python…

Pour un autre projet que j'avais commencé il y a ± 1 an (et qui a périclité malheureusement), le client voulait que je n'utilise pas de framework du tout, que je fasse du PHP pur (comme conseillé par Rasmus himself, soit dit en passant). Et c'est comme ça que j'avais commencé. Non seulement je n'avais pas envie de m'amuser à faire un générateur de code, mais de toutes façons je pensais que c'était la bonne chose à faire.

Bon, je vais pas donner mon avis sur rasmus, mais sérieusement, quand on voit tout les soucis que traine le php et que seul un framework par dessus peut masquer (partiellement), faut vraiment être *** pour dire un truc pareil… ce mec est une catastrophe dans le monde du dev… (quand je pense que python faisait du web avant que php soit inventé… je suis vert, on s'est fait bouffer par des amateurs…)

Je vais me renseigner là dessus aussi alors.

(en fait, y'a trop de frameworks dans le monde python pour les essayer tous, je ne parle que de ce que je connais un peu).

Ouais, les tests unitaires… J'y pense tout le temps, mais je n'en fais jamais… Et puis comment on fait pour tester des interfaces avec des tests automatisés?

Oui, une maladie fréquente ça je suis aussi atteins… je pense que c'est dur de s'y mettre tout seul, faut bosser avec quelqu'un qui a l'habitude d'en faire.

Mathieu147 · Le 11/06/2012, à 12:14

tshirtman a écrit :

Mathieu147 a écrit :
De ce que j'ai pu voir lors de ma recherche intensive d'informations d'une durée approximative de 3 minutes, c'est vrai que la génération de panneau d'administration de Django a l'air top moumoute.
C'est l'un des points fort de django, clairement, c'est tout bête, mais ça fait gagner beaucoup de temps apparement

Ce que j'aime bien avec l'approche de Jelix, c'est que la création d'interface d'administration est assez simple dans le sens où tu hérites de classes qui ont des méthodes généralistes et bien pratiques, mais en gros tu fais quand-même ce que tu veux. Dans ce cas-ci, le framework ne se met pas en travers de ta route. Est-ce pareil avec Django?

tshirtman a écrit :

[..]les développeurs du framework ont prévu plein de choses pour faire des formulaires, avec vérification du remplissage etc. et moi je suis en train de tout réécrire. Et donc, quel est l'intérêt, finalement, d'utiliser un framework?[..]
[..]flask ou pyramide sont plus indiqué[..]
Je serais plus attiré par un microframework qui apporte sans doute moins de fonctionnalités. Mais autant Django j'en ai déjà entendu parler souvent depuis longtemps, autant Flask et Pyramide je ne connaissais pas. Ce sont des projets récents et pérennes?
Flask est assez récent [..] c'est minimaliste, mais ça marche bien, et la profusion de libs dispos pour le reste (sqlalchemy, formalchemy…) fait que c'est une très bonne base pour développer son truc à la mains, sans ce soucier des détails trop bas niveau, ni être encombré par une architecture qui te dis ou mettre tes fichiers et tout. Oui je dirais que c'est pérennes, beaucoup de passionnés l'utilisent, et l'auteur est connus pour la qualité de ses produits.
Pyramide est plus ancien, en fait, c'est le descendant de Pylons, qui a fusionné avec un plus petit framework, repoz.bfg qui avait l'avantage d'être entièrement testé et documenté, bien foutu, y'a une communauté assez conséquente aussi, sans doute moins grosse que django, mais c'est connus dans le monde python…

Je trouve que c'est quand-même chaud de devoir réécrire toute une application dans un autre framework dans un autre langage pour se rendre compte par la suite que ça n'a avancé à rien. Enfin, je trouve que la réécriture de code est souvent bonne parce qu'on a déjà une idée de l'ensemble et que ça permet de rattraper des erreurs qu'on aurait faites parce qu'on n'avait pas un cahier des charges bien précis au départ (il évolue sans cesse suite aux demandes de clients). Mais n'empêche que ça prend du temps et le but au final c'est quand-même d'y gagner plus que le temps que ça a pris.

tshirtman a écrit :

Bon, je vais pas donner mon avis sur rasmus, mais sérieusement, quand on voit tout les soucis que traine le php et que seul un framework par dessus peut masquer (partiellement), faut vraiment être *** pour dire un truc pareil… ce mec est une catastrophe dans le monde du dev… (quand je pense que python faisait du web avant que php soit inventé… je suis vert, on s'est fait bouffer par des amateurs…)

tshirtman a écrit :

Je vais me renseigner là dessus aussi alors.
(en fait, y'a trop de frameworks dans le monde python pour les essayer tous, je ne parle que de ce que je connais un peu).

En PHP aussi il y en a plein. Et dans les autres langages également. C'est vraiment dur de faire un choix.

tshirtman a écrit :

Ouais, les tests unitaires… J'y pense tout le temps, mais je n'en fais jamais… Et puis comment on fait pour tester des interfaces avec des tests automatisés?
Oui, une maladie fréquente ça je suis aussi atteins… je pense que c'est dur de s'y mettre tout seul, faut bosser avec quelqu'un qui a l'habitude d'en faire.

Ça fait partie des choses auxquelles j'aimerais me mettre. Mais si j'avais le temps de faire tout ce que j'ai envie, ça se saurait!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 06/06/2012, à 06:11

PHP c’est mal

#2 Le 06/06/2012, à 10:22

Re : PHP c’est mal

#3 Le 06/06/2012, à 12:35

Re : PHP c’est mal

#4 Le 06/06/2012, à 13:00

Re : PHP c’est mal

#5 Le 06/06/2012, à 15:54

Re : PHP c’est mal

#6 Le 06/06/2012, à 16:14

Re : PHP c’est mal

#7 Le 06/06/2012, à 18:32

Re : PHP c’est mal

#8 Le 06/06/2012, à 18:54

Re : PHP c’est mal

#9 Le 07/06/2012, à 09:06

Re : PHP c’est mal

#10 Le 07/06/2012, à 10:02

Re : PHP c’est mal

#11 Le 07/06/2012, à 19:19

Re : PHP c’est mal

#12 Le 07/06/2012, à 20:12

Re : PHP c’est mal

#13 Le 11/06/2012, à 12:14

Re : PHP c’est mal

Pied de page des forums