Méthodes magiques, classe statique en instance

[Max72]

Le truc, c'est que je ne vois pas pourquoi j'aurai besoin de ça. Je préfère télécharger ce dont j'ai besoin, savoir ce qu'il y a dedans, le mettre en place comme je veux et l'appeler / l'installer comme je veux.
Et si c'est "parce que c'est à la mode", je fais très bien sans. Je sais que, comme mon combat perdu contre Google ^^, le fait de ne pas y passer n'embêtera que moi..

A croire que j'aime pas les monopoles ou que l'on me dicte ma façon de faire ^^

[Akira777]

+1 pour le fond. Marre de se sentir obliger ;p

Mais dans la forme c'est vraiment génial Composer et le "contorsium" PHP-FIG. Faut l'utiliser après pour vraiment en comprendre les tenants et aboutissants mais dans l'ensemble pour moi c'est vraiment ce qu'il manquait à PHP et qui lui apporte une touche de crédibilité (et de vrais perspectives d'industrialisation).

Pour moi ça rentre plus dans le code "réutilisable" et "professionnalisant" que dans le, c'est "à la mode". Je pense qu'on peut presque plus passer outre, au même titre que les frameworks ou le "MVC". Mais ce n'est que mon avis.

[niahoo]

Personnellement ça n'a aucun rapport avec la mode. Dès que j'ai croisé ce truc je ne m'en suis plus jamais passé. ça me permet de développer mon projet tranquillement et d'avoir les dépendances à disposition avec une commande dès que je change de poste pour tester sur une autre plateforme en gardant mon projet super léger (pourquoi tu mets le vendor dans git !?!).

ça me permet aussi de tester plusieurs librairies qui couvrent une fonctionalité. Exemple, je veux pouvoir faire des appels à une API en HTTP, j'ai plusieurs clients, je les teste un par un juste en faisant un `composer require ...` et sans me soucier des les inclure ou autre je peux m'en servir directement. Et une fois que j'ai fait mon choix, le composer.lock est un bonheur pour le déploiement.

En plus comparé à npm, rubygems ou autres, composer tient vraiment la comparaison.

Je préfère télécharger ce dont j'ai besoin, savoir ce qu'il y a dedans, le mettre en place comme je veux et l'appeler / l'installer comme je veux.

Argument totalement invalide. Tu as le droit de simplement ne pas avoir envie de t'en servir

Composer te permet de télécharger ce dont tu as besoin (même si ça n'est pas compatible, et de toute façon rien ne t'empêche de mixer des lib composer-compatibles et d'autres autoloads ou includes manuels).
Pour savoir ce qu'il y a dans un package ben tu regardes la source, je ne vois pas de différence.
Pour mettre en place un package comme tu veux et l'installer, effectivement c'est pas pareil ... vu qu'il n'y a rien à faire, les classes sont toujours disponibles.

Bref, je te conseille vivement de tester a minima. Ensuite, tu peux t'en passer. Mais p*tain qu'est-ce que ça me fait gagner comme temps.

[srm]

Tu sembles avoir une problématique banale que tu résous de manière très alambiqué.
Je ne sais pas quel système tu as, mais sur un système MVC à peu près correctement construit tu aurais normalement un super contrôleur , par exemple BaseController dont tous les contrôleur héritent. Et il aurait une méthode du genre preAction, qui est appelé avant l'action de base.
Il te suffit donc de mettre dans cette action la récupération de la ville de l'assigner à une propriété du contrôleur et de la passer à la vue dans genre $this->views['ville']

[Max72]

niahoo : Je teste actuellement, je vous en reparle dès que j'ai une vrai idée là dessus.
J'ai déjà remarqué des trucs qui ne me plaisent pas mais je crois que ça vient du framework qui impose des dépendances ( plusieurs versions de jQuery dans un framework PHP, Twitter Bootstrap, ..). J'en veut pas moi ! ^^

srm : Très alambiquée, peut-être.
Si tu regardes le code que j'ai filé plus tard, tu vois que j'ai un SuperController, et tous mes controllers en héritent.
L'initialisation de ma ville se fait justement dans le construct du parent.
Enfin, si je ne passe pas l'objet Town comme une propriété du controller, c'est que je veux pouvoir l'utiliser partout sans le passer à chaque fois : Certaines classes utilisent cet objet de manière automatique, avant que le controller ne fasse quoi que ce soit (gestion des évènements par exemple).

[Sephi-Chan]

A propos de Composer : quand tu peux automatiser quelque chose, fais-le. C'est un atout énorme quand tu veux déployer une application en (pré)production d'avoir un contrôle strict des versions de logiciel utilisés. Et avoir une liste déclarative de tes dépendances est également très intéressant.

[Akira777]

Personnellement ça n'a aucun rapport avec la mode. Dès que j'ai croisé ce truc je ne m'en suis plus jamais passé. ça me permet de développer mon projet tranquillement et d'avoir les dépendances à disposition avec une commande dès que je change de poste pour tester  sur une autre plateforme en gardant mon projet super léger (pourquoi tu mets le vendor dans git !?!).

Oulah non, je ne met pas les vendors dans git xD Mais quand on tombe sur des développeurs qui ne veulent pas / savent pas utiliser composer, pas le choix. Puis après le déploiement sur un mutualisé s'en voit facilité (quand on a pas accès à la ligne de commande). M'enfin, on est entièrement sur la même longueur d'onde, on ne git pas les vendors

Désolé, je met en avant de vieilles techniques de tchétchéne, mais je travaille régulièrement avec des devs qui sont trèèèèèèès loin de Git / Composer / Tests Unitaires / Déploiement.
D'ailleurs à ce propos, dploy est mon must-have depuis 2014 (je ne sais pas si vous connaissez).

[niahoo]

Connaissais pas, effectivement ça peut être pratique. Perso je n'en ai pas besoin je travaille pas sans accès shell sinon c'est vraiment relou.

[srm]

Bah si justement Max72 tu devrais vouloir le passer partout au controller car tu as dis que tu le voulais partout.

[Max72]

Oui je le veux partout, mais sans le passer à mes classes.
Par exemple, sur chaque page mon objet template récupère une grosse partie de cet objet pour l'affichage (or etc).
Mais je n'ai pas envie de passer mon objet dans chaque controller, c'est mon objet template qui va récupèrer ma cité tout seul au moment où j'appelle la méthode d'affichage du template.

Sur le fond, je suis d'accord avec toi, et mon template n'a, sémantiquement parlant, pas le droit d'aller récupérer des infos où il veut. Mais ça me simplifie le développement du controller lorsque je n'ai pas besoin, à chaque affichage, de passer ma cité à mon template à la main.