"Quoi ?? Un framework de plus ? Pas question !"
Lisez jusqu'au bout, il se pourrait que vous changiez d'avis.

Le problème

J'ai besoin d'une base de code solide sur laquelle construire des sites Web plutôt que de ré-inventer la roue à chaque fois. Des tas de concepteurs de sites sont dans le même cas que moi. Construisons une base de code commune (un framework) en rémunérant de bons développeurs pour le faire.

Le concept

• Le framework est puissant et flexible ; il doit pouvoir servir de base à n'importe quel type de site Web.
• Le framework s'adresse aux développeurs, pas aux utilisateurs finaux : il est constitué d'une série de classes/fonctions qui accélérent le développement. C'est Cake, ça n'est pas Joomla.
• Quelques fonctionnalités : gestion de l'identification et des permissions, URL propres, internationalisation, séparation du code et de la présentation (MVC), génération de HTML valide, gestion automatisée des formulaires (génération, validation...), tout élément du framework peut être "taggé" (module de taxonomie)...

La technique

• PHP/MySQL.
• Uniquement du PHP 5 orienté objet.
• Respect des bonnes pratiques de codage.

Quel intérêt ?

• Le framework est open-source, tout le monde pourra l'utiliser.
• Le framework est sponsorisé par les utilisateurs ou sociétés qui aimeraient l'utiliser (les développeurs toucheraient une "prime" pour chaque classe/module développé). En contrepartie, chaque sponsor participe à l'élaboration du framework.
• Pour un développeur PHP : apprendre, augmenter ses compétences, partager ses connaissances, valoriser son profil.
• On cause en français (la plupart des frameworks sont en anglais).

