Skip to content

Commit

Permalink
Clarify changelog for 6.0 and fix docs
Browse files Browse the repository at this point in the history
Add notes to changelog about making parsers more consistent about
checking Content-Type for JSON payloads.
Refactor the 6.0 changelog to better separate into
features/refactoring/bugfixes.

Fix use of autofunction for function definition inclusion in advanced
docs: autofunction only pulls the docstring, not the full function
definition. Instead, just copy the code verbatim.
  • Loading branch information
sirosen committed Nov 23, 2019
1 parent 1d352d2 commit 1d68733
Show file tree
Hide file tree
Showing 2 changed files with 28 additions and 7 deletions.
20 changes: 14 additions & 6 deletions CHANGELOG.rst
Expand Up @@ -4,6 +4,14 @@ Changelog
6.0.0 (unreleased)
******************

Features:

* *Backwards-incompatible*: Schemas will now load all data from a location, not
only data specified by fields. As a result, schemas with validators which
examine the full input data may change in behavior. The `unknown` parameter
on schemas may be used to alter this. For example,
`unknown=marshmallow.EXCLUDE` will produce behavior similar to webargs v5

Refactoring:

* *Backwards-incompatible*: Schema fields may not specify a location any
Expand Down Expand Up @@ -34,17 +42,17 @@ Refactoring:
def foo(q1, q2, h1):
...
* *Backwards-incompatible*: Schemas will now load all data from a location, not
only data specified by fields. As a result, schemas with validators which
examine the full input data may change in behavior. The `unknown` parameter
on schemas may be used to alter this. For example,
`unknown=marshmallow.EXCLUDE` will produce behavior similar to webargs v5

* The `location_handler` decorator has been removed and replaced with
`location_loader`. `location_loader` serves the same purpose (letting you
write custom hooks for loading data) but its expected method signature is
different. See the docs on `location_loader` for proper usage.

Bug fixes:

* *Backwards-incompatible*: all parsers now require the Content-Type to be set
correctly when processing JSON request bodies. This impacts ``DjangoParser``,
``FalconParser``, ``FlaskParser``, and ``PyramidParser``

5.5.1 (2019-09-15)
******************

Expand Down
15 changes: 14 additions & 1 deletion docs/advanced.rst
Expand Up @@ -43,7 +43,20 @@ locations.
The `json_or_form` location does this -- first trying to load data as JSON and
then falling back to a form body -- and its implementation is quite simple:

.. autofunction:: webargs.core.Parser.load_json_or_form

.. code-block:: python
def load_json_or_form(self, req, schema):
"""Load data from a request, accepting either JSON or form-encoded
data.
The data will first be loaded as JSON, and, if that fails, it will be
loaded as a form post.
"""
data = self.load_json(req, schema)
if data is not missing:
return data
return self.load_form(req, schema)
You can imagine your own locations with custom behaviors like this.
Expand Down

0 comments on commit 1d68733

Please sign in to comment.