Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Quand je dis une organisation de fichiers dans un framewrok, je ne parle pas d'une liste de chemins d'includes. Quand je dis organisé, c'est vraiment "organisé"
Un exemple, dans Jelix, tu met tes modules dans un répertoire précis. Dans un module, tu met tes objets métiers dans un sous repertoires "classes", les templates dans "templates", les controlleurs dans "controllers" etc... Et pas ailleurs.
Tu veux trouver la classe foo du module bar, tu sais tout de suite où la trouver. Dans un système avec une liste de chemin d'include, elle peut finalement être dans n'importe quel de ces chemins d'include. On a un alors une organisation moins structurée.
Cela ne veut pas dire que ce soit mal non plus. Mais avec une organisation stricte, en connaissant le framework, le dev va mieux s'y retrouver et trouver plus vite ce qu'il cherche, même si il ne connait pas l'appli, ce qui est plutôt avantageux pour la maintenance et l'évolution de l'appli,
Et cette organisation des fichiers d'une appli, ce n'est pas le langage qui l'impose, mais le framework.
Bref, dans un framework, en principe (et c'est son but), il y a plein de petite chose comme ça qui guide et oblige le développeur vers un respect de certaines "guidelines".
Pour moi, le Zend framework par exemple, il n'a de framework que le nom. Ce n'est qu'un ensemble de bibliothèque utilitaire. Il n'oblige à aucune organisation. Si tu veux faire une appli hyper bordélique, tu peux le faire. Avec un fmk comme jelix, c'est déjà beaucoup plus compliqué...
[^] # Re: Lignes de code
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal PHP eats rails. Évalué à 2.
Quand je dis une organisation de fichiers dans un framewrok, je ne parle pas d'une liste de chemins d'includes. Quand je dis organisé, c'est vraiment "organisé"
Un exemple, dans Jelix, tu met tes modules dans un répertoire précis. Dans un module, tu met tes objets métiers dans un sous repertoires "classes", les templates dans "templates", les controlleurs dans "controllers" etc... Et pas ailleurs.
Tu veux trouver la classe foo du module bar, tu sais tout de suite où la trouver. Dans un système avec une liste de chemin d'include, elle peut finalement être dans n'importe quel de ces chemins d'include. On a un alors une organisation moins structurée.
Cela ne veut pas dire que ce soit mal non plus. Mais avec une organisation stricte, en connaissant le framework, le dev va mieux s'y retrouver et trouver plus vite ce qu'il cherche, même si il ne connait pas l'appli, ce qui est plutôt avantageux pour la maintenance et l'évolution de l'appli,
Et cette organisation des fichiers d'une appli, ce n'est pas le langage qui l'impose, mais le framework.
Bref, dans un framework, en principe (et c'est son but), il y a plein de petite chose comme ça qui guide et oblige le développeur vers un respect de certaines "guidelines".
Pour moi, le Zend framework par exemple, il n'a de framework que le nom. Ce n'est qu'un ensemble de bibliothèque utilitaire. Il n'oblige à aucune organisation. Si tu veux faire une appli hyper bordélique, tu peux le faire. Avec un fmk comme jelix, c'est déjà beaucoup plus compliqué...