Automatically add compiler pass for each document manager

[fazy]

When using the RoutingBundle with multiple document managers (e.g. when using multiple workspaces), I think it would be better for it to add a DoctrinePhpcrMappingsPass compiler pass for each document manager, as seen in the CmfRoutingBundle class.

Without this, a user of the bundle can run into problems where classes are not mapped correctly, e.g. when working with a document manager other than the default. See this topic for details.

Possible approaches:

• Automatically loop through all the managers specified in doctrine_phpcr -> odm ?
• Or a manual setting?

cmf_routing:
    dynamic:
        manager_name: published
        mapped_managers: [ preview, published ]

I don't mind doing a PR if it makes sense to change this. If not, then maybe I should update the documentation, because the user of the bundle currently needs to add similar compiler pass code into their own bundle class.

[dbu]

actually it was like this at the beginning, and then @beberlei or @stof proposed to limit it to just the configured manager. maybe we should allow a list of managers too. the unfortunate thing about this is that part of the code is in symfony core (for the orm mapping past at least). so the only easy thing would be to register a second pass for the preview workspace that only gets active if we have the parameter that says preview is activated. that is a good solution for this use case, but in general it will be more fiddly than expected when working with multiple doctrine sessions.

[dbu]

do you want to do anything on this @fazy ?

[fazy]

Yes, sorry for the extended absence... I am about ready to pick this up now. So I guess we need to settle on how it should work.

I think it could work automatically, by looking at the names in doctrine_phpcr.odm.document_managers and missing out the one already specified in cmf_routing.dynamic.manager_name. Whether it should work like that, I don't know.

If you prefer the behaviour "off by default", then we just need a good name for mapped_managers: in the example above. In that example, will the published manager will always get a compiler pass, even if it's not listed in the mapped_managers array? Or do we say:

• If mapped_managers is specified, only do a compiler pass for the managers listed there (so, in fact, it's possible to remove the default compiler pass)
• If mapped_managers is not specified, keep the current behaviour, which created a compiler pass for the manager specified in manager_name.

[dbu]

the compiler pass is created in the bundle, at a time when we do not know the configuration yet. i also wonder if the preview thing should go into the RoutingBundle. maybe we should start a PreviewBundle that based on the configuration and session configures a preview routing service with the preview workspace and also handles the preview versus published of other bundles. it would know the preview workspace and could configure the preview documentmanager for all relevant bundles.

[fazy]

Yes, I'm beginning to think a PreviewBundle could be useful. I guess we would still make all the bundles be able to cope with n document managers, but the PreviewBundle (or PreviewPublishBundle?) would handle the specific case of using exactly 2 document managers, and help with providing the workflow capabilities.

[dbu]

i think the PreviewPublishBundle should be the one to handle the more document managers. there is no way for the bundle to handle n managers, unless we would refactor the compiler pass, which is based on code in symfony core so at best it could work with symfony 2.4, if the change is accepted at all.

btw, magnolia uses the concept of running the stage server on a separate server, and has some sort of rest communication to copy a jcr export to the production server and import it there. maybe the PreviewPublishBundle could have synergies with such a concept - but maybe its a really different idea, not sure.

[fazy]

Ok, I will post a topic in the devs group to scope out a PreviewPublish bundle.

The Magnolia case is interesting, although I wonder if it's too high level an operation for a CMF bundle to take care of? I guess it's only possible to publish the whole site in one go (not individual pages). However, if Jackrabbit Oak changes/removes workspace support, we may need to go down that route.

[dbu]

magnolia is doing it on page level (and also with configuration
fragments and whatnot). i think they handle themselves to not
synchronize the subtree.
it is a totally different approach to the same problem, not using the
workspace feature at all. a bundle could do it, it would have to expose
some sort of internal route that is configured to only work from the
stage server and accept a repository fragment there. a bundle could do
that i think. not sure if there are any synergies with the workspace
clone/merge approach, but wanted to toss the idea into the air.

[dantleech]

I wonder if PreviewBundle would be the best name when "staging/production" terminology seems to be more common - also I wonder if we are limiting ourselves to a model with 2 workspaces - can we imagine a scenario where people will want more than 2?

[dbu]

lets continue this discussion to the symfony-cmf mailinglist where more
people will see it. fazy created a thread on the list for this.