Discussion :

[hous04]

Je suis entrain de faire un site avec symfony2 avec une partie administration "back-end". Cette partie admin a sa propre design et vues.

Je voudrais savoir la meilleur méthode pour la conception de cette partie admin , est-ce que dois mettre les vues dans le même endroit ou se trouvent les autres vues de la partie "front-end" ou bien il se trouve une autre méthode ?

Merci d'avance

[pmithrandir]

Bonjour,

Tu as 2 cas je pense.
Soit tu fais toi même ton panneau d'administration(pas conseillé je pense), et un mélange est possible, même si pas très souhaitable selon moi.
Soit tu utilise un bundle existant(comme sonata) et c'est clairement déconseillé.

Pour ma part, j'ai eu l'occasion de passer d'un panneau d'admin avec lyra vers un autre avec sonata, et le fait d'avoir bien isolé celui ci dans un bundle à grandement facilité le travail.
Pour faire simple, j'ai eu à remplacer mon bundle en changeant son nom, et à supprimer entièrement l'ancien et c'était presque fini. Pas de recherche de code à faire dans tout les répertoires.

En général, mes applications sont divisées en plusieurs bundle :
- Core : contient mes entités + repository, mon code métier, etc...
- UserBundle : une extension de FOS user. (par exemple ou tu ajoute des méthode propre a ta boite comme le LDAP / SSO ou un avatar)
- Admin Bundle
- WebserviceBundle(si le core fait autre chose que des webservice... autrement je met tout dans le premier.


Bon courage.
Pierre

[hous04]

Bonjour,

Tu as 2 cas je pense.
Soit tu fais toi même ton panneau d'administration(pas conseillé je pense), et un mélange est possible, même si pas très souhaitable selon moi.
Soit tu utilise un bundle existant(comme sonata) et c'est clairement déconseillé.

Pierre

Salut, faire moi même le panneau d'administration est pas conseillé et utilisé un bundleb comme sonata est clairement déconseillé , donc les deux solutions sont déconseillé ?!

Bon si j'ai choisi de faire moi même , pour les repositories comment faire ? Par exemple le repository de l'entité Produit, puis-je faire au autre repository qui continent des requêtes spécifique main dans le AdminBundle ?

[pmithrandir]

Excuse moi pour la mauvaise formulation.

Je te déconseille de faire ton module d'admin. Tu en a pour des heures / journées alors que sonata prend quelques heures. Mais si tu le fais, ca se mélange ou pas au reste du code selon ton choix.

Si maintenant tu utilise sonataadmin, ce que je te conseille, tu devrais faire un bundle séparé puisque ca facilite grandement ton travail futur.

Bon courage,
Pierre

[damiensan]

Je ne suis pas d'accord avec Pierre.

Tu peux très bien mélanger ton code d'admin avec tes bundles en utilisant Sonata.

Exemple : tu as une application e-commerce qui gère des clients, des produits et des commandes et des incidents (retard, produit abimés …)

Tu sépares ton code en différents bundles : Core, Customer, Order, Product et Incidents.

Or si tu veux distribuer tes bundles ou les vendre séparément (exemple vendre le bundle de gestion des incidents séparément des autres) tu mets ta partie admin dans tes bundles respectifs.
Ton bundle au final, gère des fonctionnalités. Et à mon sens la partie administration de ton bundle doit se trouver au sein même de l'architecture de ton bundle et non dans un autre bundle.

Un client veut les incidents ? Très bien tu lui donnes le code, il autorise le bundle dans le kernel et hop il accède également à l'administration des nouvelles entités d'incidents.

Pour en revenir à ta question tu peux créer des sous dossiers dans les répertoires de vues, de controller ou de librairies. Donc il n'y a aucun soucis pour créer dans tes bundles resources/views/Admin/Product, Library/Admin/Product

[dukoid]

sonataAdminBundle l'usine à gaz qui sers à rien.

pas besoin de ce boulet pour faire du CRUD

[pmithrandir]

Je ne suis pas d'accord avec Pierre.

Tu peux très bien mélanger ton code d'admin avec tes bundles en utilisant Sonata.

Exemple : tu as une application e-commerce qui gère des clients, des produits et des commandes et des incidents (retard, produit abimés …)

Tu sépares ton code en différents bundles : Core, Customer, Order, Product et Incidents.

Or si tu veux distribuer tes bundles ou les vendre séparément (exemple vendre le bundle de gestion des incidents séparément des autres) tu mets ta partie admin dans tes bundles respectifs.
Ton bundle au final, gère des fonctionnalités. Et à mon sens la partie administration de ton bundle doit se trouver au sein même de l'architecture de ton bundle et non dans un autre bundle.

Un client veut les incidents ? Très bien tu lui donnes le code, il autorise le bundle dans le kernel et hop il accède également à l'administration des nouvelles entités d'incidents.

Pour en revenir à ta question tu peux créer des sous dossiers dans les répertoires de vues, de controller ou de librairies. Donc il n'y a aucun soucis pour créer dans tes bundles resources/views/Admin/Product, Library/Admin/Product

Je trouve ta remarque pertinente. J'envisageais le problème sur la capacité a remplacer une techno par une autre facilement. (par exemple, ma migration de lyra vers sonata) dans ce cas la, avoir un truc bien isolé aide beaucoup(rien que pour ne pas avoir a aller supprimer dans tous les répertoires les bons fichiers).
En revanche, quand on utilise la modulaité pour vendre un produit par partie comme tu le présente, je trouve l'approche du module qui inclue son admin pertinente.

[pmithrandir]

sonataAdminBundle l'usine à gaz qui sers à rien.

pas besoin de ce boulet pour faire du CRUD

En fait, encore une fois ca depend.
Si tu n'a besoin que d'un crud, sonata n'est peut etre pasb necessaire(encore que si la generation te suffit, je pense qu'il est imbattable pour présenter les choses proprement).

Si maintenant tu veux des listes triable, filtrables et ordonnable en plus de ton crud, il te fais gagner un temps fou.

Une interface d'admin pour un site existant contenant une bonne dizaine d'entité, c'est environ 2-3 heures de boulot avec sonata... je ne pense pas arriver a le faire en moins de 2 jours à la main.