| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The "mapping" field that contains the map of elements in the path is now
private and can be accesed via the RouteParams function.
|
| | |
|
| |
|
|
|
|
| |
Instead of letting the matching function creates the response object,
it's created earlier with a default HTTP status of 200, and the object
is passed to the function.
|
| | |
|
| |
|
|
|
|
|
|
| |
`foom` is now the web framework, so the code from mooh.go has been moved
to that repository.
The response and request are handled by the new `web-request` project,
and so the code has been moved to this repository.
|
| |
|
|
|
| |
This is the format supported for URI templates (RFC 6570). We're not
using it now but this is something that I consider for a near future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a route is created with a Default:
&Route{
Path: "/user/:id",
Defaults: map[string]string{
"id": "1",
},
...
}
a request for /user/ will match the route, and set the value for "id" to
1. However, the route /user will not match.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By adding validations, it's possible to create without ambiguity routes
like "/user/:id" and "/user/:name", where the validation for the name
will check that it's an number, and name is a string.
A validation is not required for every key. However, you can't specify
a validation for a key that does not exist in the URL. The validation
use Regexp for now, and the user has to create the regexp with the
function MustCompile.
Some utility functions are added to easily gain information about a
component, validator, etc. This will be extended more soon.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, to create a route, a user would call the AddRoute function,
and pass three arguments (the path, the HTTP method and the function).
This interface is way too limited if we need/want to expand what a route
is in the future.
Instead, we keep calling the AddRoute function to create a route, but
this time the user pass a Route structure. The AddRoute will then
apply a few transformations and connect the route to the router.
|
| |
|
|
|
|
| |
By keeping a map of the HTTP methods available for a given route, we
don't have to iter over a list of executors when we try to find if the
request match, we can quickly check if the methos is set to true.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's no need to split the URL in components every time we call the
Match function on a Route. We can split it once in the dispatcher and
then path the array to the function.
Sadly, this makes the interface a little bit weaker, since we have to
pass the HTTP method and the list instead of the full HTTP Request. I
think in the future we should pass our own HTTP request object, with the
split already in done in this one.
|
| | |
|
| |
|
|
|
|
| |
In the case of an optional components, the name is ":something". We
need to normalize that name in order to be able to call directly
"something" when needed.
|
| | |
|
| |
|
|
|
|
|
|
| |
Forward the http.Request object to the Dispatcher's Match function, and
instead of returning the route that match, return the whole Match
object.
We create our own Request object later in the process.
|
| | |
|
| |
|
|
|
| |
Don't mess with the first / for now, we will see later if we need to
change it.
|
| |
|
|
|
|
|
|
|
| |
For some path, more than one route can match. We try hard to
disambiguate them, and if we can't, we return an error with the list of
routes matching the request.
In order to do that, the Match function needs to be able to also return
an error in addition to a route.
|
| |
|
|
|
|
| |
If a component in the path starts with "?:", it means that it's
optional. We then store the lenght of the components without those
optional parameters.
|
| | |
|
| |
|
|
| |
If a path starts with /, remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a new route, check if the URL contains some elements with
a ":" in it. If that's the case, it means that this component is a
parameter. For now we consider that all the parameters are required,
but in the future we should support optional parameters (starting with a
?).
When dispatching a request, verify if the element in the url is a
parameter and store it in the response.
When a route match a request, a Match structure is returned with some
information (path that matched, the route, the HTTP method, etc.).
|
|
|
For now the framework provide a "dispatcher" and a mechanism to add
routes. The type "route" provide a constructor so some logic can be
applied before creating the type.
The way the dispatcher works for now is very stupid: it looks for all
the registered routes, and check if it's the right HTTP method and if
the patch matches.
The next step is to deal with place holder in the path.
|
