You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is necessary to split the usage of ``CacheMiddleware`` because some additional work should be done on request and response *before* standard caching behavior and that is not possible while using two complete middlewares in either order
159
160
160
161
Reference
161
162
=========
@@ -194,16 +195,19 @@ Reference
194
195
to ``DEFAULT_MOBILE_FLAVOUR`` settings value in case.
195
196
196
197
``django_mobile.cache.cache_page``
197
-
Same as django's ``cache_page`` decorator but applies ``vary_on_flavour``
198
-
before the view is decorated with
199
-
``django.views.decorators.cache.cache_page``.
198
+
Same as django's ``cache_page`` decorator, but wraps the view into
199
+
additional decorators before and after that. Makes it possible to serve multiple
200
+
flavours without getting into trouble with django's caching that doesn't
201
+
know about flavours.
200
202
201
-
``django_mobile.cache.vary_on_flavour``
202
-
A decorator created from the ``CacheFlavourMiddleware`` middleware.
Adds ``X-Flavour`` header to ``response['Vary']`` in ``process_response`` so that Django's ``CacheMiddleware`` know that it should take into account the content of this header when looking up the cached content on next request to this URL.
0 commit comments