> On Apr 5, 2016, at 6:51 AM, antoine <antoine.br...@sfr.fr> wrote: > > > I'm open to other ideas, but :variable is used in a number of routing > > string patterns in other languages/frameworks and seems fairly standard. > > My point was being standard with other racket work not other web framework.
I'd like to stick to at most one prefix character, but ~ is a possibility. > > I'm not sure I understand how > *limiting* the constraint to be a regex is faster than *allowing* > the constraint to be a regex i.e. in either case, the URL needs to be parsed > and then a function called > to compare a variable to a regex pattern. Am I > misunderstanding? > > The point is to make the routing use something like > https://swtch.com/~rsc/regexp/regexp1.html to match a route, and thus can be > done only if placeholder are regexp and not an arbitrary racket expression. > (That is where the #:when comes if you can't express you constraints with > regexp you could use a guard). I see. I suspect that constraint checking is nowhere near the critical path, but I'll do some performance testing once I have some code implemented. One option would be to start with the more general guard, and if warranted, I could add a more specific constraint that's required to be a regex. > Using a list for expressing the pathinfo is the less limiting you can express > "/product/item-:id" as ("product" ["item-" id]). > Antoher point you can use a symbol instead of a string removing the two ". It's something to keep in mind, but I prefer typing "/product/item-:id" and it seems more readable as I'm scanning a long list of routes since it more closely matches the actual URL. > > That should be able to be checked at compile time via a macro, right? > > It want something like: > > "/some/route/:param" > #:when (equal? "abc" param) > > instead of #:when (equal? "abc" (hash-ref some-predefine-binding "param")) > > so it will exepand to something like: > > (let ([param (hash-ref parameters "param")]) > (equal? "abc" param)) I'll keep that in mind as I continue. I like being able to see the guard expression directly in the route as in the above, and I suspect the guard will always be limited to an expression referencing the parameters, so passing a more general lambda may not buy me much in terms of flexibility. Thanks for the feedback! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
