[web-devel] Re: Proposed changes to web-routes: query-string support
jeremy at n-heptane.com
Mon Aug 9 14:32:11 EDT 2010
I have not had time to look at this in detail, and probably won't for
a few more days. But I am certainly in favor of the concept.
I recently wrote some code for one of my own projects to deal with
creating query string key/value pairs. It will be interesting to see
how they overlap.
p.s. Also, the query string is not required to be key/value pairs. It
can be any non-hierarchical data which, combined with the path info,
serves to identify a resource. It just happens the key/value pairs are
the single most common what of encoding the this data. If web-routes
is going to only support key/value pairs, that is fine. But we should
probably acknowledge that in the docs.
On Aug 8, 2010, at 7:03 AM, Michael Snoyman wrote:
> Hi Jeremy,
> I've CCed the web-devel list, as I think the discussion will be of
> interest to a number of readers there.
> When we were originally working on web-routes, you had mentioned the
> idea of including some form of support for query strings, and I said
> it was a bad idea. I'd like to backtrack on that statement: I
> *would* like to include support, and I'm including a patch that does
> just that. Let me explain the use case this is meant to serve, which
> will help explain my design decisions.
> Yesod includes a static file subsite. One trick a lot of sites are
> using these days is including a hash of the file contents in the
> query string of the URL and setting the expiration date of the file
> far in the future. This way, as long as the file contents stay the
> same, the browser should use the cached copy, and as soon as a new
> version is available, the HTML will reflect this by a change in the
> hash value.
> I wanted to provide this feature with Yesod, but realized there was
> no straight-forward way to do this. What I needed was to change the
> formatPathSegments function to have a type signature of: url ->
> ([String], [(String, String)]), where the second element in the
> tuple is the query-string parameters. This, however, presents a
> small problem: let's say that we want to add query string parameters
> *on top of* those provided by the formatPathSegments function; we
> could do manually addition textually, but we won't know whether to
> include is as "?foo=bar" or "&foo=bar"; the former should be used if
> formatPathSegments does not given any query string parameter, the
> latter if it does.
> I therefore modified the handleSite function to be: (url ->
> [(String, String)] -> String) -> url -> a. I also changed
> encodePathInfo to also encode the query string parameters, so its
> type is now: [String] -> [(String, String)] -> String. All the other
> changes were just to get the code to compile.
> I'm planning on this being a change throughout a few other
> libraries: web-routes-quasi will obviously change to reflect this,
> as will Yesod. One other perhaps unexpected change would be in
> Hamlet: the definition of Hamlet is now "type Hamlet = (url ->
> [(String, String)] -> String) -> Html ()". One nice side effect of
> this is query-string encoding code is now completely localized to
> web-routes, instead of copied throughout multiple packages. This at
> least implies to me that this is a good move.
> You'll notice that I have purposely *not* modified decodePathInfo
> and parsePathSegments; I still don't believe routing should be
> affected in any way by query string parameters.
> Look forward to hearing your thoughts on this,
More information about the web-devel