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 it a shot. Please
provide some example code if I answered the wrong question.
`nil` is a pattern that matches anything. If your URL pattern query is
`nil` then the URL query will not be checked.
A map is a pattern that matches its values against the values of another
map. Therefore, `nil` and `{}` are equivalent when used as a query pattern.
You can make a query value pattern optional by wrapped it with
`silk/option`.
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?
Yes. There is a URL type in Silk and matching is done against instances of
it. The path is represented as a vector of segments.
The readme is currently very deficient and I apologize for that.
There are some really good things in secretary. What do you think about
> them?
> Splat, regex, format matchers.
In terms of regex matching, Silk used to have a built-in regex pattern but
I removed it when I made a big architectural change. I forget why I removed
it, but I'll re-add it since it does seem like a very common requirement.
Currently, part of Secretary's splat exists as a built-in Silk pattern. For
example, `(silk/composite ["foo" :* "bar"])` would match "fooanythingbar"
and return `{:* "anything"}`. The `:*` isn't special; it's just a keyword.
Format is just a specific case of composite: `(silk/composite [:* "."
:format])`. Unlike Secretary, Silk does not have a built-in special syntax
for string patterns. This is because special syntax strings are not
composable and, since Silk matches against unencoded strings, who am I to
say you can't have ":" or "*" in your URL paths? ;)
Looking at the Secretary readme, there appear to be two ways to use splat
that Silk currently does not have built-in support for. In Secretary,
"/foo/*" would match "/foo/bar/baz" and return `{:* "bar/baz"}`. Also,
"/*/*" would match "/a/b" and return `{:* ["a" "b"]}`. I keep saying
"built-in" because, while multi-segment path patterns and binding the same
parameter key to multiple path segments does not currently exist in Silk,
it is very easy to extend Silk with that functionality. You could easily
create a pattern that did exactly what Secretary and Clout do by default
and use it to match a path instead of a vector. However, I do question the
utility of these two features. Are either of these common requirements and,
if so, could I see some examples of why they are necessary or helpful? This
isn't rhetorical; please let me know if Silk is missing something that is
within its scope and is useful to most consumers.
protocol based render function for multiple arity "unmatching." this is
> really great.
I don't think I fully understand the use cases for this protocol. Do you
want to be able to look routes up by types? If so, since route names in
Silk can be anything, you could use a type as a name. Anyway, I put
together this little gist
<https://gist.github.com/DomKM/26658b53a50e48f0be70> of ways in which Silk
could be used similarly to how I *think* someone might use Secretary's
IRenderRoute. Do these cover the use cases for that protocol?
I also agree with everything in Joel's response and look forward to working
with him on improving the routing story. :)
On Thu, Aug 7, 2014 at 2:52 PM, Joel Holdbrooks <cjholdbro...@gmail.com>
wrote:
> I'm in agreement that Silk is a step in the right direction. I've reached
> out to Dom and I think we can learn a lot from each other and work together
> to improve the routing story in Clojure overall.
>
> > 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.
>
> These are definitely nice things and I'm willing to bet Silk would be
> capable of supporting some of them.
>
> It's obvious to me to that if we can iron out the details with Silk,
> Secretary could built on top of it as a higher level interface while at the
> same time taking advantage of what Silk has to offer. It might mean some
> breaking changes in Secretary but those were already slated anyway.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>
--
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.