Attention, ce message n'est pas de la pub ni une offre d'emploi déguisée. Je ne fais que m'interroger sur la validité d'un tel modèle (sponsoriser l'open-source pour le rendre plus efficace).

Et vous, qu'en pensez-vous ?

Je suis tenté de dire quand même "Quoi, encore un framework ?"

D'abord il en existe déjà pas mal en général open-source aussi, Un des derniers qui soit sorti avec les mêmes objectifs est Prado. J'ai visité, vaguement testé 5mn le temps de voir que ça générait un XHTML avec des balises HTML des plus fantaisistes, pas transcendant. Et puis depuis l'automne dernier, il y a eu pas mal de bruit autour d'un projet en cours de montage piloté par Zend : on attend toujours, mais si on tient compte des objectifs visés et des partenaires du projet (Je ne citera que IBM, mais ce ne sont pas tout à fait les premiers venus), je me dis qu'on a des chances de voir aboutir ce projet sur un ensemble des plus efficaces.

Alors pourquoi vouloir en faire un autre. Le truc qui m'attirerait dans l'histoire, ce serait qu'on impose un codage en français, des commentaires en français et qu'on fait ça pour des francophones : après tout les anglophones ont largement de quoi s'occuper et si notre projet les intéresse, ils feront comme nous, il travailleront en traduisant comme on fait nous-même quand on utilise ce qu'ils font.

L'autre point qui pourrait m'intéresser, c'est l'organisation de la structure de développement : où ça a de l'allure, y participent des gens qui maîtrisent à fond leur sujet et certains savent organiser et découper les modules à développer, ou c'est une bande de doux dingues qui passent leur nuits et leurs jours sur leur clavier à bouffer du code, mais organisent ça à la perche : dans le second cas, ça ne m'intéresse même pas de regarder du tout le projet.

Voilà. Je reste ouvert, je dispose d'un peu de temps et je ne suis pas totalement pourri en PHP même si je ne suis vraiment pas un gourou de la POO; reste à trouver les arguments pour me convaincre. À la limite, le fric je m'en cogne : si on sort un framework qui est bien fait et me permet d'être plus efficace, je ne serai pas le dernier à m'en servir et en fin de compte c'est à l'utilisation que je gagnerai de l'argent.

Hello Cyrano,

Je suis content de voir que quelques points trouvent un écho en toi.

Tt à fait d'accord avec toi sur le Zend Framework. Son seul problème : il n'existe pas encore. Et d'ici là, je pense avoir une paire de sites à développer.

Je te rejoins aussi sur le fait que le fric n'est peut-être pas le plus important. Après tout, ça pourrait même entraîner des dérives : certains développeurs ne seraient dedans que pour le fric, et ne partageraient pas les valeurs premières du projet.

En y réfléchissant mieux, je crois que ce qu'il faut, plus que du fric, c'est un "leader", une personne ou un groupe de personnes avec une vision super claire qui donne une couleur unique, une direction et un dynamisme au projet. Il semblerait que dans l'open-source, les projets derrière lesquels on trouve une société commerciale comme leader s'en sortent plutôt bien (Zend est un bon exemple, je pense aussi au CMS eZ Publish).

En tt cas, merci de ta réponse. Je te tiendrai au courant (si suite il y a).

Salut,

Le principal problème quand on veut utiliser un framework est le temps nécessaire de compréhension du cadre pour pouvoir être productif. De plus, la plupart des frameworks regroupent l'essentiel de ce que l'on recherche pour accélérer ses développements modulo une ou 2 choses qui fait que le framework ne nous convient pas parfaitement.

C'est pourquoi je ne pense pas qu'il existe UN framework universel qui convienne à la majorité des développeurs, qu'il soit ou non développé par Zend...

Tout ce que tu proposes fait partie de la plupart des frameworks à la mode en ce moment, si ce n'est les commentaires en français; auquel cas je te renvoie vers Copix : http://www.copix.org/index.php/cms/7/Fr ... tedMenu=10

Les principaux avantages à développer son propre framework sont donc:
- connaître parfaitement le coeur du framework
- avoir toutes les "fonctionnalités" que l'on désire

Mais ce que tu conçois être quelque chose d'utile peut ne pas l'être pour un autre développeur, donc l'intérêt d'un tel framework "communautaire" est plutpot restreint.

Néanmoins, je te souhaite bon courage pour ce projet!

Bonsoir,

Personnellement j'ai jamais compris pourquoi il n'existe pas en PHP une sorte d'API pour les développeurs comme en JAVA.

Certains me diront qu'il existe PEAR. Certe, mais encore personnellement je trouve sont utilisation fastidieuse. Les classes développées le sont en POO, mais malheureusement une fois en PHP4, une fois en PHP5. La documentation est loin d'être facile à appréhender, c'est même fouilli. Toujours en comparaison avec JAVA, je ne suis pas un AS en anglais mais j'arrive à trouver ce que je cherche dans la JAVADOC.
Avec PEAR on a beau trouver la classe principale, après la description des méthodes, la plupart du temps c'est du fouilli.

Bref pourquoi ne pas développer un API PHP5 (vu que le modèle objet est maintenant au point) en anglais, qui pourrait être traduit en français et dans d'autres langues par la suite. Cet API regroupant des classes sur lesquels des développeurs web se sont mis d'accord sur leurs utilitées.
Voir même créer une fonction php du genre "import()" qui permettrait d'inclure uniquement des packages, classes, de l'API.

Voir même permettre dans le PHP INI d'utiliser un API spécifique à partir de la fonction import...

Ce shéma est assez similaire à PEAR mais malheureusement, je penses que PEAR souffre du fait d'avoir été créé trop tôt. Le mélange de PHP4 avec un modèle objet "limité" et celui de PHP5 pose problème.

Après pourquoi pas développer un framework, malheureusement une fois de plus je penses que c'est réinventer la roue pour "pas grand chose".

Bref ma réaction est peut être débile pour certains. Après tout on va pas refaire le monde... mais bon j'avais envie de m'exprimer sur ce point.

@+

En fait Ouaibou, je ne suis pas certain complètement de ce que je vais dire, mais il me semble que c'est un peu la philosophie qui encadre le développement du Zend framework : c'est pour ça que personnellement, je me fais pas de bile. C'est pas encore disponible, alors on va attendre.

PEAR est sans doute très bien pour les habitués, mais personnellement, je trouve ça imbuvable. Et tant qu'à développer quelque chose, je ne le ferai certainement pas en anglais, j'ai expliqué plus haut pourquoi.

PEAR est sans doute très bien pour les habitués, mais personnellement, je trouve ça imbuvable.

Comme tu dis Cyrano, il faut être habitué pour pouvoir utiliser PEAR.
Utiliser une classe, c'est normalement pouvoir faire abstraction de l'implémentation de celle. Une simple documentation bien faite devrait permettre de comprendre l'utilité de telle ou telle méthode sans se plonger dans son code. Malheureusement ce n'est pas le cas de PEAR.

Je ne suis pas certain complètement de ce que je vais dire, mais il me semble que c'est un peu la philosophie qui encadre le développement du Zend framework

J'étais pas au courant pour le framework Zend. J'ai hâte de voir ce que cela va donner.

@+

C'est pourquoi je ne pense pas qu'il existe UN framework universel qui convienne à la majorité des développeurs, qu'il soit ou non développé par Zend...

Je m'avance peut-être un peu (car je connais pas), mais n'est-ce pas le cas de la plate-forme .NET de Microsoft ? Un framework unique, avec qui plus est un environnement de programmation unique, et des wizzards qui automatisent tout un tas de tâches répétitives ? Franchement, le jour où on aura ça en PHP, ça sera top !

Personnellement, j'adore PHP, mais je pense qu'il y a un énorme progrès à faire en terme de "best practices", standardisation de la façon de coder, architecture du code... Le problème aujourd'hui, c'est que le PHP est trop permissif => il est ce que le développeur en fera. Bon développeur = Bon code. Mauvais développeur = mauvais code.

Un framework permet d'unifier tout ça et aide à faire respecter les best practices. Bien sûr, il reste tjours possible avec un peu de bonne volonté de faire du code pourris mais c'est plus dur.

Mais ce que tu conçois être quelque chose d'utile peut ne pas l'être pour un autre développeur, donc l'intérêt d'un tel framework "communautaire" est plutpot restreint.

Je ne crois pas, non. Je fais allusion aux couches basses du framework : celles qui sont incontournables à toute application web (la génération de l'affichage de la page, l'identification, le parcours d'une table ds la BDD...). Bien sûr, ensuite chaque développeur a des besoins spécifiques, et il construit alors son propre code, modules, plugins...

Néanmoins, je te souhaite bon courage pour ce projet!

Merci rami. Cela dit, c'est pas vraiment un projet, disons plutôt que je tâte le terrain (et il est plutôt mou le terrain).

A propos de PEAR : Tout à fait d'accord avec vos remarques.

Plus d'infos sur le Zend Framework : site de Zend ou ici.

PS. Merci pour le lien Copix, j'avais jamais entendu parler. En effet, toute ressemblance avec un framework actuel ou ayant existé...

Contrairement à vous, j'use (voire abuse?) de PEAR pour diminuer (simplifier?) mes développements. Il constitue, à mon sens, un framework applicatif assez puissant. Il existe notamment des packages du genre Datagrid, Creole, les packages pat ( http://www.php-tools.net/ ) qui permetten de s'approcher des composants .NET tout en gardant la main sur le code généré.

Les frameworks actuels imposent souvent des choix qui peuvent nous paraître contestables (le moteur de templates, le choix de la couche d'abastraction des données...) alors que PEAR fournit un "stock" de composants plus ou mons faciles à aborder je le concède. Mais, passer une semaine à appréhender un framework complet est certainement plus long que de passer quelques heures tout au plus à apprivoiser un package PEAR.

Ca ne reste que mon simple avis, mais sans être la panacée, PEAR peut constituer le couteau suisse du développeur PHP

Je reste tout de même attentif à ce que va donner le framework de Zend, si jamais il voit le jour ( ) car il pourrait en effet permettre de fédérer un grand nombre de développeurs.

Je vais essayer d'être concis pour éviter de polluer le thread, voici quelques réflexions:

• "Quoi ?? Un framework de plus ? Pas question !" - ah, mince, ça a déjà été dit
• perso, je hais PEAR pour avoir adopté le formatting style le plus immonde de l'histoire de la programmation, et ne pas forcer ses développeur à adopter E_STRICT. Mais cela n'engage que moi. D'un autre côté, vous pouvez utiliser l'installer PEAR sans pour autant utiliser PEAR (certains logiciels peuvent s'installer par PEAR sans pour autant en faire réellement partie, ce qui est drôlement pratique je dois dire)
• le Zend Framework est né en Israël, mais vu l'ambiance de sauna qui règne autour de ce projet j'aurais presque l'impression qu'il vient du pays du saumon
• je n'aime pas les logiciels en français. Pour moi, la seule langue que l'on devrait voir apparaître dans un projet collaboratif est l'anglais. Je ne sais pas à quel point tu voudrais franciser ce framework, mais garde à l'esprit que tous les termes techniques n'existent pas forcément en français, ou que leur emploi peut être désuet
• One size does not fit all. C'est pour cela que l'on voit autant de projets de framework se créer, tout le monde a sa propre idée sur la direction à prendre. Si ce projet devait se monter, veille à ce que vos avis soient compatibles

Au fait, quels sont les frameworks que vous avez déjà essayé ? Peut-être y a-t'il là dehors un super-framework que l'on ne connaitrait pas ?

PS: j'ai mis les passages les plus subjectifs en italique

je n'aime pas les logiciels en français. Pour moi, la seule langue que l'on devrait voir apparaître dans un projet collaboratif est l'anglais. Je ne sais pas à quel point tu voudrais franciser ce framework, mais garde à l'esprit que tous les termes techniques n'existent pas forcément en français, ou que leur emploi peut être désuet

Je te rejoins tout à fait. Ma proposition initiale parle de "causer en français" et elle a été reprise comme "coder en français". Je faisais en fait référence aux discussions autour du projet. Sinon je pense comme toi que le code, les commentaires et la documentation devraient être en anglais.

One size does not fit all. C'est pour cela que l'on voit autant de projets de framework se créer, tout le monde a sa propre idée sur la direction à prendre.

Ok, mais je reste persuadé que les briques de bases devraient être les mêmes pour tout le monde, comme un jeu de lego. Après, chacun construira ce qu'il voudra avec.

Au fait, quels sont les frameworks que vous avez déjà essayé ? Peut-être y a-t'il là dehors un super-framework que l'on ne connaitrait pas ?

Oui, ça serait bien. De mon côté, je n'ai jamais utilisé de framework, toujours développé les miens. En revanche, il m'arrive de jeter un oeil au code de certains frameworks pour voir comment ils font ci ou ça.

Pour info, une liste de frameworks PHP est disponible ici :
http://dmoz.org/Computers/Programming/L ... rameworks/

...Pour moi, la seule langue que l'on devrait voir apparaître dans un projet collaboratif est l'anglais. Je ne sais pas à quel point tu voudrais franciser ce framework, mais garde à l'esprit que tous les termes techniques n'existent pas forcément en français, ou que leur emploi peut être désuet...

.........
PS: j'ai mis les passages les plus subjectifs en italique

Heureusement que tu le précises : je trouve ce type de raisonnement complètement incohérent et surtout inadmissible. Il y a déjà eu des débats sur le sujet ici et on ne relancera pas une polémique de plus. Mais ceci dit, je refuse catégoriquement de me soumettre à cette espèce de monopole linguistique anglophone.

Les langages ont été développés en anglais ? D'accord. Et alors, ça change quoi ? Qu'on ait besoin de connaître langlais pour pouvoir lire la documentation, je suis d'accord. Mais programmer en commentant en (mauvais ?) anglais et en prenant soin de nommer les fonction et/ou les variables avec des mots anglais, je trouve que c'est un manque total d'imagination d'abord et illogique. Comme l'avait un jour souligné Naholyr à l'occasion d'un précédent débat sur le sujet, quel pourcentage de développeurs français travaillent sur des projets internationaux ? Trois fois rien. Rien ne justifie l'emploi de l'anglais en programmation tous langages confondus.

En reprenant une application, je veux pouvoir l'interpréter rapidement sans devoir me faire suer à commencer par la traduire. Désolé, mais ma langue maternelle, c'est le français et je crois que c'est une langue suffisament riche pour qu'on trouve des termes explicites afin de décrire clairement ce qui doit l'être. Et comme je l'ai mentionné plus haut, si un projet sur lequel je travaille intéresse des anglophones parce que les fonctionalités leur paraissent dignes d'intérêt, ils feront ce que je fais moi-même quand j'ai besoin de quelque chose qu'ils ont eux-même développé : ils traduiront. Point barre.

Je m'inscris en faux sur ces accusations: incohérent ? au contraire (en anglais dans le texte). Je suis pour un développement en anglais pour les mêmes raisons que je suis contre la profusion de frameworks et autres projets de forums: inutile de réinventer la roue. On ne va pas traduire un vocabulaire de plusieurs centaines de mots à chaque nouveauté ? lorsque les mots existent il n'y a pas de problèmes ("requête", "fonction"), mais que faire dans le cas contraire ? dois-t'on parler de graticiel, cédérom, cadre d'application ?

Dans un projet collaboratif, le plus important est la communication. Sans un protocole clair et précis il n'y a pas de communication, et je ne considère pas le vocabulaire technique français comme étant clair et précis. get_input() != obtenir_saisie_utilisateur()

Je vais rechercher sur le babillard le sujet dont tu parles pour voir s'il vaut la peine d'être déterré.

PS: la France ne semble pas être dôtée d'un site toile faisant autorité en la matière, donc j'ai consulté le Grand dictionnaire terminologique de l'Office québécois de la langue française pour franciser certains termes

Le débat de la langue est un peu hors-topic par rapport au thread initial (à nouveau, je n'ai jamais proposé de coder en français) et apparemment, il a déjà eu lieu ailleurs, mais je voulais juste partager mon expérience.

En tant que développeur, l'essentiel des ressources que j'utilise pour mon travail sont en anglais (bouquins, magazines, classes/frameworks/CMS, forums, sites de référence...).

Pourquoi ?

Parce qu'il y a plus de ressources, et dans le tas, plus de bonne qualité. Parce que l'info est plus récente (l'anglais est souvent la langue de départ ; quand une traduction existe, elle arrive souvent après et sa qualité n'est pas toujours garantie). Ainsi, même quand ça existe en français (par exemple la doc en ligne de PHP), j'utilise la version anglaise.

Mais pourquoi, ôôô pourquoi ?

Parce c'est plus simple (pour moi). Puisque je "bouffe" de l'anglais à longueur de journée, c'est juste plus facile et plus logique de travailler en anglais. C'est de coder en français qui me demanderait un effort (tu t'imagines retraduire une classe complète que t'as chopée sur le net juste pour qu'elle colle à la langue de ton projet ?).

En plus, imposer le français dans le code, c'est un peu contraire à l'esprit du net. Tu (Cyrano) sais pertinemment que tu toucheras moins de gens avec du tout-français. Quand tu dis "ils n'ont qu'à traduire", tu te doutes bien que ça n'arrivera pas tt simplement parce que le nb de gens comprenant le français est bien inférieur au nb de gens comprenant l'anglais.

Maintenant, tu peux vouloir ne toucher que les francophones. Dans ce cas, c'est ton choix.

Tu peux aussi vouloir rendre une ressource accessible aux francophones, et là, je ne peux que t'approuver. Pour reprendre la question qui nous pré-occupe (la création d'un framework), j'adhère à 100% à l'idée d'avoir un site communautaire en français sur le framework, avec doc en français, tutoriels en français, forums en français... Mais le code (et les commentaires et la doc du code proprement dit) devraient être en anglais (juste mon avis). Personnellement, mon code est en anglais, même si je ne produis que des sites en français. Prends l'exemple de PHP (et de nombreux autres langages de prog) : il est conçu en anglais et propose aussi de nombreuses ressources en français, ça fonctionne très bien.

Enfin, et je dis ça sans aucun mépris, il y a une question de niveau (en anglais). Coder en anglais implique de se débrouiller en anglais, et je conçois bien que ce n'est pas le cas de tout le monde.

Cyrano : Je comprends et je partage ton attachement au français en général. Mais j'ai l'impression que ta position relève plus d'une question de principe que de considérations pratiques.

Sans un protocole clair et précis il n'y a pas de communication, et je ne considère pas le vocabulaire technique français comme étant clair et précis. get_input() != obtenir_saisie_utilisateur()

Mais absolument pas : D'abord rien n'interdit l'élaboration d'un protocole clair et précis en français : Le français n'est pas une langue d'amateurs, c'est une langue largement aussi riche et précise que l'anglais si nécessaire, il faut juste avoir un peu plus de 200 mots de vocabulaire. Qu'on utilise certains termes occasionnellement en anglais parce qu'ils sont plus ou moins passés dans les moeurs des développeur, à la rigueur je peux le comprendre, mais développer à 100% en anglais, j'y suis vigoureusement opposé.

Selon l'exemple que tu montre, la différence, c'est la longueur du terme utilisé : où est donc le problème ? D'autant que l'exemple est faux : si on veut traduire convenablement, ce serait :
- soit : get_user_input() == obtenir_saisie_utilisateur()
- soit : get_input() == obtenir_saisie()

Or ça pose un autre problème de perspective : on sait que le langage lui-même est élaboré en anglais. On sait d'autre part que certains mots sont réservés pour le langage: il n'y a absolument rien qui indique que dans un avenir plus ou moins proche le terme "get_input" ne sera pas ajouté aux mots réservés: tu feras quoi dans ce cas-là ? Tu devras te farcir de parcourir toute ton application pour corriger ton code à cause d'un conflit, chose qui n'aura pas lieu si tu utilises obtenir_saisie : Selon la taille de ton application, ça peut te prendre pas mal de temps de faire le tour, temps qui ne sera en aucun cas rentable.