implement PrependExtensionInterface

[lsmith77]

see also http://symfony.com/doc/master/components/dependency_injection/compilation.html#prepending-configuration-passed-to-the-extension

the idea would be to make it optionally possible to configure all the key aspects of the core bundles via the CoreBundle.

this would be a nice to have for 1.0 but not a must have as it should be possible to do this without BC breaks

[lsmith77]

The goal would be to be able to replace all of this:

cmf_routing:
    route_basepath: /foo/routes
    dynamic:
        locales: %locales%

cmf_create:
    phpcr_odm: true

cmf_content:
    multilang:
      locales: %locales%

cmf_menu:
    menu_basepath: /foo/menu
    multilang:
      locales: %locales%

cmf_blog:
    blog_basepath: /foo/content

With:

cmf_core:
    phpcr_odm: true
    basepath: /foo
    multilang:
      locales: %locales%

[dantleech]

Should we change basepath to base_path ?

[dbu]

to me route_basepath is more readable than route_base_path (then i don't know if its the path of the "route base" or the "base path" of the route"). and if we leave that, the cmf_core parameter should not have the underscore for consistency. i wonder if we should call it site_basepath but i think that could be a lie, in a multisite you might still share some of the trees.

do we need to split the cmf_menu basepath parameter (and route and so on)? if we inject cmf_core.basepath into the bundles, they would still need to know that they put their stuff under "menu" node (resp route, ...). and if x_basepath is set explicitly the param from cmf_core is ignored.

[dantleech]

But then basepath would seem to be the exception in naming conventions, it is two words, "base" and "path" - it logically translates to "base_path". In the case of the individual bundles we can drop "route", "menu", etc.

cmf_menu:
    base_path: /foo

cmf_routing:
    base_path: /bar

But as you say we still need to have something specifying "menu" on top of the base path provided by the core bundle.

What if we have 2 parameters, "base_path" and "path". The base path would be optional and would prefix the path if supplied. Having a separate parameter would also enable a listener to automatically set the base path in case of a multi-site setup.

cmf_core:
    base_path: /cms

cmf_menu:
    path: /menu

[dbu]

yeah that makes sense indeed. can we call the second parameter something else than just path? maybe base_path and data_path? local_name is wrong as it should be possible to have a subpath that is more than simply a name.

[dantleech]

actually, these settings are sonata specific are they not?

[cordoval]

this would be a multiple PR or just for Core? @lsmith77

[lsmith77]

the idea here is to have one bundle that effort effectively configures multiple other bundles

[dbu]

@dantleech no its not only sonata. its also for the menu provider to know where to find menus, for route provider to know where to look for routes. content and blocks is more open as they are usually referenced.