Que doit représenter un bundle dans Symfony2

Question

C'est peut-être une chose évidente pour vous mais - même après avoir lu de nombreux manuels et blogs - je ne suis toujours pas sûr de ce que doit représenter exactement un bundle dans Symfony2 dans une page web. Et il est difficile de le deviner à partir des simples applications de démonstration.

Par exemple : J'ai un site qui est divisé en deux parties (l'une est juste un domaine de 2ème niveau comme example.com et un autre est dom2.example.com ). Chacune de ces deux parties possède ses propres sections, parfois identiques (comme les actualités), parfois différentes.

Quelle serait la représentation correcte de ceci dans symfony2 ? Devrais-je avoir

• a MySite\site1 y MySite\site2 et faire les différentes sections via différents contrôleurs, ou bien
• paquets Site1\News y Site2\News ou
• paquets MySite\Site1News y MySite\Site2News etc.

...ou est-ce que je me trompe à ce sujet ?

Answer 1

Je suis également novice en matière de Symfony et je suivrai les résultats de cette question avec intérêt, mais pour ce que cela vaut, voici mon point de vue :

Un bundle n'est rien d'autre qu'un groupe de fichiers, de ressources, de classes et de méthodes PHP, de tests, etc. La logique du regroupement peut être ce que vous voulez. Dans certains cas, il est vraiment évident de savoir ce qu'est le regroupement et pourquoi il a été fait - par exemple, si j'ai écrit un système de blog pour Symfony2 et que je voulais le publier, je le ferais dans un bundle. C'est le type d'exemple le plus utilisé dans la documentation.

Mais vous utiliseriez aussi les bundles pour tout ce que vous voulez publier comme une petite fonctionnalité. Disons par exemple, ce forfait qui crée des routes par défaut pour tous vos contrôleurs. Ce n'est pas un plugin ou une fonctionnalité entièrement développé(e) comme un blog ou un forum, mais c'est un bout de code que je peux facilement importer dans mon projet, il reste totalement séparé de tout le reste, c'est un paquet.

Enfin, vous pouvez également utiliser les bundles en interne dans votre projet, de la manière qui vous semble la plus logique.

---

Mon point de vue sur votre situation spécifique :

Rapide et facile :

• MySite\MyCode -- fait le travail, et peut-être n'avez-vous pas de moyen logique de décomposer le code que vous allez écrire.

S'il y a des caractéristiques uniques entre les deux sites et que vous voulez les séparer pour plus de clarté :

• MySite\SharedFeatures
• MySite\Site1Features
• MySite\Site2Features

Si vous aimez vraiment que tout soit à sa place, ou si vous avez un projet complexe, peut-être :

• MySite\MySiteMain (fonctions partagées et informations diverses qui ne méritent pas d'être regroupées)
• MySite\News
• MySite\Site1FeatureSomethingOrOther
• MySite\Site2FeatureSomethingOrOther

Je pense vraiment que vous voulez vous en tenir à des groupes logiques de code -- donc je pense que ton exemple "regroupe Site1 \News et Site2 \News "et "MySite \Site1News et MySite \Site2News "ne serait pas la meilleure façon de procéder. Site1 et Site2 sont des implémentations, donc faire un paquet séparé pour la page de nouvelles de chaque site me semblerait contre-productif ; vous voudriez faire un composant de nouvelles et le construire pour être utilisé de deux manières différentes.

Pour ce qui est de votre question sur les deux domaines, vous pouvez soit faire pointer les deux domaines vers le même code, et tester dans votre code le domaine demandé, soit vérifier deux copies du même code et modifier légèrement les fichiers de configuration (cela ne va pas nécessairement à l'encontre de l'idée de SEC parce que vous devez toujours modifier le code à un endroit, puis mettre à jour les deux copies).

Answer 2

Selon moi, un bundle est similaire à ce que des CMS comme Typo3 ou Drupal appellent un "plugin". Il doit donc être idéalement autonome et écrit de manière à pouvoir être utilisé sur d'autres projets.

Par exemple, dans votre cas, je créerais un "staticHtmlBundle" qui contient toutes les pages statiques de votre site web, divisées par site.com et dom2.site.com.

Ensuite, je créerais un "newsBundle" qui contient tous les articles d'actualité, peut-être même piloté par une base de données avec une petite section d'administration où vous pouvez les modifier et les affecter à différents canaux (dans votre cas, c'est site.com, dom2.site.com). Une page statique à l'intérieur de staticHtmlBundle appellerait newsBundle et afficherait ses données (comme par exemple une listView des news ou une detailView et ainsi de suite).

Si vous gardez tout aussi abstrait et réutilisable que possible, vous pouvez même publier le newsBunde dans le référentiel Symfony 2 Bundle et le partager avec la communauté !

Answer 3

La façon dont je perçois les bundles Symfony2 est qu'ils fournissent un système modulaire qui vous permet non seulement d'étendre et de remplacer le code php, mais aussi toutes les ressources qu'ils peuvent ou non inclure.

Cela dit, considérons que vous disposez d'une API et que vous souhaitez transférer un objet.
Comment feriez-vous ?

Bien sûr, vous pouvez le faire manuellement, mais ne serait-il pas agréable que Symfony puisse le faire pour vous ?

Ma façon de faire serait d'inclure 3 paquets, JMSSerializerBundle y FosRestBundle .

1. Un paquet pour le côté client - MyCompany/ClientBundle
2. Un paquet pour le côté serveur - MyCompany/ServerBundle
3. Un paquet contenant tous les objets de transfert de données que je voudrais pouvoir transférer - MyCompany/CommonBundle .

Dans mon MyCompany/CommonBundle J'aurais les classes que j'utiliserais pour mes objets de transfert de données ainsi que les règles de sérialisation que je devrais fournir à la JMSSerializerBundle avec. Elles peuvent se présenter sous la forme d'annotations xml, yml ou php.

Une fois que vous avez un objet rempli avec les données, vous pouvez simplement utiliser return y FosRestBundle le mettrait en série pour vous. La sérialisation dépend du routage, de sorte que l'objet peut être sérialisé en XML pour un système et en JSON pour un autre. Le point essentiel est que vous disposez de différents formats de sérialisation et de versions que vous pouvez utiliser ultérieurement.

Côté client, vous pouvez utiliser un simple convertisseur de paramètres pour convertir le JSON ou le XML reçu en un objet directement dans le contrôleur, sans difficulté supplémentaire. Vous pouvez également saisir certaines règles de validation, afin de vérifier si l'objet est rempli comme vous l'attendez.

Dans mon exemple, le MyCompany/CommonBundle possède des objets qui seraient utilisés par plusieurs applications et qui seraient identiques. Le fait de disposer d'un paquet séparé vous permet d'éviter la duplication du code et facilite grandement la maintenance à long terme.

J'espère avoir réussi à l'expliquer. Des questions ?
Demandez dans les commentaires. Nous mettrons à jour la réponse en conséquence.