On 7/5/10 8:46 PM, Michael Snoyman wrote:
There were a few places where you used the @-interpolation with strings, which resulted in the "Hamlet String" datatype. The first patch addresses that, and adds a bunch of type signatures.
Aha! This is very helpful. I think I get it. I was assuming @...@ takes a string, and just enforces proper encoding. And indeed you can give it a string, and this forces the type of the template to Hamlet String (and prevents easy use of hamletToRepHtml, at least in my experience.) But for stronger checking, you should give it a route (type ...Routes, eg one of the Route constructors defined with parseRoutes). And if you occasionally still want to specify a url with a string, you can use $...$. If the above is correct.. is it useful to have @...@ be polymorphic in this way ? Or should it just require a route ?
The second patch may not be exactly what you're looking for, but I'm pretty sure it's correct: in generals, you don't need to capture multiple values for GET parameters, so I just changed the data types of "as" and "ps" throughout the code to be "String" instead of "[String]". This allowed me to use the special URL-params interpolation sequence of Hamlet:
I guess you're right, one GET parameter can hold all the command-line args or options. Thanks very much for the patches! -Simon