Use cases of Dream.path

[amongonz]

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 to path 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.

[Josef-Thorne-A]

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 :)

[reynir]

We use Dream.path in two cases:

• .../build/latest/** where it redirects to .../build/:build/** preserving the tail of the path
• file/** which looks up in a database to find the data corresponding to that file, somewhat similar to Dream.static except with a indirection through a database.

[aantron]

Thank you all. It looks like it's best to undeprecate it, but probably also consider routing in more detail.