You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are getting feature requests and questions from the community to be able to route based on different properties of req than just path, see, e.g., #709.
We probably don't want to bloat the default router too much, OTOH, after #967, custom routers can go wild with the passed req object. However, at the time of this writing, it is a bit cumbersome to implement a new custom router -- although the protocol itself is straightforward and easy to understand, implementing a completely new routing strategy from scratch is quite an involved task, and it is unclear how to extend the default "compiled" router beyond simple wrappers around, e.g, add_route().
Things that already are easy to reuse:
map_http_methods() -- factored out into a separate helper that can be used with any router.
set_default_responders() -- factored out into a separate helper that can be used with any router.
Things that are opaque/private/undocumented/hard to reuse:
Extracting parameters from a URI template. Controlling how parameters are passed to a method. Unavailable in falcon.inspect either.
Parsing converter spec from a URI template, controlling how converters are called. Unavailable in falcon.inspect either.
Reusing/extending the compile machinery, all methods/locks are private except the compile flag itself.
Extended code generation in any way.
The text was updated successfully, but these errors were encountered:
We are getting feature requests and questions from the community to be able to route based on different properties of
req
than just path, see, e.g., #709.We probably don't want to bloat the default router too much, OTOH, after #967, custom routers can go wild with the passed
req
object. However, at the time of this writing, it is a bit cumbersome to implement a new custom router -- although the protocol itself is straightforward and easy to understand, implementing a completely new routing strategy from scratch is quite an involved task, and it is unclear how to extend the default "compiled" router beyond simple wrappers around, e.g,add_route()
.Things that already are easy to reuse:
map_http_methods()
-- factored out into a separate helper that can be used with any router.set_default_responders()
-- factored out into a separate helper that can be used with any router.Things that are opaque/private/undocumented/hard to reuse:
falcon.inspect
either.falcon.inspect
either.compile
machinery, all methods/locks are private except thecompile
flag itself.The text was updated successfully, but these errors were encountered: