This is a breaking change.
This commit introduces `RawStr` to forms. In particular, after this
commit, the `&str` type no longer implements `FromFormValue`, and so it
cannot be used as a field in forms. Instad, the `&RawStr` can be used.
The `FormItems` iterator now returns an `(&RawStr, &RawStr)` pair.
This is a (minor) breaking change. If `rocket.launch()` is the last expression
in a function, the return type will change from `()` to `LaunchError`. A simple
workaround that preserves the previous functionality is to simply add a
semicolon after `launch()`: `rocket.launch();`.
resolves#34
This commit includes the following important API changes:
* The `form` route parameter has been removed.
* The `data` route parameter has been added.
* Forms are not handled via the `data` parameter and `Form` type.
* Removed the `data` parameter from `Request`.
* Added `FromData` conversion trate and default implementation.
* Added `DataOutcome` enum, which is the return type of `from_data`.
* 'FromData' is now used to automatically derive the `data` parameter.
* Moved `form` into `request` module.
* Removed `Failure::new` in favor of direct value construction.
This commit includes the following important package additions:
* Added a 'raw_upload' example.
* `manual_routes` example uses `Data` parameter.
* Now building and running tests with `--all-features` flag.
* All exmaples have been updated to latest API.
* Now using upstream Tera.
This commit includes the following important fixes:
* Any valid ident is now allowed in single-parameter route parameters.
* Lifetimes are now properly stripped in code generation.
* `FromForm` derive now works on empty structs.
* 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.
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?
Sergio Benitez
mikejiang
Sergio Benitez