Pull requests

#8 Declined
Repository
shadowman131/CherryPy_subhandler CherryPy_subhandler
Branch
default
Repository
cherrypy/CherryPy CherryPy
Branch
default

Added cherrypy.SegmentHandler for conveniently binding dynamic handlers

Author
  1. Walt Woods
Reviewers
Description

Updated for SubHandler -> SegmentHandler. Now stored in cherrypy.request.segments.

Comments (5)

  1. Sylvain Hellegouarch

    I can't see the use for this but I'd rather see it as an external recipe rather than a built-in new handler which would need to be maintained. Don't we already have popargs that could achieve such feature?

  2. Walt Woods author

    This is a better form of popargs, essentially. The main problem with popargs is that assigning _cp_dispatch is ugly and pretty unintuitive unless you're fairly intimate with CherryPy's workings. If I had of thought about it a bit more before implementing popargs, a SegmentHandler class that wraps an application class is what should have happened in the first place. That's the motivation here. It's a more user friendly way of supporting routed application code with object ids internal to the path.

  3. Sylvain Hellegouarch

    I can appreciate that and I quite agree with you that popargs is not as intuitive as it should be. Yet I'm not at ease to add one more way of doing things. Perhaps for a future CP version where we make it leaner and drop some features in favor of others?

  4. Walt Woods author

    I'm not opposed to that approach, though I will say that it often is better to deprecate features by implementing the new, preferred method, and referring users to that approach, while supporting both for a limited time. I do understand your hesitation though. The way I see it, the code that this depends on (as well as popargs) hasn't changed in eons, and I wouldn't expect it to change anytime soon. I think it might be worth considering this a little longer, particularly how it plays with CherryPy's goals (which I'm fairly certain you have a better idea of than me, but API friendliness, simplicity, and "pythonic" / object approaches come to mind).

    Either way though. I think this design pattern in general (object ids internal to a URL) is pretty common, and I just want CherryPy to support that pattern in a sensible manner.