Werkzeug Documentation

# Werkzeug

# Extra Wrappers

Extra wrappers or mixins contributed by the community. These wrappers can be mixed in into request objects to add extra functionality.

Example:

    from werkzeug import Request as RequestBase
    from werkzeug.contrib.wrappers import JSONRequestMixin

    class Request(RequestBase, JSONRequestMixin):
        pass

Afterwards this request object provides the extra functionality of the `JSONRequestMixin`.

class `werkzeug.contrib.wrappers.` `JSONRequestMixin`

  Add json method to a request object. This will parse the input data through simplejson if possible.

  `BadRequest` will be raised if the content-type is not json or if the data itself cannot be parsed as json.

  `json`
    Get the result of simplejson.loads if possible.

class `werkzeug.contrib.wrappers.` `ProtobufRequestMixin`

  Add protobuf parsing method to a request object. This will parse the input data through protobuf if possible.

  `BadRequest` will be raised if the content-type is not protobuf or if the data itself cannot be parsed property.

  `parse_protobuf`(proto_type)
    Parse the data into an instance of proto_type.
  `protobuf_check_initialization`
    by default the `ProtobufRequestMixin` will raise a `BadRequest` if the object is not initialized. You can bypass that check by setting this attribute to False.

class `werkzeug.contrib.wrappers.` `RoutingArgsRequestMixin`

  This request mixin adds support for the wsgiorg routing args specification.

  `routing_args`
    The positional URL arguments as tuple.
  `routing_vars`
    The keyword URL arguments as dict.

class `werkzeug.contrib.wrappers.` `ReverseSlashBehaviorRequestMixin`

  This mixin reverses the trailing slash behavior of `script_root` and `path`. This makes it possible to use `urljoin()` directly on the paths.

  Because it changes the behavior or `Request` this class has to be mixed in before the actual request class:

      class MyRequest(ReverseSlashBehaviorRequestMixin, Request):
          pass

  This example shows the differences (for an application mounted on /application and the request going to /application/foo/bar):

  > | normal behavior | reverse behavior
  > --- | --- | ---
  > script_root | `/application` | `/application/`
  > path | `/foo/bar` | `foo/bar`

  `path`
    Requested path as unicode. This works a bit like the regular path info in the WSGI environment but will not include a leading slash.
  `script_root`
    The root path of the script includling a trailing slash.