How to deal with persistence layers

[wouterj]

How should we handle PHPCR ODM/ORM, etc. things in this bundle?

1) Global config

cmf_sonata_admin_integration:
    persistence:
        phpcr: ~
    bundles:
        seo: ~
        routing: ~

The problem here is that some options of the admin factories are persistence layer dependent (e.g. basepath in routing).

2) Per admin config

cmf_sonata_admin_integration:
    bundles:
        seo:
            persistence:
                phpcr: ~
        routing:
            persistence:
                phpcr:
                    basepath: /cms/routing

This might be combined with a global enable option, to avoid lots of duplication.
The problem here is that each admin factory has to add these options to its config tree. We can't guarantee that the option exists.

3) Other options?

There probably are some other ideas?

---

Btw, this also means we have to make the PHPCR ODM Sonata admin bundle optional, so people can install only the SonataDoctrineOrmAdminBundle.

[ElectricMaxxx]

i would prefer 2.) cause especially for the block-bunlde, we have an other base path (basepath_menu).

A third option would be a global one and an optional overwriting one for each admin.

When this one is clear and done we should read setting of the path from core-bundle => symfony-cmf/core-bundle#217

[dbu]

each admin section should have an enabled option. i like version 2, with a global persistence section for the default value for all sections.

regarding base paths, if possible we should default to the one from the actual bundles. the routing bundle base path logic is quite odd, btw. i dont get why we abort early if cmf_sonata_admin_integration.routing.phpcr.basepath is not set in the container.

[ElectricMaxxx]

So we default on the bundle's paths, and use persistence.phpcr section in each bundle section? So then lets do it.

[wouterj]

@ElectricMaxxx I'm currently thinking about a way to enforce this on the factories.

[ElectricMaxxx]

👍 i trust your thinking :-) and will wait for it.

[wouterj]

Well, I'm kind of afraid it isn't possible (there is no state in the tree builder, only a tree, so no way to get child elements afaics).

What you can try:

• Always add a persistence node in Configuration class.
• Add the persistence node again in the factories, but then with phpcr child and all related stuff.
• Add a global persistence node under cmf_sonata_admin_integration that can take any string (or array of strings) with a persistence layer in this. Pass this to the factories in an argument and let the factory determine how to handle the global option.

Examples of wanted behaviour:

cmf_sonata_admin_integration:
    persistence: phpcr
    bundles:
        content: ~
        seo: ~

Result: Content and Seo admins with PHPCR backend

---

cmf_sonata_admin_integration:
    persistence: orm
    bundles:
        content: ~
        seo: ~

Result: Seo admin with ORM backend, error in Content admin because no backend is supported

---

cmf_sonata_admin_integration:
    persistence: [phpcr, orm]
    bundles:
        content: ~
        seo: ~

Result: Seo admin with PHPCR and ORM backend, Content admin with PHPCR backend.

---

cmf_sonata_admin_integration:
    persistence: orm
    bundles:
        content:
            persistence:
                phpcr: ~
        seo: ~

Result: Seo admin with ORM backend, Content admin with PHPCR backend.

---

cmf_sonata_admin_integration:
    persistence: phpcr
    bundles:
        routing:
            persistence:
                phpcr: { basepath: /cms/routes }
        seo: ~

Result: Seo and Routing admins with PHPCR backend, Routing admin with an extra basepath setting

[dbu]

i like your configuration examples wouter. i think we should do it like that. its quite an effort but i don't see how to make it simpler.

i would limit the global option to persistence: [orm|phpcr] . anything more complicated has to be on a per bundle level. if we ever have more persistence layers, we do pull requests on this bundle anyways. and a custom factory can chose to ignore the defaults...

[ElectricMaxxx]

Is this one solved by #71 too? (the PR was closed)

[wouterj]

Yes, we removed persistence layer by requiring PHPCR persistence :)