After several partial projects, I finally made one simple enough that I actually finished it before getting frustrated with Ur/web's quirks and lack of documentation. Ur/web is tremendous overkill for this project, but it was a good learning experience.
All it does is look at the San Francisco and San Jose sports schedules, and if there's a game at a time that will cause lots of people to ride Caltrain, say so and change the color. (If you're in the right timezone, that is...) http://willcaltrainsucktoday.com/ https://github.com/edanaher/willcaltrainsucktoday (It's a bit silly; as the about page says, it's a takeoff of http://isthereagiantsgametoday.com/ based on a silly tweet) I do like Ur/web very much in theory, and now that I've done a decent working example of simple SQL, RPC, and FRP, I hope I'll be able to use it for beefier projects in the future. Some thoughts/issues I had doing this (in no particular order): 1. Timezone handling is annoying if the client and server are in different timezones. Initially, everything was server-side, and it was great. Then I moved some of the computation client-side, and suddenly it broke on my remote server, since I'm now on Eastern time, while this assumes Pacific time. I'm not sure of a clean way to fix this in general, but since this really only makes sense if you're in California, I didn't try that hard. 2. To set the color, I wanted to set a class on the <body> that everything else could then work from. Unfortunately, dynclass on body didn't work. I don't see any theoretical reasons why this wouldn't work, but I certainly haven't investigated too deeply. 3. I had some issues with multiply-used signals giving bizarre errors; see https://github.com/edanaher/willcaltrainsucktoday/tree/master/signal_test. It seems like using a signal object multiple times leads to "TSignal remains" errors. The simple workaround is to think the creation of the signal so that it's not reused, but it makes the code uglier, and I'm mystified as to what the problem is (having not really thought about how signals might be implemented). 4. Generated JS onclick handlers appear to always return false, preventing the event from propagating. I wanted to onclick the main body to close the menu, but this prevented links from working because the body ate the click first. Changing it to onmousedown worked, but it would be nice to be able to specify whether the event should propagate. 5. URL whitelisting is prefix only; I wanted to use mailto:comments-[timestamp]@... for spam-blocking purposes. But to allow this link, I had to whitelist mailto:comments-*. This isn't a huge deal, but I'm wondering if there's any deep reason for this or if it just handles the common URL case, so was never improved. 6. Maybe I've done too much Haskell, but I kept being lazy about let val versus let fun (particularly when thunking the signals for (3) above). The initial error message "This is an expression but not a pattern." is extremely confusing, especially as it tends to point at an apparently unrelated line. The second error, "syntax error: inserting REC", is more helpful, but occasionally I managed to confuse the parser far enough that I didn't even get that. I hear there's work being done on a better infrastructure for compiling; I hope clearer error messages are a part of that. 7. Generating a dynamic link (such as on/[year]/[month]/[day]) requires generating the whole link tag dynamically instead of just substituting the link in. I found a reference online that this is because the function name in the link needs to be used to generate the URL; this makes sense, but seems to be an annoying limitation. _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
