Skip to content

Use cases of Dream.path #238

Open
Open
@amongonz

Description

@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.

Metadata

Metadata

Assignees

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions