feat(server): shared data between requests and plugins for Response #280
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This can be used to add some compile time dependencies for Middleware and Plugins. You can add bounds to `D` in the above to place compile-time restrictions on the server data (can be used for configuration). BREAKING CHANGE There is a default for the type-param to help mitigate breakage, but some code will probably still be significantly broken by this. To fix code broken by this, you will need to introduce a type parameter for various nickel types including: Request, Response, Middleware, MiddlewareResult and NickelError. ``` // e.g. This: fn foo<'mw>(&mut Request, Response<'mw>) -> MiddlewareResult<'mw> // Should become: fn foo<'mw, D>(&mut Request<D>, Response<'mw, D>) -> MiddlewareResult<'mw, D> // Or you can use a concrete type: fn foo<'mw>(&mut Request<MyType>, Response<'mw, MyType>) -> MiddlewareResult<'mw, MyType> ```
Also adds `on_send` which can be used to execute code when the Response headers are being sent.
|
Pushed cookies to https://github.com/nickel-org/cookies Will push session later after I've cherry-picked from old branch, have to head out for a bit first! |
|
👍 awesome. Can't wait for it to land :) |
== r+ ? 🙈 (Let homu know if so!) |
|
Let's do it :) @homu r+ |
|
📌 Commit fc35544 has been approved by |
homu
added a commit
that referenced
this pull request
Sep 10, 2015
feat(server): shared data between requests and plugins for Response I've ripped out the core from #272 and decided we should just push separate crates for now until the implementation for Session/Cookies has settled. This allows more breaking changes to the session/cookies implementations as we experiment without requiring a load of version bumps to nickel itself. It's more work for us to manage, but should be better for users 👍 I've also added a default type for the typeparam, so breakage in client crates should be minimal (until they start using the dataparam!) and only really affect people who've written library level stuff. r? @cburgdorf @simonpersson
|
☀️ Test successful - status |
This was referenced Sep 10, 2015
feat(nickel): add options to Nickel, allowing the user to disable the messages output on listen
#277
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've ripped out the core from #272 and decided we should just push separate crates for now until the implementation for Session/Cookies has settled. This allows more breaking changes to the session/cookies implementations as we experiment without requiring a load of version bumps to nickel itself. It's more work for us to manage, but should be better for users 👍
I've also added a default type for the typeparam, so breakage in client crates should be minimal (until they start using the dataparam!) and only really affect people who've written library level stuff.
r? @cburgdorf @simonpersson