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'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).
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 ".
> 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))
On 04/04/2016 10:33 PM, Brian Adkins wrote:
On Apr 4, 2016, at 3:44 PM, antoine <antoine.br...@sfr.fr> wrote:
Hello,
I would go for 'methods instead of 'verbs, a HTTP vocabulary instead of a REST
one.
Fair point. I suppose a couple additional characters won't kill me.
For the pathinfo:
When using a string you use :pattern as place holder as far as i know there is
no such convention in racket, maybe you should explore ~pattern (like format),
#:pattern, 'pattern, #'pattern (like macro templating) or at-expr?
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.
For constraints on placeholders you may want to limit them to regexp because:
1. 99.999% of the time they will satisfy the developer needs.
2. You give you room to make your router fast implementing a minimal final
state machine (a regexp).
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?
I probably didn't communicate very well with my example, but when I first
started thinking about constraints, I assumed I'd follow the Rails idea of an
elaborate construct to declare all the constraints, but then I thought that
using a single lambda to indicate whether the route matched might be better. I
figured syntax sugar can be added later for common cases. For example:
("/:org_shortname/product_image/:style/:filename" product-image
#:methods get
#:when verify-filename)
(define (verify-filename params)
(regexp-match #rx".jpg$" (hash-ref params 'filename)))
or
("/:org_shortname/product_image/:style/:filename" product-image
#:methods get
#:when verify-filename-and-style)
(define (verify-filename-and-style params)
(and
(regexp-match #rx".jpg$" (hash-ref params 'filename))
(exact-integer? (hash-ref params 'style))))
example:
("/~org-shortname/product_image/~style/~filename"
#:method POST
#:constraints ([filename ".*\\.xml$"])
;; a guard that break optimisations and expand
#:when (not (equal? "abc" org-shortname))
#:controller my-controller)
I'm not sure what you're suggesting here. Is your idea to provide both
#:constraints and #:when ?
Or maybe use a list like dispatch-rule
((org-shortname "product_image" style filename)
#:method POST
#:constraints ([filename ".*\\.xml$"])
;; a guard that break optimisations and expand
#:when (not (equal? "abc" org-shortname))
#:controller my-controller)
The list style might disallow something like:
"/product/item-:id" e.g. /product/item-473
or
"/products/(*id).json" e.g. /products/foo/bar/baz.json => id = 'foo/bar/baz'
On 04/04/2016 08:08 PM, Brian Adkins wrote:
I've been looking into an appropriate syntax for routing web requests. For each
route, I'll need the following information:
* URL Pattern (required) e.g.
"/"
"/:org_shortname/product_image/:style/:filename"
"/:org_shortname/products/(*id).json"
* Function to handle request (required)
* Accepted HTTP verbs (optional, defaults ot all)
* Name (optional) - used to do "reverse routing" i.e. produce a URL from
parameters
* Contraints (optional) - further refine the pattern matching e.g. type/format
of params
Here's an example from Rails:
Foo::Application.routes.draw do
match "/:org_shortname/product_image/:style/:filename" =>
'product_images#product_image',
:as => :product_image, :via => :get, :constraints => { :filename =>
/.jpg$/ }
# URL pattern: "/:org_shortname/product_image/:style/:filename"
# Function: ProductImagesController.product_image
# Name: :product_image
# Verbs: GET
# Contraints: filename param must end in .jpg
match '/products/(*id).json' => 'products#show', :via => :get
# URL pattern: '/products/(*id).json'
# (*id) globs everything between /products/ and .json including / chars
# Function: ProductsController.show
# Verbs: GET
end
There are many other aspects (much of which is just syntax sugar) of routing in
Rails that I'm ignoring initially.
I'm thinking of something like the following:
(routes
("/" home-page)
("/:org_shortname/product_image/:style/:filename" product-image #:verbs (get)
#:name prod-image #:when (regexp-match #rx".jpg$" filename))
("/products/(*id).json" product-show #:verbs (get)))
The first two arguments (url-pattern function) are required, so they're
positional. The optional arguments are specified with keywords.
Instead of: #:verbs (get) would it be better to have #:verbs get and
dynamically check for an atom vs. list ?
My initial goal is just for the "base" syntax. Sugar can be added later for
some cases.
Any feedback is appreciated.
Thanks,
Brian
--
You received this message because you are subscribed to a topic in the Google Groups
"Racket Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/racket-users/wZ07AM8SBuw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
