* All From* trait methods are now named like the trait.
* All From* traits have an associated Error type.
* Document all of the `form` module.
* Add codegen tests for auto-derived forms.
* The param parsing traits now live under Request.
* Add content-type responsers for JSON, HTML, and plain text.
* Use content-type responders in content_type example.
* Conditionally create Request `from` HypRequest.
* Clean-up dispatching and handling in main rocket.
* Change Level enum to Logging Level and reexport.
* Allow users to set logging level before launch.
* Fix content_type example error handling.
* Percent decode params when user requests `String`.
The error function now takes in a "RoutingError" structure. The idea is that the
structure includes all of the information necessary for a user to processor the
error as they wish. This interface is very incomplete and may change. At a
minimum, the error structure should include:
1) The request that failed.
2) Why the request failed.
3) The chain of attempted route matches, if any.
4) Something else?
A few important things needs to get this to be 'right':
1a. Have a way to return a response with a status code.
1b. Use that mechanism in the default catchers.
2. Automatically fill in that code from the #[error] handler.
3. Have a way for a responder to say if responding succeeded.
4. Try next highest ranking route if responding with one handler fails.
Added `error` decorator and `errors` macro.
The current idea is that you can have "catchers" for all valid errors code (in
range [400, 500). At the moment, catchers are just request handlers, and the
decorator expected an empty function signature for the error handler. Obviously,
this is pretty useless. Not sure on what the API should be here. But, progress.
Oh, one more thing: who should handle forwarding a request to a catcher?
Probably not the router. So, the main Rocket should?
Here's the idea: under the `Rocket` namespace should live things critical to
writing simple Rocket apps: Request, Response, Error, etc. Nothing should be
nested more than one level deep. Only items required for more complex things
(implementing uncommon traits, etc.) should be nested one level deep.
This commit is the first attempt at realizing this.