Template, UML et MVC...

Bonjour.

J'ai découvert il y a peu Apprendre-PHP, alors que j'étais à la recherche de la meilleure méthodologie à suivre pour réaliser une classe de template (ou un template en classes).

Je suis tombé sur le sujet suivant : Créer son propre moteur Template, et vos réponses m'ont surpris, bien qu'elles soient pour certaines simples à comprendre.

Après avoir fait quelques recherches, tant sur l'UML que sur le MVC et tout cela m'a laissé bien perplexe.

Je suis sur le point de réaliser le développement d'un site de jeu en ligne (),qui està l'heure actuelle codé sans aucune des notions dont j'ai parlé ci-dessus, et dont j'ai repris le codage depuis juin.

Je me pose ainsi les questions suivantes : afin de rendre la plus facile possible l'ajout de fonctions dans un futur proche, de quelle façon dois-je procéder ? L'utilisation de l'UML me semble être importante, surtout qu'un nombre important d'objets seront manipulés, mais je ne vois pas comment il pourrait être possible de le lier à du MVC (si cela se fait, déjà !). De plus, je souhaiterait pouvoir modifier facilement le design du site (qui va changer bientôt, mais je ne vais pas attendre la fin du travail du graphiste pour commencer à coder). Comment faire, si l'utilisation de template est déconseillée ?

Dans l'attente de vos lumières, merci d'avance.

Salut In4matik,

tu abordes là un vaste sujet. Il sera difficile de tout traiter ici, mais on peut voir les grandes lignes.

