Support multiple fragments on the same controller

[aschempp]

If the same fragment controller implements multiple content elements or frontend modules (example: https://github.com/terminal42/contao-oembed/blob/master/src/Controller/OEmbedController.php#L14-L18), the options will overwrite each other.

This is the best solution I came up with, but it's still kinda ugly 😞

[leofeyer]

Is implementing multiple elements/modules in the same fragment controller a supported use-case?

but it's still kinda ugly 😞

What exactly bothers you?

[Toflar]

I think @aschempp is concerned because of things having state. But I don't think that's true here. They don't have state. The fragment options do not change after container build. Just applying the correct ones is different.
I actually think that looks good here. Or what's ugly, @aschempp?

[Toflar]

Ah I see. Yes, this actually is state so the concept here seems wrong. What about actually dynamically creating 3 different services with different options during container build time? So the actual service one registers is not registered in the container but 3 child definitions per type, each having their own options? That's only required in case of multiple annotations on the same service of course but that would be the proper way to go imho :)

[Toflar]

👍 👍 👍

[philvdb]

This actually broke my setup because I was getting subcontrollers inside controllers (i. e. sub-content elements inside content elements) by referring to the service by class name.

$objSubController = System::getContainer()->get(FooController::class);

This approach basically still works now, unfortunately none of the options in the annotations of that service are available anymore. I believe that is because in RegisterFragmentsPass only the $childDefinition now has the call to setFragmentOptions added. The original service loses those fragment options, which means I cannot override the type or template settings and they are inferred from the class name. This is not always correct in my case leading to fatal errors on the site as templates are not found.

My code works again if I explicitly use the child definition by getting the child service like this:

$objSubController = System::getContainer()->get('contao.fragment._contao.content_element.foo');

Is that best practice now? Or could we add a call to setFragmentOptions for the original service as well, maybe at least with the first set of annotation options?

[aschempp]

You should never call the fragment controller directly. Use the Symfony fragment handler if you need to do that, similar to https://github.com/contao/contao/blob/master/core-bundle/src/Resources/contao/modules/ModuleProxy.php#L25

[philvdb]

Okay thanks for your help, I will look into it.

[philvdb]

Thank you again, @aschempp . Every little bit helps in my journey to understanding The Symfony Way:tm: - I am now using the FragmentHandler (no dependency injection for that intended, it seems? As Contao gets it from the container as well?) and request attributes to inform the controller of models and objects. Makes a lot of sense. So this message is just another thank you to you for steering me in the right direction.

[aschempp]

ALWAYS use dependency injection if you can! Contao only does it this way because the legacy classes cannot use dependency injection.