{
    "info": {
        "author": "calband",
        "author_email": "calband-compcomm@lists.berkeley.edu",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 4 - Beta",
            "Environment :: Web Environment",
            "Framework :: Django",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: BSD License",
            "Natural Language :: English",
            "Operating System :: OS Independent",
            "Programming Language :: Python :: 2.6",
            "Programming Language :: Python :: 2.7",
            "Programming Language :: Python :: 3.3",
            "Topic :: Internet :: WWW/HTTP",
            "Topic :: Internet :: WWW/HTTP :: Dynamic Content",
            "Topic :: Software Development :: Libraries :: Python Modules"
        ],
        "description": "=============\ndjango-mobile\n=============\n\n|build| |package|\n\n.. _introduction:\n\n**django-mobile** provides a simple way to detect mobile browsers and gives\nyou tools at your hand to render some different templates to deliver a mobile\nversion of your site to the user.\n\nThe idea is to keep your views exactly the same but to transparently\ninterchange the templates used to render a response. This is done in two\nsteps:\n\n1. A middleware determines the client's preference to view your site. E.g. if\n   he wants to use the mobile flavour or the full desktop flavour.\n2. The template loader takes then care of choosing the correct templates based\n   on the flavour detected in the middleware.\n\n\nInstallation\n============\n\n.. _installation:\n\n*Pre-Requirements:* ``django_mobile`` depends on django's session framework. So\nbefore you try to use ``django_mobile`` make sure that the sessions framework\nis enabled and working.\n\n1. Install ``django_mobile`` with your favourite python tool, e.g. with\n   ``easy_install django_mobile`` or ``pip install django_mobile``.\n2. Add ``django_mobile`` to your ``INSTALLED_APPS`` setting in the\n   ``settings.py``.\n3. Add ``django_mobile.middleware.MobileDetectionMiddleware`` to your\n   ``MIDDLEWARE_CLASSES`` setting.\n4. Add ``django_mobile.middleware.SetFlavourMiddleware`` to your\n   ``MIDDLEWARE_CLASSES`` setting. Make sure it's listed *after*\n   ``MobileDetectionMiddleware`` and also after ``SessionMiddleware``.\n5. Add ``django_mobile.loader.Loader`` as first item to your\n   ``loaders`` list for ``TEMPLATES`` setting in ``settings.py``.\n6. Add ``django_mobile.context_processors.flavour`` to your\n   ``context_processors`` list for ``TEMPLATES`` setting. You can read more about ``loaders`` and ``context_processors`` in `Django docs`_.\n\n*Note:* If you are using Django 1.7 or older, you need to change step 5 and 6 slightly. Use the ``TEMPLATE_LOADERS`` and ``TEMPLATE_CONTEXT_PROCESSORS`` settings instead of ``TEMPLATES``.\n\nNow you should be able to use **django-mobile** in its glory. Read below of how\nthings work and which settings can be tweaked to modify **django-mobile**'s\nbehaviour.\n\n\nUsage\n=====\n\n.. _flavours:\n\nThe concept of **django-mobile** is build around the ideas of different\n*flavours* for your site. For example the *mobile* version is described as\none possible *flavour*, the desktop version as another.\n\nThis makes it possible to provide many possible designs instead of just\ndifferentiating between a full desktop experience and one mobile version.  You\ncan make multiple mobile flavours available e.g. one for mobile safari on the\niPhone and Android as well as one for Opera and an extra one for the internet\ntablets like the iPad.\n\n*Note:* By default **django-mobile** only distinguishes between *full* and\n*mobile* flavour.\n\nAfter the correct flavour is somehow chosen by the middlewares, it's\nassigned to the ``request.flavour`` attribute. You can use this in your views\nto provide separate logic.\n\nThis flavour is then use to transparently choose custom templates for this\nspecial flavour. The selected template will have the current flavour prefixed\nto the template name you actually want to render. This means when\n``render_to_response('index.html', ...)`` is called with the *mobile* flavour\nbeing active will actually return a response rendered with the\n``mobile/index.html`` template. However if this flavoured template is not\navailable it will gracefully fallback to the default ``index.html`` template.\n\nIn some cases its not the desired way to have a completely separate templates\nfor each flavour. You can also use the ``{{ flavour }}`` template variable to\nonly change small aspects of a single template. A short example:\n\n.. code-block:: html+django\n\n    <html>\n    <head>\n        <title>My site {% if flavour == \"mobile\" %}(mobile version){% endif %}</title>\n    </head>\n    <body>\n        ...\n    </body>\n    </html>\n\nThis will add ``(mobile version)`` to the title of your site if viewed with\nthe mobile flavour enabled.\n\n*Note:* The ``flavour`` template variable is only available if you have set up the\n``django_mobile.context_processors.flavour`` context processor and used\ndjango's ``RequestContext`` as context instance to render the template.\n\nChanging the current flavour\n----------------------------\n\nThe basic use case of **django-mobile** is obviously to serve a mobile version\nof your site to users. The selection of the correct flavour is usually already\ndone in the middlewares when your own views are called. In some cases you want\nto change the currently used flavour in your view or somewhere else. You can\ndo this by simply calling ``django_mobile.set_flavour(flavour[,\npermanent=True])``. The first argument is self explaining. But keep in mind\nthat you only can pass in a flavour that you is also in your ``FLAVOURS``\nsetting. Otherwise ``set_flavour`` will raise a ``ValueError``. The optional\n``permanent`` parameters defines if the change of the flavour is remember for\nfuture requests of the same client.\n\nYour users can set their desired flavour them self. They just need to specify\nthe ``flavour`` GET parameter on a request to your site. This will permanently\nchoose this flavour as their preference to view the site.\n\nYou can use this GET parameter to let the user select from your available\nflavours:\n\n.. code-block:: html+django\n\n    <ul>\n        <li><a href=\"?flavour=full\">Get the full experience</a>\n        <li><a href=\"?flavour=mobile\">View our mobile version</a>\n        <li><a href=\"?flavour=ipad\">View our iPad version</a>\n    </ul>\n\nNotes on caching\n----------------\n\n.. _caching:\n\nDjango is shipping with some convenience methods to easily cache your views.\nOne of them is ``django.views.decorators.cache.cache_page``. The problem with\ncaching a whole page in conjunction with **django-mobile** is, that django's\ncaching system is not aware of flavours. This means that if the first request\nto a page is served with a mobile flavour, the second request might also\nget a page rendered with the mobile flavour from the cache -- even if the\nsecond one was requested by a desktop browser.\n\n**django-mobile** is shipping with it's own implementation of ``cache_page``\nto resolve this issue. Please use ``django_mobile.cache.cache_page`` instead\nof django's own ``cache_page`` decorator.\n\nYou can also use django's caching middlewares\n``django.middleware.cache.UpdateCacheMiddleware`` and\n``FetchFromCacheMiddleware`` like you already do. But to make them aware of\nflavours, you need to add\n``django_mobile.cache.middleware.FetchFromCacheFlavourMiddleware`` item before standard Django ``FetchFromCacheMiddleware``\nin the ``MIDDLEWARE_CLASSES`` settings and ``django_mobile.cache.middleware.UpdateCacheFlavourMiddleware`` before\n``django_mobile.cache.middleware.UpdateCacheMiddleware`` correspondingly.\n\nIt 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\n\nReference\n=========\n\n``django_mobile.get_flavour([request,] [default])``\n    Get the currently active flavour. If no flavour can be determined it will\n    return *default*. This can happen if ``set_flavour`` was not called before\n    in the current request-response cycle. *default* defaults to the first\n    item in the ``FLAVOURS`` setting.\n\n``django_mobile.set_flavour(flavour, [request,] [permanent])``\n    Set the *flavour* to be used for *request*. This will raise ``ValueError``\n    if *flavour* is not in the ``FLAVOURS`` setting. You can try to set the\n    flavour permanently for *request* by passing ``permanent=True``. This may\n    fail if you are out of a request-response cycle. *request* defaults to the\n    currently active request.\n\n``django_mobile.context_processors.flavour``\n    Context processor that adds the current flavour as *flavour* to the\n    context.\n\n``django_mobile.context_processors.is_mobile``\n    This context processor will add a *is_mobile* variable to the context\n    which is ``True`` if the current flavour equals the\n    ``DEFAULT_MOBILE_FLAVOUR`` setting.\n\n``django_mobile.middleware.SetFlavourMiddleware``\n    Takes care of loading the stored flavour from the user's session or\n    cookies (depending on ``FLAVOURS_STORAGE_BACKEND``) if set. Also sets the\n    current request to a thread-local variable. This is needed to provide\n    ``get_flavour()`` functionality without having access to the request\n    object.\n\n``django_mobile.middleware.MobileDetectionMiddleware``\n    Detects if a mobile browser tries to access the site and sets the flavour\n    to ``DEFAULT_MOBILE_FLAVOUR`` settings value in case.\n\n``django_mobile.cache.cache_page``\n    Same as django's ``cache_page`` decorator, but wraps the view into\n    additional decorators before and after that. Makes it possible to serve multiple\n    flavours without getting into trouble with django's caching that doesn't\n    know about flavours.\n\n``django_mobile.cache.vary_on_flavour_fetch`` ``django_mobile.cache.vary_on_flavour_update``\n    Decorators created from the ``FetchFromCacheFlavourMiddleware`` and ``UpdateCacheFlavourMiddleware`` middleware.\n\n``django_mobile.cache.middleware.FetchFromCacheFlavourMiddleware``\n    Adds ``X-Flavour`` header to ``request.META`` in ``process_request``\n\n``django_mobile.cache.middleware.UpdateCacheFlavourMiddleware``\n    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.\n\n\nCustomization\n=============\n\n.. _customization:\n\nThere are some points available that let you customize the behaviour of\n**django-mobile**. Here are some possibilities listed:\n\n``MobileDetectionMiddleware``\n-----------------------------\n\nThe built-in middleware to detect if the user is using a mobile browser served\nwell in production but is far from perfect and also implemented in a very\nsimplistic way. You can safely remove this middleware from your settings and\nadd your own version instead. Just make sure that it calls\n``django_mobile.set_flavour`` at some point to set the correct flavour for\nyou.\n\nIf you need example how tablet detection can be implemented, you can checkout the `middleware.py`_ file in directory `examples`. Feel free to modify it as you like!\n\nSettings\n--------\n\n.. _settings:\n\nHere is a list of settings that are used by **django-mobile** and can be\nchanged in your own ``settings.py``:\n\n``FLAVOURS``\n    A list of available flavours for your site.\n\n    **Default:** ``('full', 'mobile')``\n\n``DEFAULT_MOBILE_FLAVOUR``\n    The flavour which is chosen if the built-in ``MobileDetectionMiddleware``\n    detects a mobile browser.\n\n    **Default:** ``'mobile'``\n\n``FLAVOURS_COOKIE_HTTPONLY``\n    The value that get passed into ``HttpResponse.set_cookie``'s ``httponly``\n    argument. Set this to ``True`` if you don't want the Javascript code to be\n    able to read the flavour cookie.\n\n    **Default:** ``False``\n\n``FLAVOURS_COOKIE_KEY``\n    The cookie name that is used for storing the selected flavour in the\n    browser.  This is only used if ``FLAVOURS_STORAGE_BACKEND`` is set to\n    ``'cookie'``.\n\n    **Default:** ``'flavour'``\n\n``FLAVOURS_TEMPLATE_PREFIX``\n    This string will be prefixed to the template names when searching for\n    flavoured templates. This is useful if you have many flavours and want to\n    store them in a common subdirectory. Example:\n\n    .. code-block:: python\n\n        from django.template.loader import render_to_string\n        from django_mobile import set_flavour\n\n        set_flavour('mobile')\n        render_to_string('index.html') # will render 'mobile/index.html'\n\n        # now add this to settings.py\n        FLAVOURS_TEMPLATE_PREFIX = 'flavours/'\n\n        # and try again\n\n        set_flavour('mobile')\n        render_to_string('index.html') # will render 'flavours/mobile/index.html'\n\n    **Default:** ``''`` (empty string)\n\n``FLAVOURS_TEMPLATE_LOADERS``\n    **django-mobile**'s template loader can load templates prefixed with the\n    current flavour. Specify with this setting which loaders are used to load\n    flavoured templates.\n\n    **Default:** same as ``TEMPLATE_LOADERS`` setting but without\n    ``'django_mobile.loader.Loader'``.\n\n``FLAVOURS_GET_PARAMETER``\n    Users can change the flavour they want to look at with a HTTP GET\n    parameter.  This determines the name of this parameter.  Set it to\n    ``None`` to disable.\n\n    **Default:** ``'flavour'``\n\n``FLAVOURS_SESSION_KEY``\n    The user's preference set with the GET parameter is stored in the user's\n    session. This setting determines which session key is used to hold this\n    information.\n\n    **Default:** ``'flavour'``\n\n``FLAVOURS_STORAGE_BACKEND``\n    Determines how the selected flavour is stored persistently. Available\n    values: ``'session'`` and ``'cookie'``.\n\n    **Default:** ``'cookie'``\n\nCache Settings\n--------------\n\nDjango ships with the `cached template loader`_\n``django.template.loaders.cached.Loader`` that doesn't require to fetch the\ntemplate from disk every time you want to render it. However it isn't aware of\ndjango-mobile's flavours. For this purpose you can use\n``'django_mobile.loader.CachedLoader'`` as a drop-in replacement that does\nexactly the same django's version but takes the different flavours into\naccount. To use it, put the following bit into your ``settings.py`` file:\n\n.. code-block:: python\n\n   TEMPLATES = [\n      {\n         ...\n         'OPTIONS': {\n            ...\n            'loaders': ('django_mobile.loader.CachedLoader', (\n               'django_mobile.loader.Loader',\n               'django.template.loaders.filesystem.Loader',\n               'django.template.loaders.app_directories.Loader',\n            )),\n         }\n      }\n   ]\n\n.. _cached template loader:\n   https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.cached.Loader\n\n.. _middleware.py:\n   examples/middleware.py\n.. _Django docs:\n    https://docs.djangoproject.com/en/dev/topics/templates/#module-django.template.backends.django\n\n.. |build| image:: https://travis-ci.org/gregmuellegger/django-mobile.svg?branch=master\n    :alt: Build Status\n    :scale: 100%\n    :target: https://travis-ci.org/gregmuellegger/django-mobile\n.. |package| image:: https://badge.fury.io/py/django-mobile.svg\n    :alt: Package Version\n    :scale: 100%\n    :target: http://badge.fury.io/py/django-mobile\n\n\nChangelog\n=========\n\n0.8.0 (in development)\n----------------------\n\n* `#68`_: Support recursive template inheritance in django mobile template\n  loader, so that we are compatible with Django's 1.9 admin. Thanks to\n  @wolfg1969 for the patch.\n\n.. _#68: https://github.com/gregmuellegger/django-mobile/issues/68\n\n0.7.0\n-----\n\n* `#64`_: Fixing ``cache_page`` decorator and splitting the\n  ``CacheFlavourMiddleware`` into two middlewares. This follows the same\n  strategy as Django did since quite a while. Please see `#64`_ for more\n  details about why this is necessary.\n\n  If you are using ``CacheFlavourMiddleware``, you need to replace it now with\n  ``FetchFromCacheFlavourMiddleware`` and ``UpdateCacheMiddleware``.  Please\n  consolidate the README for more information.\n\n  Thanks to Yury Paykov for the patch.\n\n.. _#64: https://github.com/gregmuellegger/django-mobile/pull/64\n\n0.6.0\n-----\n\n* `#63`_: Django 1.9 support. Thanks to Alexandre Vicenzi for the patch.\n\n.. _#63: https://github.com/gregmuellegger/django-mobile/pull/63\n\n0.5.1\n-----\n\n* `#58`_: Fix Python 3 install issues related to unicode strings. Thanks to\n  Zowie for inspiring the patch.\n\n.. _#58: https://github.com/gregmuellegger/django-mobile/pull/58\n\n0.5.0\n-----\n\n* Support for Django 1.7 and Django 1.8. Thanks to Jose Ignacio Galarza and to\n  Anton Shurashov for the patches.\n\n0.4.0\n-----\n\n* Python 3.3 compatibility, thanks Mirko Rossini for the patch.\n* Dropping Django 1.3 and 1.4 support.\n\n0.3.0\n-----\n\n* Dropping support for python 2.5 (it might still work but we won't test\n  against it anymore).\n* Fixing threading problems because of wrong usage of ``threading.local``.\n  Thanks to Mike Shultz for the patch.\n* Adding a cached template loader. Thanks to Saverio for the patch.\n\n0.2.4\n-----\n\n* FIX: Cookie backend actually never really worked. Thanks to demidov91 for\n  the report.\n\n0.2.3\n-----\n\n* FIX: set *flavour* in all cases, not only if a mobile browser is detected.\n  Thanks to John P. Kiffmeyer for the report.\n\n0.2.2\n-----\n\n* FIX: Opera Mobile on Android was categorized as mobile browser. Thanks to\n  dgerzo for the report.\n* Sniffing for iPad so that it doesn't get recognized as small mobile device.\n  Thanks to Ryan Showalter for the patch.\n\n0.2.1\n-----\n\n* Fixed packing issues that didn't include the django_mobile.cache package.\n  Thanks to *Scott Turnbull* for the report.\n\n0.2.0\n-----\n\n* Restructured project layout to remove settings.py and manage.py from\n  top-level directory. This resolves module-name conflicts when installing\n  with pip's -e option. Thanks to *bendavis78* for the report.\n\n* Added a ``cache_page`` decorator that emulates django's ``cache_page`` but\n  takes flavours into account. The caching system would otherwise cache the\n  flavour that is currently active when a cache miss occurs. Thanks to\n  *itmustbejj* for the report.\n\n* Added a ``CacheFlavourMiddleware`` that makes django's caching middlewares\n  aware of flavours. We use interally the ``Vary`` response header and the\n  ``X-Flavour`` request header.\n\n0.1.4\n-----\n\n* Fixed issue in template loader that only implemented\n  ``load_template_source`` but no ``load_template``. Thanks to tylanpince,\n  rwilcox and Fr\u00e9d\u00e9ric Roland for the report.\n\n0.1.3\n-----\n\n* Fixed issue with ``runserver`` command that didn't handled all request\n  independed from each other. Thanks to bclermont and Fr\u00e9d\u00e9ric Roland for the\n  report.\n\n0.1.2\n-----\n\n* Fixed unreferenced variable error in ``SetFlavourMiddleware``.\n\n0.1.1\n-----\n\n* Fixed ``is_usable`` attribute for ``django_mobile.loader.Loader``. Thanks Michela Ledwidge for the report.\n\n0.1.0\n-----\n\n* Initial release.",
        "description_content_type": null,
        "docs_url": null,
        "download_url": null,
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://github.com/calband/django-mobile",
        "keywords": "django,mobile",
        "license": "BSD",
        "maintainer": null,
        "maintainer_email": null,
        "name": "calband-django-mobile",
        "package_url": "https://pypi.org/project/calband-django-mobile/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/calband-django-mobile/",
        "project_urls": {
            "Homepage": "https://github.com/calband/django-mobile"
        },
        "release_url": "https://pypi.org/project/calband-django-mobile/0.7.0.dev1/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "Detect mobile browsers and serve different template flavours to them.",
        "version": "0.7.0.dev1"
    },
    "last_serial": 2681431,
    "releases": {
        "0.7.0.dev1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "34ff3e2badd783ec57869448888ac3e3",
                    "sha256": "8daad9d62beb3c42934eb4ca973a5e85fd4f64bddd8df6326b3d601924e7b806"
                },
                "downloads": -1,
                "filename": "calband-django-mobile-0.7.0.tar.gz",
                "has_sig": false,
                "md5_digest": "34ff3e2badd783ec57869448888ac3e3",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 21255,
                "upload_time": "2017-03-03T22:46:02",
                "url": "https://files.pythonhosted.org/packages/7c/cb/8c0a6b367ea96f0e4530c3e7a730eda02a8da5554561b5041675f003fafb/calband-django-mobile-0.7.0.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "34ff3e2badd783ec57869448888ac3e3",
                "sha256": "8daad9d62beb3c42934eb4ca973a5e85fd4f64bddd8df6326b3d601924e7b806"
            },
            "downloads": -1,
            "filename": "calband-django-mobile-0.7.0.tar.gz",
            "has_sig": false,
            "md5_digest": "34ff3e2badd783ec57869448888ac3e3",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 21255,
            "upload_time": "2017-03-03T22:46:02",
            "url": "https://files.pythonhosted.org/packages/7c/cb/8c0a6b367ea96f0e4530c3e7a730eda02a8da5554561b5041675f003fafb/calband-django-mobile-0.7.0.tar.gz"
        }
    ]
}