Allow router object in nuxeo-routing-behavior to resolve entities. This must enable the urlFor and navigateTo functions to accept an entity object and infer what named route to call and what parameters to use.
Currently, if you have a document and you want to generate a url for it, or even navigate to it, you need to explicitly tell what route you want to use:
However, it would be useful to allow our reverse routing to accept an object instead, and be able to compose a suitable URL according logic defined at the application level:
The router should be customizable to handle different object types (e.g. documents, users, etc.), and leverage configuration properties to change it's behavior (e.g. use UID instead of path to generate document urls).
Of course, we must keep compatibility so that our reverse routing keeps working with the explicit named routes.
The urlFor and navigateTo functions will now accept an object as the first parameter as well, instead of a name route. If an object is passed, an entity resolver will be used to infer the name of the route to use and what parameters to pass to the route:
- The name of the route will be determined by convention, and the the entity-type of the object will be used.
- The parameter to be passed to the route will be a property read from the object. This property is referred to as routeKey.
- The routeKey is loaded from a UI config property, using the convention Nuxeo.UI.config.router.key.<entityType>.
- If no routeKey is found for a given entity type, id will be used (the default).
- For document entities, the default routeKey is "path".
- For document entities, the routeKey will be "uid" if we are dealing with a proxy or a version.
- For document entities, if the routeKey is "path", the browse named route will be used instead of document, to maintain compatibility with previous versions of the router model, which assumed the browse route would always be used to generate URLs using the document's path.