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
Author of bidi here.
In his blog article, REST Litmus Test for Web Frameworks -
https://www.innoq.com/blog/st/2010/07/rest-litmus-test-for-web-frameworks/
- Stefan Tilkov asks of REST libraries:
Is there an easy way to produce links that point back resources
identified by whatever means
On Sat, Apr 11, 2015 at 10:46 AM, Malcolm Sparks malc...@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
This thread over Silk, Bidi and Secretary has been very interesting. I looked
at the three projects to see how they evolved after this thread started. Any
cross-pollination or progress worth sharing now that I've missed?
From what I could gather:
* Secretary is evolving towards a conservative
Thanks both.
On 13 October 2014 04:27, Dom Kiva-Meyer li...@domkm.com wrote:
Thanks for the experience reports, Dylan!
Colin, Silk is Ring-compatible and meant to be used as a single
replacement for both Compojure and Secretary (or any other server/browser
routing combination with
Thanks for the experience reports, Dylan!
Colin, Silk is Ring-compatible and meant to be used as a single replacement
for both Compojure and Secretary (or any other server/browser routing
combination with incompatible syntax and semantics). But, as Dylan said,
it's totally fine to use it in
Thanks for putting that together, Dylan. Looking forward to seeing what
you're building. :)
Olli, please feel free to reach out to me (email, Twitter, GitHub issue,
whatever) if you have any questions. Thanks for trying it out!
On Tue, Oct 7, 2014 at 12:05 PM, Dylan Butman dbut...@gmail.com
Good stuff, Marc! Thanks for the feedback.
That behavior in `composite` is a bug. Thanks for reporting.
Sorting the query map seems reasonable. Good suggestion!
Thanks again, Marc.
On Sat, Aug 9, 2014 at 8:05 PM, marc marc.bosc...@gmail.com wrote:
I've been playing and like Silk a lot!
I'd like to thank everyone in the community for both Silk, and Secretary.
I'll throw out some (uninvited) feature requests I'd love to see in a
future route-matching library.
1) Make trie-based route dispatching possible. A feature pedestal has/will
soon have, is to compile the routing table
Hi Allen,
Thanks for the feedback!
1) This, and precompiling regexes where possible, is my intention with Silk.
2) I'm not convinced that requiring fully-qualified routes would be a
feature. Let's say we have route A which should match /foo/bar and route
B which should match /foo/*. If these
I've been playing and like Silk a lot!
However the following I find curious as I'm wondering what the intended
behaviour should be:
user= (silk/match (silk/composite [user- (silk/integer :id) -fred (silk
/option :this that) s]) user-42-fredjs)
{:id 42, :this j}
user= (silk/match (silk/composite
Thanks for your feedback, Dylan!
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.
I'm not entirely sure what you mean, but I'll give
Hi Joel,
Thanks for your feedback. Off topic, but Garden is awesome and Ankha has
been indispensable when developing Om applications! Thanks for those.
I didn't complain or suggest a patch because, aside from Bidi, I didn't
find a Clojure or ClojureScript routing library that I could conceive of
Dom,
We’re actually well aware of many of the flaws you have pointed out with
Secretary. In fact, we even have open issues for some of them.
While I value all of these features that Secretary lacks, I think that last
one, impurity, is the most significant... Mutation is always possible, but
14 matches
Mail list logo
