Au départ, j’étais complètement contre l’utilisation de framework. Je voulais programmer mon site web de A à Z sans intermédiaire. Je voulais garder le contrôle sur mon code en écrivant chaque ligne de code. J’avais un donc un petit système déjà bâti qui utilisait un fichier de configuration, un fichier de fonctions ainsi que mes pages PHP/HTML ensemble. Ensuite je me suis mis à apprendre l’oriente-objet pour ensuite me mettre à lire des livres sur la POO pour améliorer mes techniques de programmation. Dans les deux livres que j’ai lus sur la POO, on expliquait le design pattern MVC (Modèle-Vue-Controlleur) qui consiste a séparer l’interaction avec l’utilisateur (contrôleur), la présentation (vue) et l’interaction avec les données (modèle). Je reviendrais sur ce design pattern dans un prochain billet. Lors de mes lectures sur le sujet, je connaissais déjà cette méthode de travail sans avoir réussi à l’implémenter. Je me suis questionné sur le sujet longuement en me demandant si, un coup un tel système monté, je sauverais du temps et énergie lors de mes prochains projets.
La découverte des frameworks
Lors de mon apprentissage autonome en 6e session lors de mon DEC, j’avais exploré CakePHP, un des frameworks PHP5 les plus populaires. J’avais détesté mon expérience ne comprenant pas trop comment il marchait, et ce, malgré la présence de tutoriels. On me vantait ce framework comme un système qui me ferait sauver un temps fou en développement, alors que je ne voyais pas comment il pouvait y arriver. J’avais tout de même accroché sur le fait qu’il était possible de développer avec le pattern MVC.
Lors de mon questionnement sur un développement en POO, recommencer à utiliser un framework m’est revenu à l’idée. En fait, c’est un collègue scolaire et bon ami Rémi Prévost qui fait découvrir un autre framework PHP5 : Code Igniter. Il m’aura fallu quand même 8 mois avant de l’utiliser. Et maintenant, après 4 mois d’utilisation, je peux faire une bonne critique de cet outil. Les avantages et inconvénients des frameworks qui suivront sont basés sur une utilisation de Code Igniter et Kohana. Je n’ai jamais utilisé Symfony ou ZendFramework. Également, je ne peux critiquer Cake vu ma trop courte utilisation de ce framework. Également, la vue d’ensemble que je vous offre aujourd’hui ne représente que les frameworks PHP.
La POO : un bijou en soi
Le plus dur pour un programmeur est de passer de la programmation procédurale à celle orientée-objet. Une multitude de concepts s’ajoute lorsqu’on fait le saut à la POO. Les frameworks vous offrent la possibilité d’apprendre l’orienté-objet facilement. Vu que le système est déjà préconçu, il est facile d’avancer dans un petit projet pour apprendre les bases de la POO. Avec un tutoriel bien monté ainsi qu’une documentation riche, il devient facile de s’en sortir.
Un autre avantage d’utiliser la POO des frameworks et que vous pouvez le modifier sans toucher au code original du système. Il suffit d’ajouter par exemple une classe enfant pour écraser une fonction dont vous n’aimez pas le fonctionnement. Cette méthode est également valide lors de prochaine modification sur votre projet. Elle vous évitera plusieurs problèmes que la programmation procédurale peut vous causer. Vous savez sûrement de quoi je parle quand vous modifiez une fonction sur une page en particulier qui affecte une dizaine de pages sans le vouloir.
Le pattern MVC
Comme je le disais plus haut, j’utilise les frameworks en partie en raison de la programmation orientée-objet et pour le pattern MVC. J’apprécie beaucoup le fait d’avoir mon contenu séparé en trois couches. Cela évite en premiers lieux d’avoir des fichiers beaucoup trop gros. Il m’est déjà arrivé d’avoir des fichiers de fonctions communes (disponible sur plusieurs pages de mon site) de plus de 3000 lignes de code. Trouver une erreur dans ce fichier gigantesque était un défi en soi. Tout étant séparé dans le pattern MVC, il devient facile de cerner une erreur et de la corriger rapidement. Par exemple, lorsque l’erreur est d’ordre HTML, il suffit de regarder dans la Vue concernée. Plus le site devient gros, plus l’utilisation du pattern MVC est utile.
Un autre avantage d’utiliser ce pattern se situe au niveau du travail d’équipe. On peut facilement se retrouver dans le travail d’un collègue, même en ayant perdu le fil du projet pendant des semaines. On peut également développer en même temps sur le même projet sans trop s’accrocher, surtout pour l’intégration CSS/HTML. Pendant qu’un intégrateur modifie l’HTML d’une page, rien n’empêche le programmeur PHP de continuer l’ajout de fonctionnalité dans les contrôleurs.
La réécriture d’URL
Avec la puissance de Google, il est plus qu’important d’être visible sur le web. Une des techniques utilisées pour y arriver est la réécriture d’URL. Elle permet de passer d’une URL de type : posts.php?id=1&page=2 à quelques choses du genre posts/une-nouvelle-page/2 . Cette URL est beaucoup plus significative pour un moteur de recherche que la première, vu la présence de mots-clés directement dans l’URL. C’est souvent long et pénible de réécrire des URL. Avec un framework, on commence avec 90% du travail effectué. La manière dont le système est bâti vous offre déjà l’URL réécrite. Par exemple, l’URL par défaut de Kohana est http://www.monsite.com/index.php/welcome/index. Ce qui veut dire que le framework appelle la page index.php (la pièce maîtresse du système) qui appelle le contrôleur welcome et ensuite la fonction index du contrôleur. Il ne vous reste qu’à utiliser un htaccess pour cacher le index.php pour avoir une réécriture d’URL presque parfaite. Le reste de votre travail se fera dans le routage de ces URL pour qu’elles soient peaufinées à votre goût.
Les validations
Je déteste faire les validations d’un formulaire. Ce sont souvent des routines que vous avez fait des centaines de fois, mais qui vous font perdre énormément de temps de développement. Les frameworks offrent presque tous maintenant des routines de validation pour les formulaires qui vous épargne beaucoup de temps. En passant par la validation de courriel ou simplement la validation d’un champ requis tout y est. Vous pouvez sans problème ajouter des validations manuellement. La beauté de tout cela est que les messages d’erreurs sont gérés automatiquement.
Internationalisation du site web
Traduire un site web devient de plus en plus important, surtout pour un francophone qui veut que son site web soit lu et visité par le plus de personnes possible. Les méthodes variaient de beaucoup que ce soit un simple fichier PHP ou un XML qui contenait les lignes de texte. Un framework n’échappe pas vraiment à ces méthodes, mais c’est plus une certaine automatisation qui fait la beauté du système. Codeigniter et Kohana utilisent un peu le même système, soit un fichier dossier par langue qui contient plusieurs fichiers selon les pages du site (en fait vous décidé de la manière dont vos fichiers de langues sont gérés). Donc, il ne vous reste plus qu’à appeler la fonction lang (avec kohana) pour afficher le texte désiré. Votre site a besoin d’une deuxième langue, copier la première langue et traduisez. Ensuite il ne vous reste plus qu’à faire la validation qui détermine dans quelle langue le site se trouve.
Et bien plus encore…
Les frameworks contiennent encore plus que vous le pensez. On retrouve souvent un système de cache, de benchmark ou de logs. Ces trois éléments sont souvent utilisés pour améliorer les performances d’un site web. Plus votre site est gros, plus il est impératif d’avoir les meilleures performances possible. D’autres éléments viennent se greffer à tout ce que je vous ai déjà montré. Des librairies monter pour vous faire sauver du temps de développement, des classes dites “helper” qui ont les mêmes tâches que les librairies, mais plus petites. On ajoute à cela une configuration malléable pour former une recette gagnante.
Vais-je continuer à utiliser un framework?
La réponse est oui avec un bémol. L’utilisation d’un framework doit être justifiée. Un site de petite envergure comme une compagnie d’électricien sur la Rive-Sud de Montréal ne justifie en rien l’utilisation d’un framework. Le site doit être d’une envergure moyenne à grosse pour que l’utilisation d’un framework soit rentable. Un facebook ne devrait pas être développé avec un framework vu sa grosseur et sa complexité. Notez que plus le site devient gros et complexe, plus le temps sauvé par l’utilisation d’un framework par rapport à un site procédural devient presque inexistant. Pour ce point je parle par rapport à l’expérience vécue lors des derniers mois. Est ce que je regrette l’utilisation d’un framework pour ce projet? Non pas du temps. Si c’était à refaire, je referais la même chose.
On vous vente souvent la rapidité avec laquelle vous aller développer votre site web en utilisant un framework. Je suis ne pas vraiment d’accord avec cette affirmation. Il y a trop de facteurs à prendre en considération lors d’un développement de site web qui influence le temps de développement. Prenez simplement par exemple le temps d’apprentissage du dit framework. Il est évident que vous allez développer très vite si vous êtes un programmeur expert en POO et que c’est votre vingtième site avec votre framework. Même chose si vous êtes un habitué des sites plus traditionnels, vous aurez une vitesse de croisière supérieure comparativement à l’utilisation d’un framework. Tous ces arguments font en sorte que je n’ai même pas donné la vitesse de développement comme raison d’utiliser un framework.
Un autre désavantage de développer avec un framework est que lorsque vous avez besoin de quoi de moindrement hors-norme, il peut devenir complexe de le coder. Vous devez toujours avoir en tête que cela fonctionne avec le framework, sans le ralentir ou le détruire. Également, si vous n’aimez pas un “feature” du framework vous êtes pris avec ou vous devez changer de système. Par exemple, la classe de la gestion des bases de données. Finalement un dernier point, lorsque vous développerez une “feature” sur un framework, vous serez porté à utiliser les librairies ou helper du framework. Le problème sera lorsque vous tenterez de déplacer la classe ou fonction dans un nouveau framework ou dans un site qui n’en utilise pas. Vous perdrez beaucoup de temps à réécrire certaines parties du code pour le rendre compatible avec votre nouveau site web. Un conseil, limitez le plus possible les utilisations de librairies ou helper externe dans votre nouvelle feature.
Voilà, j’espère vous avoir éclairé sur l’utilisation d’un framework. Mon but n’est pas de vous forcer la main pour utiliser un framework ou non, mais bien de vous faire comprendre pourquoi moi j’ai utilisé un framework lors des derniers mois. À vous de juger si cela vous convient ou non.