On Saturday, April 11, 2015 at 8:40:07 AM UTC-7, kovas boguta wrote: > On Sat, Apr 11, 2015 at 10:46 AM, Malcolm Sparks <mal...@juxt.pro> > > So, in summary, I think it would be useful to have a single 'default' routing > library in Clojure that supported isomorphism and was built on protocols, as > a minimum. Now that Clojure is attracting so many new users, it would be > great to discuss the outstanding differences between all the routing > libraries and try to drive some consensus as to what a combined library would > include. > > > I'm on board with most of this post (and the Bidi approach in particular), > I'm not sure consensus is necessary but I'll throw in my 2 cents. > > > - Please, no more defroute etc macros > - Routing should be composable. I want to take some routes and just plug them > in at some level of my existing hierarchy. > - Middleware should be decoupled from the routes as much as possible. The > process for associating middleware to the request should be > parallel/complementary to resolving the resource. Maybe "middleware" is not > the best concept to begin with. >
I'm definitely in agreement that the approach Bidi and Silk have taken is much better than what exists on master in Secretary. Most of the undesirable aspects pointed out about Secretary have largely been resolved on the 2.0.0 branch for Secretary. The other desirable qualities found in Silk (unsure about Bidi) have been in existence in Secretary for sometime but the library was not oriented properly to make those features "idiomatic". I do not agree that "defroute etc macros" should be eliminated from the picture. There is nothing inherently wrong with authoring and/or encouraging their use. It is only an issue when those macros are the only way to use a library effectively. People enjoy using DSL's (until they hit a wall with them) and for small to medium scale projects they are completely appropriate and just as effective as the "it's just data" style of routing for "getting shit done." I will also say the same about middleware. Although I do not like the middleware pattern I do not believe it is worth throwing out the window just because it is "not the best concept." It is a familiar pattern and sometimes that familiarity is worth avoiding the friction of learning a something else for some individuals and teams. tl;dr retaining features that people enjoy using and are familiar with is fine so long as there is a composable API underneath it that can be used alternatively. -- 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.
