À propos des frameworks [sujet sérieux]

Bonjour à tous,

Le forum d'Alsacréations n'est pas consacré au développement à proprement parler (mais plus à l'intégration avec les standards et, à l'occasion, à la prise en compte de l'accessibilité numérique). On y parle cependant de temps à autre de sujets mixtes, comme par exemple les CMS (systèmes de gestion de contenus).

Par contre, il me semble qu'il n'y a aucune discussion un peu sérieuse sur les frameworks.

Un framework, kézako
Connaissant mal le sujet, je ne peux que vous recopier une partie de l'article de Wikipédia :

a écrit :
Un framework est un espace de travail modulaire. C'est un ensemble de bibliothèques et de conventions permettant le développement rapide d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres (...).

Des tentatives de francisation du terme ont été faites. On trouve ainsi parfois les termes cadre d'applications, proposé par l'Office québécois de la langue française, ou cadriciel.

Un framework fournit un ensemble de fonctions facilitant la création de tout ou d'une partie d'un système logiciel, ainsi qu'un guide architectural en partitionnant le domaine visé en modules.

Les frameworks pour le web
Je propose que nous laissions de côté les frameworks applicatifs et l'aspect « développement d'application » (internet, extranet, intranet...), pour nous concentrer sur l'aspect « création d'un site web dynamique ».

Ce sujet est un appel à contribution adressé à ceux qui sont familiers de ces outils, afin qu'ils puissent nous les présenter. Surtout, il s'agirait de répondre aux questions suivantes :

1 - niveau nécessaire à la prise en main : développeur-gourou, développeur-débutant, technicien du web (par exemple intégrateur) peu versé en développement, profane... ;
2 - types de sites réalisables, possibilités, limites ;
3 - hébergement (possible sur du mutualisé généraliste -- et si oui sur un hébergement modeste ou relativement confortable -- ? nécessite un hébergement spécifique ? ou carrément un serveur dédié ?)
4 - difficulté d'installation et de prise en main.

Alsacréations rassemble sans doute quelques développeurs de formation ou par passion, mais aussi et surtout beaucoup d'intégrateurs, graphistes, eet de personnes débutant ou vaguement initiées en développement. Pour ces derniers, les frameworks sont-ils une piste à explorer au même titre que les CMS et le développement « à la main » de sites techniquement simples en PHP (ou autre) ?

Voilà, à vos claviers !

Pour rappel, et bien que ce sujet soit lancé un vendredÿ, ce sujet est sérieux et les trolls n'y seront pas tolérés. Merci d'argumenter votre point de vue, et de préférer l'apport d'informations et de votre point de vue à la polémique.

Pour les trolls, il y a un sujet dédié aux trolls sur les frameworks.

Dans le cas d'un site web dynamique, on a 3 choix :
- Ecrire une application de 0. Long, fastidieux, exploseur de délais.
- Utiliser un CMS. Le CMS a l'avantage d'être complètement fonctionnel dès son installation et il ne reste que l'intégration à faire. Si les fonctionnalités viennent à être modifiées ou étendues, on peu l'étendre par le biais de plugins. Par contre la modification d'une partie existante est plus laborieuse.
- Utiliser un Framework. A l'installation un framework ne fait rien. Seules les fondations sont là, il reste à contruire l'application. L'avantage par rapport à un développement de 0 est ce qui est systématique (appels à la base de données notamment) est complètement automatisé. On peut se concentrer uniquement sur la demande client et ce qui est spécifique à l'application. Le reste est déjà là.
Modifié par Lanza (29 Jun 2007 - 12:07)

Bonjour à vous

Merci pour cette bonne idée

Si vous pouviez aussi, dans vos réponses, s'il vous plait citer des frameworks, y en a-t"il qui sont dédiés à telle ou telle autre application ? Peut on parler de qualités différentes pour ces outils ?

Merci d'avance

Je vais zessayer de répondre aux questions posées. Le framework que je connais le mieux étant Ruby on Rails. Encore qu'ASP.Net est également un framework , mais d'un autre genre.

1 - niveau nécessaire à la prise en main :
Pour Ruby on Rails : je dirais soit débutant, soit bien initié. Le frein ici est le langage Ruby, qui est assez différent des langages habituels. Du coup, il n'est pas évident à appréhender quand on a l'habitude de PHP, ou de Java par exemple.
Ruby est plus proche de javascript que de PHP au niveau du fonctionnement, même si javascript ressemble plus au niveau de la syntaxe à PHP. Par contre si on débute en programmation, on peut éventuellement commencer par Ruby.
Pour les framework PHP : c'est utilisable même avec un niveau pas très élevé.

2 - types de sites réalisables.
Tous. Sinon, ce n'est plus un framework c'est un CMS, et il n'y a pas vraiment de limites. L'apport d'un framework comme Ruby on Rails est justement d'avoir réussi à dégager ce qui était répétitif lors de la création d'un site, et de laisser libre ce qui est spécifique à chacun.

3 - hébergement
Pour Ruby on Rails, c'est le point faible. Les offres mutualisées sont rares, même si OVH parlait de l'offrir, on n'a toujours pas de nouvelles. Il faut une installation spécifique (ruby + apache et fastcgi par exemple). Dédié conseillé, même si on peut trouver des offres spécifiques à l'étranger.

Pour les framework PHP, vérifier que son hébergement supporte PHP5 et la réécriture d'url. La réécriture est obligatoire, parce que les frameworks MVC (Modèle Vue Contrôlleur), comme Rails et ses clones PHP, ne fonctionne pas sur le principe une URL = un script, mais une URL déclenche une action qui renverra une ressource.

4 - Difficulté d'installation et de prise en main.
4.1 Installation
Pour Rails : Ça dépend d'où on part. Si on prend un serveur dédié et qu'on fait toute l'installation, ça peut être laborieux; si on utilise un hébergement Rails, ça va tout de suite mieux. L'installation sur la machine est plus facile. Il faut cepandant au préalable installer Ruby, et Rubygems et un moteur de bases de données (MySQL, etc). Il y a un serveur de test intégré, donc pas besoin de configurer quoi que ce soit à ce niveau.

Pour un framework PHP : c'est presque plus simple qu'un CMS. On télécharge, et voilà, on peut commencer à bosser. Peut-être une modif à faire dans le .htaccess. Pour le lancer sur sa machine de test, le classique easyphp peut faire l'affaire.

4.2 Prise en main
Les framework dont il est question fonctionnent plus ou moins tous sur le même modèle (Modèle Vue Controlleur) donc une fois qu'on a compris ce principe et qu'on maïtrise le langage utilisé, ça roule tout seul. Le plus difficile à comprendre, je pense, c'est vraiment qu'une URL ne correspond pas à un fichier physique, mais va être transmise à un contrôleur qui va la traiter.

En ce qui concerne la possibilité de prise en main par les intégrateurs, c'est plus délicat comme question. S'ils sont dans une équipe qui compte un développeur, il peuvent ne toucher qu'aux vues et aux feuilles de style, ce qui est assez aisé, même sans maîtriser complètement le langage.
S'ils sont seuls, et qu'ils ont besoin d'un développement spécifique, je pense qu'un framework peut être une bonne idée également. Même si l'investissement initial en temps est peut-être plus lourd, l'abstraction des accès à la base de données est une sacrée charge en moins, et les choix d'architecture qui sont fait aident à une programmation plus propre que le code spaghetti typique du débutant.

Mais si un CMS existe et qu'il remplit les besoin, un intégrateur qui ne souhaite pas acquérir des compétences de développeur aura tout intérêt à l'utiliser.

dominique a écrit :
Bonjour à vous

Merci pour cette bonne idée

Si vous pouviez aussi, dans vos réponses, s'il vous plait citer des frameworks, y en a-t"il qui sont dédiés à telle ou telle autre application ? Peut on parler de qualités différentes pour ces outils ?

Merci d'avance

Alors il y a Ruby on Rails
En python, il y a Django. L'avantage de ces deux là, c'est qu'ils tirent parti des spécificités de leur langage pour simplifier au maximum tout ce qui peut l'être.

Ensuite il y a les émules en PHP :
CakePHP qui est ni plus ni moins qu'un clone de Rails en PHP. Il est cependant moins agréable à utiliser, puisque PHP n'étant pas Ruby ni python, certaines choses ne peuvent pas être automatisées, et le code à produire est plus long.

Et il y a ceux que je connais moins, mais qui sont basés sur le même principe : le Zend Framework,
Symfony qui si je me rappelle bien fait des entorses au modèle MVC, Code Igniter, Jelix, PHP on Trax et quelques autres.

A noter qu'ASP.Net est également un framework pour le Web, mais ne fonctionne pas sur le modèle MVC. Pour l'avoir pratiqué pendant 2 ans, je suis tenté de le déconseiller. Même s'il c'est un framework très puissant intégré à la plateforme .Net, il a à mon avis un défaut majeur : il tente de rendre la programmation Web la plus proche possible de celle d'une application de bureau classique, et de ce fait tend rapidement vers l'usine à Gaz et s'éloigne des bonnes pratiques. Pour exemple, un document ASP.Net s'appelle par défaut Webform, ce qui suppose que c'est un formulaire dès le départ, et de fait, Visual Studio inclut un formulaire par défaut dans le code. A réserver au grosses applications web/intranet/extranet greffée sur une application .Net, et encore...

En ce qui concerne la qualité, oui, il y a des différences, à plusieurs niveaux, et le choix va dépendre de ces facteurs :
- Certains frameworks ne respectent pas complètement le modèle MVC, ce qui risque d'inviter le développeur à faire du code parfois bancal. Mais probablement moins qu'en partant de 0 toutefois.
- Certains frameworks offrent plus de fonctions que d'autres. Rails puisque c'est celui que je connais le mieux, propose un système de tests (du code pour tester le code et éviter de tout casser à chaque modification), possède des fonctions pour intégrer rapidement du javascript (à ne pas utiliser tel quel), un système de "migrations" pour faire évoluer sa base de données en gardant la possibilité de revenir en arrière, et couplé à un système de contrôle de source comme Subversion ou CVS et à Capistrano, le déploiement sur un ou plusieurs serveurs se fait en une ligne de commande et sans FTP, etc...
- Certains ont des fonctions pour créer du code HTML et/ou javascript tout seuls, et ce code est de plus ou moins bonne qualité (En vérité je vous le dit, n'utilisez pas les Helpers Javascript de Rails tels quels).
- Enfin ils n'utilisent pas le même langage.

En fait il faudrait faire un article complet sur l'utilité et l'utilisation d'un framework, qui ne sont pas aisée à décrire en quelques lignes, puisque par définition, c'est quelque chose d'assez abstrait. J'avais prévu d'en faire un pour mon blog, d'ailleurs...
Modifié par Lanza (29 Jun 2007 - 14:22)

Salut,

petites questions :

- qu'en est-il de la phase de tests ? Est-ce qu'il existe un équivalent de EasyPhp et/ou la possibilité d'installer Ruby sur son poste ?

- En cas de développement vraiment "tordu" (ou disons très spécifique) est-ce que c'est suffisament souple ?

Une petite question pour ceux qui ne savent absolument rien sur le sujet:

Par où commencer ?

Y-a-t-il de bons tutoriels...?

Heyoan a écrit :
Salut,

petites questions :

- qu'en est-il de la phase de tests ? Est-ce qu'il existe un équivalent de EasyPhp et/ou la possibilité d'installer Ruby sur son poste ?

Oui, il faut installer ruby et rubygems, puis rails. Ce n'est pas très compliqué, il y a même peut-être des packages tout prêt avec ruby et rubygems. Ensuite, Rails étant fourni avec un serveur web minimal, il suffit en ligne de commande de lancer

c:\Mon_application_Rails> ruby script/server

et l'application est immédiatement disponible à l'adresse http://localhost:3000/

a écrit :
- En cas de développement vraiment "tordu" (ou disons très spécifique) est-ce que c'est suffisament souple ?

Oui, oui, mille fois oui. C'était une de mes craintes au départ, mais j'ai eu tort. C'est la grande force de ces frameworks justement.

Sylvain a écrit :

Par où commencer ?

C'est là que le bât blesse, au moins en ce qui concerne Rails, en France. On manque de tutoriaux. Faudrait écrire un article.

Lanza a écrit :
C'est là que le bât blesse, au moins en ce qui concerne Rails, en France. On manque de tutoriaux. Faudrait écrire un article.

euh ok mais alors avec quoi as-tu appris ?

Moi, je n'avais fait que ça :

http://rubyfr.org/documentations/les-bases/apprenez-ruby/ ce qui ne concerne que Ruby (sans rails)

Quand j'ai vu rails, je suis reparti faire mes pâtés de sable avec php à l'époque...

Un truc hyper important (mais alors vraiment hyper important), c'est la DOC !

Pour utiliser un framework, il faut avoir de la doc pour apprendre comment sa fonctionne et voir un peu "la philosophie" derrière le code.

C'est à dire, comment les concepteurs du framework on-t-ils voulu qu'on utilise le bouzin.

2eme chose, il faut distinguer les "gros frameworks bien lourds" (sans préjugé aucun) des "framework léger qui facilite la vie sans faire le café"

C'est à dire que pour la très grosse appli, même si les petits frameworks s'en sortiront à force de code, il pourra surement être plus efficace d'utiliser le gros framework prévu pour absorber tout le bordel.

A contrario pour des petites applis style blog ou galerie de photo, ça ne sert sûrement à rien de sortir le gros framework.

Comme pour les langages, un framework est adapté plus à certains besoins qu'à d'autre, et on utilise pas un outil parce qu'il nous plait mais parce qu'il est adapté à ce qu'on veut faire.

Il ne faut pas avoir peur d'utiliser la ligne de commande pour certains d'entre eux, notamment pour les procédures d'installation du framework et/ou de l'appli résultante.

Koala64 a écrit :
euh ok mais alors avec quoi as-tu appris ?

Avec des bouts de tutoriaux (en anglais) à droite et à gauche, puis avec la doc, et finalement le bouquin.

Un bon point de départ : tutoriel sur ONLamp.com

@olivier : Rails ne m'a jamais paru un truc énorme. Qu'est-ce qui te fait dire ça ? Il sait faire plein de trucs qui ne servent pas forcément, certes, mais c'est vrai pour toute bibliothèque de code. Quelle fraction des fonctions PHP utilises-tu au quotidien ?

Oui pour la ligne de commande, mais les commandes sont simples, justement.
Modifié par Lanza (29 Jun 2007 - 15:27)

Pour les exemples :

Ruby :
Rails (RoR = Ruby on Rails)

PHP :
Code Igniter (léger) (codé en PHP4 pour la retro compatiblité, mais notre code peut être fait en PHP5, le coeur du framework n'utilisera juste pas les avancées objets de PHP5, l'avantage est d'être utilisable à la fois avec PHP4 et PHP5), Symphony (usine à gaz), Jelix (tend à devenir usine à gaz il me semble), CakePHP, ...

Python :
Pylons (léger), Django (tend à devenir unsine à gaz)


Sinon, attention à bien comprendre une chose, c'est que les framework génèrent un niveau d'abstraction supplémentaire, c'est à dire que la couche objet du coeur du framework plus la notre ajoute du temps de traitement de calcul. Plus on abstrait, plus c'est "lent".

Je ne dis pas que ça ralentit tout comme à l'époque du 56K mais il faut en être conscient.

Avantages de ce principe :
Abstraire un maximum de choses (connexion à la BD, gestion des formulaires etc.), manipuler des structures équivalentes, élégantes, cohérentes. Des structures extensibles, repose sur des design patterns éprouvés et reconnus. Robustesse du code généré.

Désavantages :
Nécessite un apprentissage (ou de l'habitude), peut devenir lent en traitement etc.

Lanza a écrit :



@olivier : Rails ne m'a jamais paru un truc énorme. Qu'est-ce qui te fait dire ça ? Il sait faire plein de trucs qui ne servent pas forcément, certes, mais c'est vrai pour toute bibliothèque de code. Quelle fraction des fonctions PHP utilises-tu au quotidien ?

Oui pour la ligne de commande, mais les commandes sont simples, justement.

Hein ? j'ai jamais dit (ici ^^) que rails était un truc énorme

Tu mets le doigts sur ce dont je parlais dans mon précédent post, certains frameworks font beaucoup de choses et parfois des choses dont on ne se servira jamais là où d'autre font juste ce qu'on leur demande et permettent d'ajouter des éléments si besoins.

Ce n'est pas un reproche, il faut simplement en être conscient et utiliser les outils en prenant en compte ce critère.

Si on veut se faire une petite appli rapido, on a pas forcément besoin de la grosse artillerie alors qu'avec une grosse appli là, ça prend tout son sens et c'est limite nécessaire.

Pour la ligne de commande, ce n'est pas non plus un reproche, et ce n'est pas nécessairement complexe, c'est juste qu'il faut le savoir.

Enfin, quand je parle de framework lourd, usine à gaz etc. je ne parle pas forcément de Rails certains frameworks PHP et Python font ça très bien aussi

Olivier a écrit :
Pour les exemples :

Sinon, attention à bien comprendre une chose, c'est que les framework génèrent un niveau d'abstraction supplémentaire, c'est à dire que la couche objet du coeur du framework plus la notre ajoute du temps de traitement de calcul. Plus on abstrait, plus c'est "lent".

Je ne dis pas que ça ralentit tout comme à l'époque du 56K mais il faut en être conscient.

Avantages de ce principe :
Abstraire un maximum de choses (connexion à la BD, gestion des formulaires etc.), manipuler des structures équivalentes, élégantes, cohérentes. Des structures extensibles, repose sur des design patterns éprouvés et reconnus. Robustesse du code généré.

Désavantages :
Nécessite un apprentissage (ou de l'habitude), peut devenir lent en traitement etc.

C'est vrai dans l'absolu. Simplement, j'ai remarqué que dans la pratique et dans l'urgence, peu de développeurs web prennent le temps de définir une architecture solide pour leur sites. J'ai l'expérience de plusieurs "frameworks maisons" (dont un des miens) qui, dès qu'il montent en charge s'écroulent lamentablement, et pourtant les couches d'abstraction sont moindres.

A contrario, les choix d'architecture logicielle[1] qui sont faits par un framework tels que ceux évoqués ici, pour peu qu'on les respecte, et tout est fait pour qu'on les respecte, mènent à une application beaucoup plus solide. Ensuite, c'est une question de configuration du serveur.

[1] Je parle bien d'architecture logicielle, pas de l'information, qui est laissé à la discrétion des auteurs du site.

Ce sujet m'intéresse beaucoup, car jusqu'ici, je ne connaissais pas les frameworks, et j'ai toujours tout fait moi même, en php.

Mais je suis confrontée à des problème de sécurité...

En particulier, quand je reçois des infos d'un formulaire qui me génère des requètes sur ma bdd, j'ai toujours peur que qqn se glisse dans une faille et me bousille tout. Surtout que je ne suis pas une spécialiste.
a mon boulot, on utilise jsp, et en java, il y a des fonctions sécurisée pour insérer des données dynamiques clients dans une requètes.

Est ce qu'un framework peut être la solution à mon problème ?

Il y a-t-il des bons frmaworks php (car mon serveur est php et je connais déjà bien) ? Ai-je besoin de tout refaire mon site ou est ce que je peux simplement utiliser certaines fonctions ?

Tiens, j'ai jeté un oeil au site de CodeIgniter, et ils ont l'air d'avoir une jolie doc bien complète... et le bouzin lui-même m'a l'air très compréhensible.

Je crois que je vais faire quelques tests. Je compte refondre mon site perso prochainement, et vu qu'il part un peu dans tous les sens (un blog + plein de petits machins) ça peut être intéressant de faire les choses moi-même en m'appuyant sur un framework léger. Enfin bref, je crois que je vais y jeter un oeil pour voir. Et faudra que je me remette à mes bases de PHP.

yahrou a écrit :
Est ce qu'un framework peut être la solution à mon problème ?

Il y a-t-il des bons frmaworks php (car mon serveur est php et je connais déjà bien) ? Ai-je besoin de tout refaire mon site ou est ce que je peux simplement utiliser certaines fonctions ?

Les frameworks ont souvent des solutions pour éviter ce genre de choses, oui.

Maintenant, refaire un bout de site, ça me paraît compliqué.

Je répond à Florent et à yahrou en même temps.

Code Igniter (que j'utilise personnellement) est vraiment léger, simple, bien documenté, évolutif, bien foutu et aussi, c'est des paranos de la sécurité qui l'ont fait et la gestion des données issues de formulaires et urls et autre est super bien gérée et prévue comme ça !

Perso, j'ai pas beaucoup d'élément de comparaison, mais la simplicité, l'efficacité et la sécurité ajouté à la doc de CI font que c'est énorme j'adore

Y a une grosse commu (anglophone) derrière en plus.

La doc est en cours de traduction FR à ce qu'on m'a dit


@Lanza, oui la montée en charge est prévue, testé et éprouvée sur les frameworks, c'est aussi un grand interêt de les utiliser

Bon ben après avoir visionné une grosse partie des vidéos tutoriels de CodeIgniter, je constate qu'apparemment (ou alors je me trompe lourdement) on ne peut pas faire grand chose avec ces outils si on n'a pas une certaine dose de php dans ses connaissances techniques. Et justement c'est mon cas

Donc, ben si jamais un jour j'apprends le php (ce que je n'exclus pas), j'essayerai de m'y mettre, en attendant, je reste fidèle à nos bons vieux cms avec lesquels on sait déjà faire pas mal de choses.

Encore merci à Florent et les autres pour m'avoir appris des choses aujourd'hui.

touvert a écrit :
Bon ben après avoir visionné une grosse partie des vidéos tutoriels de CodeIgniter, je constate qu'apparemment (ou alors je me trompe lourdement) on ne peut pas faire grand chose avec ces outils si on n'a pas une certaine dose de php dans ses connaissances techniques. Et justement c'est mon cas

Donc, ben si jamais un jour j'apprends le php (ce que je n'exclus pas), j'essayerai de m'y mettre, en attendant, je reste fidèle à nos bons vieux cms avec lesquels on sait déjà faire pas mal de choses.

Encore merci à Florent et les autres pour m'avoir appris des choses aujourd'hui.

Euh, bah pour utiliser un marteau, c'est mieux de savoir comment ça marche et à quoi ça ressemble, c'est sur !!

Mais c'est très loin d'être complexe je trouve

Justement les tutos vidéos montrent à quel point c'est simple !

Mais bon, si tu ne connais pas du tout PHP, c'est sûr que c'est pas la peine (idem pour Ruby ou Python pour les frameworks ruby/python !!)