simplify the dynamic router

[dbu]

the dynamic router has grown quite complicated from its initial design. we should check if we can streamline things.

• do we need route enhancers or can we tell people to do an event system after the route match (resp use the symfony events)?
• can we simplify the setup of the dynamic router?

[danrot]

I was wondering what the initial idea behind splitting the DynamicRouter and RouteProvider. Feels to me like the setup would grow a lot easier, if developers would only have to create a DynamicRouter instead of both.

[dbu]

the dynamic router is handling the matching of routes when you can't have the collection upfront (because it is dynamic). the provider knows how to load the route candidates (e.g. from phpcr or some relational database).

[aschempp]

I Contao CMS we use a lot of these features and would need to rewrite if they are gone. But I would also agree that we use most of them because they are there – and I was trying to do best practice to use them 😆

We do use a route enhancer that does not actually enhance the route, but it "enhances" our legacy system with the route information. This could very well be implemented through a request listener, the enhancer kind of has the advantage to not rely on the router listener priority and noone could slip between them.

We also use route filters extensively. Not sure there's a particular reason not to do that filtering in the router provider, but the filters can be reused (we have multiple dynamic routers).

can we simplify the setup of the dynamic router?

regarding this question, I can't think of anything that could be made simpler. Having the router tag is great, but that's the chain router actually. Our dynamic router uses/needs a customized route provider, matcher (due to filters) and url generator. Maybe you have a more specific idea what could be made simpler?

[dbu]

i created this issue based on https://twitter.com/alex_s_/status/1526845679292882945 by @alexander-schranz

i have not formed a clear opinion one way or the other, but am looking for thoughts and inputs. if in the end we have a little implementation document that explains why we do things the way we do, and they stay the same, that would be a good outcome for me too.