L'UML, c'est bien et plus généralement, la modélisation est une étape indispensable dans tout développement rationnel quand on a une vision au delà de la semaine prochaine. ;) Mais l'UML, ça veut dire la POO : C'est là que ça devient amusant parce que lorsqu'on commence avec de l'objet, on se demandequ'est-ce que ça a finalement de mieux que des fichiers avec des collections de fonctions en marge du code des pages. Mais en fait quand on parle de POO, on arrive fatalement à de l'architecture logicielle : avec une vision à long terme, on doit tenter de faire en sorte que la maintenance et l'évolution de l'application en cours de construction soit la moins pénible et coûteuse possible. C'est de là qu'on en arrive aux Design Patterns (Motifs de Conception en français) et au MVC (qui est un DP composite, ne l'oublions quand même pas trop vite)

Le MVC schématiquement : tu vas diviser ton application en trois partie.

1. Modèle : c'est la couche d'accès aux données : c'est la partie qui gère la récupération des données depuis une source externe (base de données, fichiers, autres...) et retourne les données demandées;
2. Vues : c'est la partie affichage de l'application : on gère la construction et la mise en forme selon le format de sortie : écran d'ordinateur, de téléphone portable, fichier pdf, tableur (Excel ou OOCalc), etc...
3. Contrôleur : c'est ce qui va faire le lien entre les deux précédents en demandant au modèle certaines données et en choisissant la vue appropriée à retournée une fois construite.

Tout ça, c'est la théorie, c'est beau comme un camion tout neuf tellement ça a l'air simple, c'est quand on veut rentrer dans la mécanique que ça se corse un peu. Donc traduit autrement, je dirais qu'on pourrait aussi formuler ça de la manière suivante :

1. Un framework : ce sont des collections de classes génériques. Il en existe quelques majeurs (Symfony, Zend Framework, Cake PHP et bien d'autres encore. Tu peux aussi te construire le tien si le coeur t'en dit. Ce qu'il est bien important de comprendre, c'est que c'est du code générique qu'on ne modifie que pour des mises à jour et des corrections de bugs indépendamment de toutes les applications qui peuvent s'appuyer dessus;
2. L'application où on va trouver :

• Un Contrôleur frontal : tous les appels passent par cette page index : ces appels vont alors être analysés et il sera fait appel à d'autres contrôleurs plus spécifiques. Ces contrôleurs, c'est ton code dit «métier», du code propre à ton application : il n'est pas utilisable pour une autre application comme le serait le framework parce que le code cette fois-ci concerne directement l'application elle-même;
• Les vues : ça peut très bien être des templates, mais ça veut dire que tu utilises un framework dans lequel tu disposes (ou tu intègres si nécessaire) des classes appropriées pour gérer ces templates. Ou bien tu fais comme j'ai montré aussi dans le sujet que tu as cité avec de la syntaxe HEREDOC. Personnellement, c'est la méthode que j'utilise et que je recommande, même si Hugo ne partage pas cet avis :p De toutes façons, à ce niveau là, on est plus dans des problématique s de MVC mais dans des choix de méthodes.
• Le modèle : bien souvent en PHP c'est le parent pauvre et il se limite à peu de chose parce que beaucoup vont gérer leurs requêtes SQL directement dans les contrôleurs. Peronnellement c'est ce que je fais en me basant sur un package d'accès aux données de mon framework et auquel j'envoie les requêtes pour obtenir les données.

Résultat des courses : le MVC, c'est d'abordet avant tout découpler autant que possible les différents éléments. Tu mentionnes vouloir commencer sans attendre que le designer ait fini : c'est justement ça que permet cette architecture : dans la mesure où chaque page est définie, on sait ce qu'on va afficher comme données dans quelle page. Le développeur n'a en réalité pas besoin de savoir sir ce sera affiché en rouge ou en vert, en haut à gauche ou bienj en bas à droite : il a juste besoinde savoir ce qu'il doit collecter comme données et alimenter des variables qui seront utilisées pour remplir les maquettes/templates. De même le designer n'a aucunement besoin de savoir comment fonctionne le moteur interne de l'application : il sait aussi ce qu'il doit afficher et doit pour sa part en gérer la présentation. La nature même du contenu n'a pour lui aucune espèce d'importance tant que ça respecte des normes établies avant tout début de quoique ce soit : je veux dire par là que s'il attend un texte entre 10 et 20 ligne et que tu lui envoies 14 pages, le disign risque d'en prendre un coup sévère. Le lien entre les deux, c'est un dictionnaire de variable : chacun des deux doit savoir à quoi elle correspond, le développeur s'occupe d'en initialiser le contenu avec les valeurs appropriées, le designer se charge de la mise en page

En conclusion : le template n'est pas totalement déconseillé : c'est le moteur de template qui l'est. C'est vrai que pour beaucoup, un moteur comme Smarty peut être pratique. Je l'ai utilisé chez un client pendant un an, c'est une gymnastique à laquelle on finit par se faire. Mais fondamentalement, c'est une couche de traitement supplémentaire. On va éventuellement te dire « Ha oui mais Smarty gère aussi la mise encache »... heu... oui, et alors ? Rien n'interdit d'avoir dans un framework un package qui fait exactement la même chose, on peut activer des extensions PHP comme PAC et ce genre de chose et ce sera largement aussi performant. Et surtout, si on veut bien ne pas oublier que PHP est déjà en soi un moteur de template, l'intérêt d'en mettre un supplémentaire m'apparait comme exagéré. C'est comme si j'avais une voiture dans alquelle je voudrais ajouter un second moteur : ça n'aurait aucun sens, même en admettant que ce soit techniquement faisable, ça va alourdir le véhicule, ça va consommer davantage de ressources et le gain de performance n'est en aucune manière suffisant pour justifer ça, en tous cas pas pour un site « normal » : si tu devais gérer un site avec un catalogue de 500 000 article, là je dis pas que ce serait pas une option à étudier sérieusement.

Voilà, est-ce qu'il y a un point particulier qui te tracasse en dehors de ça ?

Erratum : Lire « extensions PHPcomme APC» et non « extensions PHPcomme PAC»

Merci Cyrano pour ces explications, qui éclairent un peu tout ce que j'avais lu (ce qui est fort consistant, il faut l'avouer !).

Je me demande désormais si ce n'est pas un peu "gros" pour le projet que je mène à l'heure actuelle : de là à utiliser un framework...

A partir de quel moment devient-il intéressant d'utiliser les méthodes UML ?

Et il y a encore un point que je n'ai pas compris :p Tu dis que PHP est déjà en soi un moteur de template... C'est à dire ?

Merci en tous les cas pour ces explications.

Salut In4matik,

désolé pour le délai, je n'ai pas eu l'avis de réponse.

Quand je dis que PHP est déjà un moteur de templates, c'est tout simplement qu'on peut tout simplement intégrer du HTML dans le PHP. Si tu fais :

<?php$nom = $_POST['nom'];?><p>Bonjour <?php echo($nom); ?></p>

Dans un système utilisant un moteur de template, on fait la même chose à la différence près qu'on utilise une syntaxe particulière et du code PHP pour l'interpréter et remplacer des variables spéciales par les valeurs de variables PHP : en d'autres termes, on ajoute une variable entre l'originale en PHP et le HTML alors que ci-dessus, on l'utilise directement.

Il y a par ailleurs des manières de faire pour coder de façon plus rationnelle et plus facile à maintenir aussi.

L'UML, c'est pratique pour analyser un projet de développement orienté objet. On identifie quels sont les objets nécessaires, comment ils interagissent entre eux, quelles méthodes doivent être élaborées, quelles propriétés seront utilisées : c'est de la modélisation.

Tu sembles réticent pour l'instant à te tourner vers un framework : je dirais que ce qui est important, c'est d'en comprendre l'utilité et la manière dont ça fonctionne, au moins globalement. Pour ton projet, je serais tenté de dire que la taille importe assez peu. Maintenant il est vrai que pour monter un blog par exemple, faire appel à l'artillerie lourde du genre Symfony ou le Zend Framework serait peut-être exagéré. Personnellement j'ai commencé il y a quelques années par me construire une petite structure de framework personnel histoire d'assimiler les concepts. C'est avec ce genre de pratique qu'on apprend. Mais si tu dois être opérationnel rapidement pour des besoins professionnels, il serait plus prudent de te tourner vers ce qui existe déjà et qui fonctionne fort bien : tu apprendras tout autant en utilisant un code stable et maintenu. L'idée générale du framework, c'est aussi surtout que tu peux te concentrer sur ton code métier sans devoir te creuser les méninges très longtemps sur les traitements que fait le framework. Dans ce cas, l'utilisation de l'UML peut s'avérer utile pour la partie application dans la mesure où tu veux monter ça en Objet. Ça pourra t'aider à visualiser ta structure de code métier, comment organiser tes contrôleurs et les autres parties de ton modèle MVC. Ça va aussi te faire réaliser l'importance de l'ordre et de la méthode pour n'importe quel développement, comment faire les choses dans le bon ordre pour ne pas devoir revenir en arrière pour recommencer un truc mal conçu parce que ne prenant pas en compte un élément non anticipé au départ : c'est là que la modélisation prend toute son importance en amont du projet.

Je ne suis pas vraimentréticent à l'utilisation d'un framework, mais on va dire plutôt que ne connaissant pas leur fonctionnement, je suis un peu inquiet de la masse possible de travail que cela pourrait m'apporter.

Après avoir fait quelques recherches, je pense que je vais opter pour Symfony, et donc apprendre les bases de ce framework.

J'ai vu aussi qu'une pre-release de la version 2 de symfony est disponible. Je suppose qu'il n'est pas intéressant de me mettre dessus à l'heure actuelle ?

Merci en tous les cas pour les éclaircissements, qui étaient nécessaires, cela est certain. Je repasserai peut-être de temps à autre pour poser quelques questions, au long de mon apprentissage.

Salut In4matik,

au contraire : si tu es en phase d'apprentissage, dis-toi bien que ton site ne sera pas terminé demain et qu'au moment de sa mise en ligne, la version stable de Symfony v2 sera très probablement disponible. Donc je recommanderais vivement à toute personne dans ton cas de se familiariser dès maintenant avec la v2.

Par contre, si tu as des questions sur Symfony, j'espère que Hugo trouvera un peu de disponibilité pour donner des réponses aux questions parce que je ne connais pas du tout ce framework. Je travaille actuellement avec un framework personnel qui n'a pas grand chose à voir avec ce bestiau qui est autrement plus gros. Et du coup le temps que j'ai passé à le mettre au point n'a pas pu être consacré à l'utilisation d'un des frameworks majeurs du marché. Quant au ZF, je n'en ai que des notions et je l'ai abandonné parce que certains choix techniques ne me satisfont pas pour le besoin que j'ai.

Salut,

Je me permets de répondre à tes interrogations concernant symfony 1.x versus Symfony2 car je travaille à la source du projet chez Sensio Labs. Tu as deux possibilités. Soit tu apprends symfony 1.4 car c'est une version très stable, largement documentée et supportée par la communauté ou bien tu te mets à Symfony2 au risque de passer du temps à comprendre comment ça marche.

Symfony 1.4 est la dernière version de Symfony 1. C'est très stable, très documenté et la communauté suit énormément le projet car elle contribue au projet sous forme de documentation ou de plugins fonctionnels entièrement gratuits. Tu n'auras pas de mal à apprendre comment fonctionne le framework grâce à des tutoriels comme Jobeet. L'idéal c'est surtout d'apprendre à travailler autrement avec des bonnes pratiques en vue d'accroître ta productivité, la qualité de tes développements et la pérennité des projets. Sache également que les développeurs Symfony (ou Zend) sont des profils de plus en plus convoités en entreprise.

L'autre possibilité c'est Symfony2 mais avec tout le contraire de symfony 1.x. Pourquoi ? Déjà Symfony2 nécessite au minimum PHP 5.3.2 pour fonctionner. Le problème c'est que très peu de serveurs web supportent cette version. D'autre part le framework est encore en version pre-alpha, ce qui implique deux choses non négligeables :

• Il manque des briques logicielles importantes (formulaires, admin generator, sécurité et droits d'accès...),
• le code risque (et c'est quasiment sûr) encore de beaucoup changer d'ici la fin de l'année.

Par conséquent, tu seras obligé de suivre l'évolution de Symfony2 avec attention afin de mettre à jour ton application en accord avec toutes les modifications apportées au framework. Ca demande du travail mais c'est aussi un avantage certain pour bien apprendre la philosophie du framework et être parmi les premiers à savoir l'utiliser à sa sortie en fin d'année. Pareil ce sera une compétence très convoitée par les entreprises en début d'année 2011. Autres inconvénients à Symfony2 : la documentation est encore très faible et pas tout le temps mises à jour. La communauté qui supporte le projet est encore minoritaire du fait que la philosophie de Symfony2 est radicalement différente de celle de Symfony 1.x.

En somme, travailler avec symfony 1.x c'est s'assurer des bases solides et c'est le meilleur moyen d'aller vite. Au contraire, utiliser Symfony2 maintenant c'est encore s'appuyer sur des fondations friables et tout apprendre soi même mais c'est aussi le moyen de préparer l'avenir des développements web professionnels avec PHP. A toi de voir comment tu veux travailler à courts et moyen termes.

Hugo.

Veeeery uselful, couldn't acquisition a account like this one ANYWHERE on the net!good affair you've got the visualizations for each, helps a lot. jogos de vestir jogos de futebol