Faire des liens entre applications dans un projet symfony, revue des trois méthodes proposées

Avec Symfony 1.0, faire un lien d’une application vers une autre application représentait un vrai challenge. La solution la moins horrible consistait à parser le fichier routing.yml et faire 10 000 bidouilles que je vous cacherais ici. Dans Symfony 1.0 le contexte était géré via le pattern singleton dans une variable statique ; impossible d’en instancier un autre. De plus, le système de route était trop couplé au framework pour l’utiliser plus indépendamment.

Ces deux évolutions (instanciation de plusieurs contextes possible et découplage du système de routing) en symfony 1.2 on permis enfin de gérer des liens inter application proprement

A ma connaissance il y a trois façons aujourd’hui de faire des liens entre différentes applications dans un même projet Symfony. Dans ces trois cas, on sent que les développeurs ont cherché à répondre à  ce même besoin selon des contraintes qui leurs étaient propres.

omCrossAppUrlPlugin – écrit par Olivier Mansour (moi)

Ce plugin propose un helper assez simple à utiliser :

function cross_app_url_for($appname, $url, $absolute = 'false',
  $env = null, $debug = 'false')

Sous le capot, plusieurs choses ce passe :

  1. instanciation du contexte symfony correspond à l’application,
  2. récupération du contrôleur associé (cette partie là peut misérablement planter si vous n’utiliser pas les conventions de symfony, par ex *_dev.php pour l’environnement de dev, ou une configuration avec no_script_tag à on),
  3. génération de l’url via le système de routing dans le bon contexte.

C’est pas mal, les urls sont cachées, c’est facile à utiliser. Par contre l’instanciation du contexte est assez couteuse. Globalement on va faire une pelletée de choses dont on a pas forcement besoin pour générer une URL. Ce plugin est en production sur un projet très important comportant de nombreuses applications, il marche très bien. Enfin, le code écrit n’a pas besoin de paramètrage, ce qui était nécessaire dans le cas d’utilisation du plugin ou il devait être déployé chez des centaines de clients ayant des configurations variées et utilisé par de nombreux développeurs.

Une recette proposée par Fabien Potencier

Avec ce système, on doit, dans chaque gestionnaire de configuration des applications (apps/frontend/config/frontendConfiguration.class.php par exemple), déclarer des fonctions qui permettent d’accéder au routing des autres applications.

Cette solution est bien adaptée si le besoin est ponctuel. Elle ne nécessite pas d’instancier un contexte (ce qui est une sacré évolution) mais n’est pas trop pratique à utiliser.

Thomas Rabaix vient de sortir un nouveau plugin très intéressant : swCrossLinkApplicationPlugin

Clairement, si vous cherche une méthode, utilisez celle là. Elle a de nombreux mérites :

  1. elle est peu intrusive, il suffit de modifier factories.yml et on continue a utiliser ses bons vieux link_to en préfixant les routes du nom de l’application suivi du point (.)
    link_to('Edit Blog Post', '@backend.edit_post?id='.$blog->getId())
  2. on évite d’instancier un contexte, cela diminue l’empreinte mémoire,
  3. on bénéficie de toute la partie routing du framework et du cache des routes.

Seul inconvénient, on doit faire quelques paramétrages, le plugin ne détecte pas les contrôleurs comme omCrossAppPlugin. (ceci dit, c’est très facilement améliorable). De mon coté, j’espère pouvoir apporter rapidement quelques améliorations et utiliser ce plugin. Merci Thomas Rabaix !

Publicités

2 réflexions au sujet de « Faire des liens entre applications dans un projet symfony, revue des trois méthodes proposées »

  1. NiKo

    Pour les petites applis, j’avoue généralement placer et back et front office dans la même application, les modules résidents alors dans des plugins et n’étant alors qu’activé et éventuellement surchargés localement dans une unique application…

    Ça fonctionne, et on dispose naturellement de tout l’écosystème de ressources applicatives à tout moment…

    Le seul inconvénient est que les gros projets peuvent rapidement se retrouver difficilement gérable au sein d’une seule application.

    Répondre
  2. Tim

    Merci pour ce tour d’horizon!

    C’est une des problématiques que j’ai toujours évité jusque là, mais on va bien finir par me le demander un jour :p

    Je prend donc bonne note 😉

    Répondre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s