Use cases of Dream.path
amongonz opened this issue · 1 comments
The function Dream.path
has been marked as deprecated. I understand that structured routing is preferable, but its removal blocks use cases for which routes can't be computed upfront. For example:
Dream.static
depends on the internal equivalent topath
to map paths to the file system; it should be possible to implement such a handler with Dream's public API as well.- I'm currently writing a CGI handler, and I needed
path
to forward paths to CGI scripts.
If path
were removed, implementing such handlers would become an exercise in recursive application of Dream.router
to consume the entire path that wouldn't even provide any static information to parent scopes. Simple access to the path feels to me too foundational to remove, even if it competes with structured routes. (Would access to query parameters be removed as well if they were made routable?)
If widespread access to path
is problematic for routing, maybe path
could return a value only when the innermost route handler ends with a wildcard, and raise an exception otherwise. This would make handlers like static
or my CGI handler fail unless mounted directly under a wildcard, which I think is reasonable.
Will the deprecation of this be reversed? For the above use cases I don't see a clear alternative. If this has already been un-deprecated and my dream version is out of date then my mistake :)