in reply to Re: Mapping URLs to code - in search of perlish dispatch schemes
in thread Mapping URLs to code - in search of perlish dispatch schemes

Thanks for CGI::Application::Dispatch - I'll add that to my above roundup table. I don't quite understand the finer points of the dispatch interface, but some longer study of the documentation will hopefully tell me ;-)

My idea would work transparently for GET and POST queries because CGI (as an example) abstracts both into the ->param() function and even mixes and mashes the parameters together if I tell it to.

To me, the query path and the query parameters are more or less the same, except that the query path has no name, while the query parameters are name-value pairs. The functional programming languages (I'm thinking of Haskell) also have value-based function signatures, and my approach would be similar to that.

  • Comment on Re^2: Mapping URLs to code - in search of perlish dispatch schemes
  • Download Code

Replies are listed 'Best First'.
Re^3: Mapping URLs to code - in search of perlish dispatch schemes
by rhesa (Vicar) on Jul 20, 2006 at 22:50 UTC
    Gotcha. I thought you were just looking at throwing regexes at the request URI, but you're going one further. At the risk of over-stretching the analogy, it looks to me like you're going to do compile-time method dispatching and type checking, instead of at run-time. I can see value in that, although we could debate endlessly whether that is the perlish way ;)

    I'm interested to see what you come up with. I suppose I always felt that the uri-path is similar to a method name, while the query parameters are similar to its input parameters. Although CA::Dispatch's named captures muddles the water there, and that's also quite a useful feature. I'm still mostly using old-fashioned urls like /book/edit?id=1 instead of the more modern /book/edit/1, but I'm slowly catching up :)