### Navigation

- index
- modules |
- next |
- previous |
- Werkzeug 0.8.3 documentation »
- Contributed Modules »

# 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.wrappers 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` = True

    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.

class `werkzeug.contrib.wrappers.``DynamicCharsetRequestMixin`

  “If this mixin is mixed into a request class it will provide a dynamic charset attribute. This means that if the charset is transmitted in the content type headers it’s used from there.

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

      class MyRequest(DynamicCharsetRequestMixin, Request):
          pass

  By default the request object assumes that the URL charset is the same as the data charset. If the charset varies on each request based on the transmitted data it’s not a good idea to let the URLs change based on that. Most browsers assume either utf-8 or latin1 for the URLs if they have troubles figuring out. It’s strongly recommended to set the URL charset to utf-8:

      class MyRequest(DynamicCharsetRequestMixin, Request):
          url_charset = 'utf-8'

  New in version 0.6.

  `charset`

    The charset from the content type.

  `default_charset` = 'latin1'

    the default charset that is assumed if the content type header is missing or does not contain a charset parameter. The default is latin1 which is what HTTP specifies as default charset. You may however want to set this to utf-8 to better support browsers that do not transmit a charset for incoming data.

  `unknown_charset`(charset)

    Called if a charset was provided but is not supported by the Python codecs module. By default latin1 is assumed then to not lose any information, you may override this method to change the behavior.

    Parameters: | charset – the charset that was not found.
    Returns: | the replacement charset.

class `werkzeug.contrib.wrappers.``DynamicCharsetResponseMixin`

  If this mixin is mixed into a response class it will provide a dynamic charset attribute. This means that if the charset is looked up and stored in the Content-Type header and updates itself automatically. This also means a small performance hit but can be useful if you’re working with different charsets on responses.

  Because the charset attribute is no a property at class-level, the default value is stored in default_charset.

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

      class MyResponse(DynamicCharsetResponseMixin, Response):
          pass

  New in version 0.6.

  `charset`

    The charset for the response. It’s stored inside the Content-Type header as a parameter.

  `default_charset` = 'utf-8'

    the default charset.