consider moving the Bundle to the CMF org

[lsmith77]

I would be open to moving this Bundle to the CMF org. At first I thought it might even be integrated into the RoutingBundle, but as it requires the RequestStack, which requires 2.4, I guess its better to keep it separate.

what do you think?

/cc @dbu @dantleech

[dantleech]

So I understand what this about, what is the use case?

[hacfi]

@dantleech Have a look at symfony-cmf/routing-bundle/pull/156

[EmmanuelVella]

@lsmith77 It also requires the expression language from sf 2.4

[dbu]

i am +1 to move this to the cmf organization. i guess we should target the 1.3 release and not the upcoming 1.2 to integrate it in a demo and the doc, so we have some time to review it and clean it up.

i think its good to keep it separate. RoutingBundle is quite complex already, and multidomain is a specific requirement not everybody has. i think @ElectricMaxxx could have some inputs here as well, as he is doing a multidomain site if i am not mistaken.

being on holidays, i don't have time to examine this bundle in detail - but i think we should give it a good review and see to it that things play well together (e.g. when combining language by domain name with multidomains, where you would have groups of domains that represent the same site in different languages. this should at least be feasable if not supported outright.)

[ElectricMaxxx]

Yea @dbu you are right.
Will try to have a look at the weekend. I am nearly ready with my project and will run 3 different portals out of one backend in the end of september (before i will leave Company+project). But i am very interessted in that bundle and its aproach/solutions.

[ElectricMaxxx]

Ohh yea that's the idea i should have had some month ago:
https://github.com/M4nu/MultiDomainBundle/blob/master/DependencyInjection/Compiler/OverrideRouteBasepathsCompilerPass.php#L12-L30
instead of (re-) creating an own route provider and filter, new route candidates are use, that's nice. Cause implementing an own provider causes many issues (forgot some stuff).

[EmmanuelVella]

If you think this bundle is ok, I can reorganise/rename it in order to move it to the CMF org. Here are some name proposals :

• symfony-cmf/RoutingMultiDomainBundle
• symfony-cmf/MultiDomainBundle

Or with host (closer from the routes host attribute)

• symfony-cmf/RoutingMultiHostBundle
• symfony-cmf/MultiHostBundle

[hacfi]

I like symfony-cmf/RoutingMultiHostBundle

[EmmanuelVella]

symfony-cmf/MultiHostRoutingBundle is also possible. However, maybe the bundle won't be limited to routing, so I'm not sure including Routing in its name is a good idea.

[lsmith77]

+1 for symfony-cmf/RoutingMultiHostBundle

[dbu]

If we just call it MultiHostBundle it could be used for things not directly related to routing. Are there any non-routing things to consider?

[ElectricMaxxx]

+1 for symfony-cmf/MultiHostBundle trust me, there will be more tasks then "just" routing, like:

• content in different representations per host
• different route strategies for each host
• ...

[ElectricMaxxx]

especially the new RoutingAutoBundle will got lots of new interesting tasks. Currently doing that with an fancy, crazy listener.

[dantleech]

Do we have any concrete use cases? It would be a shame to call it MultiHostBundle only to find out later that it is only Routing. (e.g. "differnet route strategies per host" sounds like routing :)

RoutingAutoBundle is very much only Routing.

[dbu]

different templates per domain would be a quest for some "theme" bundle. i think there already are some theme bundles for that.
but there could be access control or publication workflow things maybe? or something to help with multidomain menues? like i can just ask for a menu and get either the site specific menu or a fallback menu?