I agree with Joel that I've found that secretary works very well with Om, especially with a few abstractions built over it to built the corresponding state. The opposite direction is tricky though, and the biggest problem I've run into is that matching order is based on runtime route declaration order, and as Dom points out, if you try to do this across namespaces, you're in for trouble. In practive, I've never wanted or needed to define routes in any way but top to bottom in a single file.
That said, I think the Silk approach is very elegant. First, isomorphism is great, good one. Second, being able to easily define subsets of routes and match/unmatch on arbitrary combinations of them is very powerful and highly composable. You could use the same (Google History) hash change token → dispatch! → data → transition! (Om), where dispatch! is a match on a group of routes. The state -> route direction is much cleaner with silk. It simplifies the problem a lot to be able to filter your routes to only include those dealing with your current app state, then selecting from your app state and matching on the filtered routes. I was trying to do something similar with Tao (although it was an alpha level mess), but ended up being hampered by the somewhat hidden nature of secretary matching/unmatching. I agree it's a shame to keep reinventing the wheel, but while I like secretary, I've never felt that it's approach was the be all end all. I appreciate some of the sentiment of "if it ain't broke, don't fix it," but more good ideas in the mix only push us all to write better code. Dom, some questions and thoughts for improvement. If you define routes with :path and :query, will the route match/unmatch with undefined query keys? If so, how are they handled? If not, I'd suggest making query matching optional, where nils are substituted. It's a little unclear how your matching functions relate to route. It looks like Silk always breaks at / in path and matches, is that correct? There are some really good things in secretary. What do you think about them? Splat, regex, format matchers. protocol based render function for multiple arity "unmatching." this is really great. and more I'm sure I'm missing -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
