This feature would make it possible to have a separate module/dependency dynamically adding a route for instance in an init listener.
It would be great to also have support for adding parameterized routes dynamically; this would for example allow us to have jax-rs-like urls such as /person/{id}/add
My use case would also benefit from dynamically registered routes: I create views dynamically on start-up of application depending on a configuration loaded. Configured parameter is arbritrary and not known in advance. Therefor, I cannot declare routes at coding/compile time.
My current workaround is real hack: Building classes at runtime using Javassist with required annotations. Unfortunately, it wasn't enough to register these generated classes as spring beans. Instead I had to hook into VaadinServletContextInitializer and RouteServletContextListener to make them available to Vaadin.
We also need the possibility to create routes dynamically during runtime.
Our Vaadin application (currently Vaadin 8) is very modular and allows adding, removing, activating and deactivating modules at runtime. Modules may even be added and removed without application restart (achieved by embedding an OSGI runtime that picks up new jars).
Modules can register views but those views are only really available, if the module is actually activated by the user.
Currently we use a custom ViewProvider that only provides views of present and active modules.
Since arbitrary new modules may be deployed at runtime it is also not possible to know views / routes beforehand.
Of course we could put checks into each view / route but we would rather have that logic in one central place. Modules may be developed by third party developers and we don't want to rely on their implementation. So a custom route registry would be ideal for us.
There are two different technical approaches for being able to change the routing configuration while the application is running:
@markus-herrmann, @steffen-harbich-itc: Do you see any reasons for why either approach would be more suitable in your particular cases?
Hi Legioth,
in my opinion allowing the content of the route registry to be modified would probably be easier to use and also easier to implement . All we would need is a "registerRoute" and "unregisterRoute" method on the registry (or returning a Registration object from the "registerRoute" method that can be canceled instead of an "unregisterRoute" method).
The current RouteRegistryInitializer could remain, discover Routes defined with annotations and also use the "registerRoute"-Method on the registry to register those discovered routes.
This way we can mix static Routes (by annotation) and additional dynamic Routes.
@Legioth, approach 1 would be sufficient for my scenario and probably easier.
Our use case would be to allow user to define their won layout class, and store in the configuration table in the database. When rendering the page, we need to retrieve the layout definition defined by users and programmatically set that layout class as the routelayout of the designated page. Therefore APIs/methods to programmatically register routelayout would be essential to us.
Use cases:
There is a demo in flow-demos for this particular feature.
Tried that new feature and replaced my workaround with the dynamic routes. Worked like a charm, and great documentation. Good job!
Links to the demo and tutorials would be useful
From the flow 1.3.0 release notes:
https://github.com/vaadin/flow-and-components-documentation/blob/master/documentation/routing/tutorial-router-dynamic-routes.asciidoc
Most helpful comment
Our use case would be to allow user to define their won layout class, and store in the configuration table in the database. When rendering the page, we need to retrieve the layout definition defined by users and programmatically set that layout class as the routelayout of the designated page. Therefore APIs/methods to programmatically register routelayout would be essential to us.