Exactly, been seeing that comment inside the core. So yes, have a interface in the core and let developers implement that.
Can we create a project on github and try to collect issues without messing up the rest of the Flow issue tracker? Or should I just fork the flow collection/distributioni (?) repository and start collecting issues there ?
@aberl I was wondering if we could isolate the IdentityRoutePart to a own package aswell? Neos.Routing.IdentityRoute - but then I came across the DynamicRoutePart that requires the persistencemanager interface to get the identity of a object (used for ex. a “single view” route. So the splitting of the RoutePart classes might also be larger than expected, since everything excecpt static routes (controller/action based, no persisted object arguments) requires some sort of Persistence layer.
But of course we could use the Generic persistence implementation for that, as it already implements a generic way of getting that identifier. Or split the routing into different parts - you can still do routing with out having to pass around persisted object.
Which brings me to another topic: Are we touching other parts now aswell? TypeConverters, PropertyMapper ? Or are they good to leave and are not affected by these changes (more likely the other way around)