[web-devel] Re: Proposed changes to web-routes: query-string support

[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
> <query-string-support_.dpatch>