I've added an extra patch into the bundle with just a minor optimization:
when a pair in the query string list has an empty value, it doesn't output
an equals sign. Nothing ground-breaking, but makes the URLs look nicer for
those cases.
Michael
On Mon, Aug 9, 2010 at 9:32 PM, Jeremy Shaw
Nice!
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.
- jeremy
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, Michael