Discussion :

[ioexception]

Bonjour,

Voilà, j'ai un peu de mal à voir la bonne pratique à adopter, je vous explique mon projet.

J'ai un site web à faire avec ces fonctionnalité :
- un moteur qui calcul tout un tas de truc et affiche tout un tas d'information/images etc...
- un système de facturation
- un catalogue de produit
- un système de gestion de livraison
- un système de produit (creation, etc..)
- un systeme pour gérer mes utilisateur
- un systeme de calendrier + retroplanning très poussé etc...

Bref, j'ai pensé à créer un bundle pour chacune de ces fonciton ce qui me semble une bonne méthode pour maintenir etc... mais je me rend compte que point de vue programmation c'est la m***

par exemple sur ma page principale je souhaite afficher plusieurs bundle :
- le calendrier
- une liste des produits
- un catalogue

Etant donné que je vois ça sous forme de bundle, pour les réunir tous ils me faudrait inclure dans un twig les bundles de cette facon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{{ render(controller('***ProduitBundle:Produit:show')) }}

Et je ne sais pas si c'est une bonne manière de faire, sachant que si par exemple je souhaite personnaliser mon twig "show" comment je lui inclut une css étant donné qu'il n'hérite de rien.

Comment feriez vous à ma place, je découpe mes fonctions en bundle comme ci-dessus et dans ce cas je fais des contrôleur imbriqués ou je découp mon application en 2 bundles (frontend et backend) et basta, en sachant que je trouve qu'avec cette dernière ce sera moins pratique à maintenir :/

[dukoid]

pour moi l’intérêt premier d'un bundle est la réutilisabilité.
l'autre interêt, c'est d'avoir un bundle sur un serveur de donnée et un autre bundle sur un autre serveur de donnée.

sinon sans cela, un bundle frontend et backend me semble bien.

n'oublions pas que dans les bundles nous pouvons classer de la sorte :
controller/facturation/...
controller/produit/...

views/facturation/...
views/produit/.....

[ioexception]

Ce qui m'embête c'est que j'ai une "fonctionnalité" qui va souvent évoluer (en fonction de client). Et la notion de bundle était parfaite car j'aurai créé dans ce bundle un contrôleur par client quand cela serait nécessaire.
Ce qui me faciliterai la maintenabilité.

Symfony est pas évident appréhender je trouve de ce côté. D'un côté dans les bonnes pratiques je lis qu'un bundle = une ou un gorupe de fonctionnalité de même nature mais d'un côté quand tu as besoin de réunir de manière ponctuel plusieurs bundle sur la même page, l'intégration est complètement tordu.

Ca me semble pourtant assez basique ce que je veux faire, une page d'accueil avec :
- un calendrier
- une liste de produit
- une toolbar
- un catalogue

Le calendrier n'est qu'une fonctionnalité parmis d'autre du bundle Schedule que j'aimerai créer et pareil pour les autres.

[dukoid]

dans ce cas tu peux très bien partir de ton idée de départ.


concernant le css:

tu as la page "parent" qui contient le bon .css du produit.
cette page "parent" va appeler :
{{ render(controller('***ProduitBundleroduit:show')) }}

donc la page produitshow.html va utiliser le .css du parent, non ?

[prims]

Tu fais un bundle par fonctionnalité c'est très bien.

Pour ta page home c'est simple. Plusieurs solutions.

- Soit tu te dis, que celle page home à du métiers plus du coté calendrierBundle ou autre alors tu créer route/controller dans le bundle et tu fais appele aux autres bundles et code métiers. Bonne pratiques c'est service, injection de dépendances.

-Soit tu créer un bundle qui a des fonctionnalité pour réunir tous tes bundles...

Enfin je le vois comme ça...

[ioexception]

dans ce cas tu peux très bien partir de ton idée de départ.


concernant le css:

tu as la page "parent" qui contient le bon .css du produit.
cette page "parent" va appeler :
{{ render(controller('***ProduitBundleroduit:show')) }}

donc la page produitshow.html va utiliser le .css du parent, non ?

oui mais ce que j'aurais aimé c'est que la feuille css reste dans mon bundle produit (ou toolbar dans ce cas précis) car ça le concerne uniquement. (je sais je suis chiant )

En gros voilà l'architecture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#app/Ressources/views/layout.html.twig
{{ render(controller('***ToolbarBundle:Toolbar:show')) }}
 
{% block body %}{% endblock %}
 
 
{{ render(controller('***ProduitBundle:Produit:list')) }}

puis j'ai mon bundle toolbar avec sa propre feuille css et son twig show :
src/.../ToolBar/Ressources/css/mafeuille.css

Merci en tout cas, je prend tout vos avis en compte, je réfléchis encore au problème en fouillant le net pour voir ce qui sera le plus simple à maintenir et propre.

J'ai cru voir qu'il était possible de faire un héritage, en gros, j'aurais un bundle Main (qui va se charger de réunir les bundles dont j'ai besoin sur la page d'accueil) et il serait donc le parent des autres bundles. Je ne sais pas encore si ce serait une solution, je vais essayer aussi de regarder de ce côté, j'explore un peu toute les pistes avant de me décider sur quoi je pars.

[dukoid]

en effet, il est possible d’hériter d'un bundle. sf2 est objet, utilisons ces propriétés

concernant le css, à ma connaissance les fragments que tu ajoutent "produit, calendrier..." s'ajoutent les uns après les autres et donc avec les différentes déclaration css .(et donc pas misent dans le header html)

je donne ma langue au chat .....

après il est possible de definir plusieurs layout:

layout_modele_1 avec une liste de declarations .css defins
layout_modele_2 une autre liste....

et tes pages heritent soit de layout_modele_1 ou 2



et même faire 3 niveaux d’héritage comme ceci : (ce que je fais)
base_page

layout_modele_1 et layout_modele_2 hérite de base_page

pageX herite de layout_model_1
pageY herite de layout_modele_2