Combining bundles that use Sonata Admin

96 views
Skip to first unread message

Lars Janssen

unread,
Oct 24, 2012, 12:49:27 PM10/24/12
to sonata...@googlegroups.com
Hi,

I'm involved in building a number of Symfony 2 applications, many of which will need to share similar admin functionality based on the Sonata Admin bundle. Of course, I don't want to copy and paste code between projects. :)

Suppose I have a bundle src/Acme/AdminBundle that provides the following:

    * Log in/out (using entities in src/Application/Sonata/UserBundle/Entity)
    * Dashboard
    * Administer users and groups (using entities in src/Application/Sonata/UserBundle/Entity)
    * Administer Feature X (using entities in src/Acme/FeatureXBundle/Entity)
    * Administer Feature Y (using entities in src/Acme/FeatureYBundle/Entity)

If Feature X and Feature Y both have several admin pages, and could be used by several different web applications, I might be tempted to create the following bundles:

    * src/Acme/AdminBundle - base admin bundle including the user/group admin, default dashboard and log in/out
    * src/Acme/FeatureXAdminBundle - bundle that adds admin pages for Feature X
    * src/Acme/FeatureYAdminBundle - bundle that adds admin pages for Feature Y

The idea is that any application could bring in the admin bundles needed, with the appropriate entries in config.yml.

So my questions are:

1. Is the above possible using Symfony 2 / Sonata Admin?
2. Is it a desirable approach anyway?
3. Is there an alternative way to provide this flexibility?

I've tried putting the above into practice, but it seems the closest I can get involves having one 'main' AdminBundle with a config/services.yml defining services with reference to all the other Admin bundles. Also tried, unsuccessfully so far, to use bundle inheritance.

Thanks,

Lars.

David Buchmann

unread,
Oct 26, 2012, 5:29:37 AM10/26/12
to sonata...@googlegroups.com, Lars Janssen
why do you want to separate the admins from the entities?

we just put the Admin for the respective entities into the bundle of
that entity. and define the service in that same bundle and tag it.

for an example with PhpcrOdm admin see
https://github.com/symfony-cmf/MenuBundle/blob/master/Resources/config/admin.xml
(note that your "manager_type" attribute will be different with orm
https://github.com/symfony-cmf/MenuBundle/tree/master/Admin

cheers,david
> --
> You received this message because you are subscribed to the Google
> Groups "sonata-users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sonata-users/-/Mssv1QBS9j4J.
> To post to this group, send email to sonata...@googlegroups.com.
> To unsubscribe from this group, send email to
> sonata-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sonata-users?hl=en.

--
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch

Lars Janssen

unread,
Oct 29, 2012, 2:11:55 PM10/29/12
to sonata...@googlegroups.com, Lars Janssen
Hi David,

Regarding separating bundles from entities - in the beginning we had an Admin bundle for all the admin functionality separate from all the other bundles. Now that we've moved to something pretty much as you suggested, there's no reason to have the admin classes in separate bundles from their entities.

The one step we haven't made yet is to define all the services in their respective bundles. For now we have:

AdminBundle - containing the services configuration, pulling it all together, and the dashboard
FeatureXBundle - including admin classes, entities
FeatureYBundle - including admin classes, entities

Do you think it's possible to eliminate need for the AdminBundle altogether? i.e. by moving all service configuration to the feature bundles.

If we did that, the only possible other reason to keep the AdminBundle is to keep any style/layout that we might do differently from Sonata.

Thanks,

Lars.
Reply all
Reply to author
Forward
0 new messages