Open nmeri17 opened 2 years ago
On a second thought, an additional reason to have a route aggregator is that it'll afford us the chance to have named routes that can be referenced in views since they're relatively more stable than referencing the actual urls
Another purpose this will serve when it exists is to move the Services\DecoratorHandlers\SecuresPostRequestHandlerDecorator
to a dependency sanitizer. It can then easily determine request method (from attached routing map), and complain in the absence of recommended services
Whenever this is ready, look into helpers such as this https://boringrails.com/tips/rails-link-to-unless-current
This aggregator will typically work with methods from https://github.com/nmeri17/Tilwa/blob/master/nmeri/tilwa/src/Routing/RouteManager.php. Current consumers (
ModuleInitializer
) useRouteManager
to compute patterns that best match incoming path. That's different from this case in the sense that no comparison is being made. We just want to follow and list all possible from a collection to any additional collections attached to it along with any behaviour bound to it (middleware, authentication, authorization, controller, action method, validator, doc blocks).The design of route collections in itself is a ready-made map for exploring the route tree; which would make this endeavour unnecessary for the mere purpose of route listing. The bigger picture is gathering these details into a format that can be transferred to https://apiblueprint.org/. I'm proposing ApiBlueprint since it's said to be compatible with OpenApi in addition to having more functionality.
If you're interested in working on this, please let me know if you need anything