{ "info": { "author": "Gregor M\u00fcllegger, Demodov Dmitry", "author_email": "demidov91@mail.ru", "bugtrack_url": null, "classifiers": [ "Environment :: Web Environment", "Framework :: Django", "Intended Audience :: Developers", "License :: OSI Approved :: BSD License", "Natural Language :: English", "Operating System :: OS Independent", "Programming Language :: Python" ], "description": "=============\ndjango-mobile-threadsafe\n=============\n\n.. _Note!:\nThis is thread safe version of original *django-mobile* package. Use it if you can't gurantee that **python** part of requests processing is served by one thread. Or if you like **explicity** of this package. Apache is not thread safe but you can configure it to use one thread for process and problem of original *django-mobile* will be resolved.\n\n:: _Differense between django-mobile-threadsafe and django-mobile\n1. It holds only ``TemplateResponse`` responses. Syntax is practically the same as for usual ``render_to_response`` but someone may not like it.\n2. You should register separate inclusion tags for mobile version if you want to render other templates with them.\n3. You should declare template names in templatetags explicitly. For example, django-mobile uses ``{% extends base.html %}`` and django-mobile-threadsafe uses ``{% extends mobile/base.html %}`` - that will extend the same mobile/base.html template.\n4. Yes, this is thread-safe.\n\n\nLast thing to remember about is **cashing** - it needs one more middleware and django-mobile's implementation of ``cache_page`` decorator. This is the same as original package have Original package manage it the same way. I've mantioned it only because it influnses on your views, rest of the work is going on in separate template directory.\n\n\n\n.. _introduction:\n\n**django-mobile-threadsafe** 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 make minor changes in views but to transparently\ninterchange the templates used to render a response. This is done in two\nsteps:\n\n1. The request 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 response' middleware takes then care of choosing the correct templates based\n on the flavour detected in the middleware.\n\n**django-mobile-threadsafe** needs your views to return ``TemplateResponse`` objects instead of usual ``HttpResponse`` or shortcut ``render_to_response``. It is easy to change your view to use them::\n\n t = loader.get_template(template_name)\n c = RequestContext(request, some_dictionary_as_context)\n return HttpResponse(t.render(c))\n\nor::\n\n return render_to_response(template_name, some_dictionary_as_context, context_instance = RequestContext(request))\n\nbecomes::\n\n return TemplateResponse(request, template_name, some_dictionary_as_context)\n\n* - Oh! But what about cookies?! I can't set them without response object!* \n - Everything is under control. They are served by ``request.cookies_to_save.add(cookies_dictionary, path='/')`` method with the same middleware as django-mobile.\n\nInstallation\n============\n\n.. _installation:\n\n*Pre-Requirements:* Default implemetation of ``django_mobile`` depends on django's session framework. So before you try to use ``django_mobile`` make sure that the sessions framework is enabled and working.\n\n1. Make sure that all views that will be used by ``django-mobile`` return objects of ``TemplateResponse`` class declared in ``django.template.response``. \n2. Install ``django_mobile`` with your favourite python tool, e.g. with\n ``easy_install django-mobile-threadsafe`` or ``pip install django-mobile-threadsafe``.\n3. Add ``django_mobile.session.SessionMiddleware`` to your\n ``MIDDLEWARE_CLASSES`` setting. Make sure it's listed *after* ``SessionMiddleware``.\n\n\nThats all :) Now 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\n*request* object gets to your views with instansce of **DjangoMobile** class assigned to the ``flavour`` field. You can use this in your views to provide separate logic. It is very usefull to have such methods as request.flavour.**is_mobile**, request.flavour.**is_default** or request.flavour.**get** in your python view. First to methods return boolean value, last one - string, name of the flavour.\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``TemplateResponse('index.html', ...)`` is called with the *mobile* flavour\nbeing active will actually return a response rendered with the\n``mobile/index.html`` template. But if this flavoured template is not\navailable it will gracefully fallback to the default ``index.html`` template only if you was using HttpResponse object instead of TemplateResponse to render that template. I'll try to make TemplateResponse object work in the same way in the next version. \n\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)``. The first argument is self explaining. But keep in mind that 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 \n\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.CacheFlavourMiddleware`` as second last item\nin the ``MIDDLEWARE_CLASSES`` settings, right before\n``FetchFromCacheMiddleware``.\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\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\nFLAVOURS\n^^^^^^^^\n\nA list of available flavours for your site.\n\n**Default:** ``('full', 'mobile')``\n\nDEFAULT_MOBILE_FLAVOUR\n^^^^^^^^^^^^^^^^^^^^^^\n\nThe flavour which is chosen if the built-in ``MobileDetectionMiddleware``\ndetects a mobile browser.\n\n**Default:** ``mobile``\n\nFLAVOURS_TEMPLATE_PREFIX\n^^^^^^^^^^^^^^^^^^^^^^^^\n\nThis string will be prefixed to the template names when searching for\nflavoured templates. This is useful if you have many flavours and want to\nstore them in a common subdirectory.\n\n**Default:** ``''`` (empty string)\n\n\nFLAVOURS_GET_PARAMETER\n^^^^^^^^^^^^^^^^^^^^^^\n\nUsers can change the flavour they want to look at with a HTTP GET parameter.\nThis determines the name of this parameter. Set it to ``None`` to disable.\n\n**Default:** ``'flavour'``\n\n\nSTATIC_URL_MOBILE\n^^^^^^^^^^^^^^^^^\n\nAnalog of django's STATIC_URL. It is good practice to use it your template but not necessary. If you was fond of it on desctop version, take an advatage of it in mobile version too. \n\n**Default:** ``'/media/mobile/'``\n\n\nFLAVOURS_SESSION_KEY\n^^^^^^^^^^^^^^^^^^^^\n\nThe user's preference set with the GET parameter is stored in the user's\nsession by default. This setting determines which session key is used to hold this\ninformation.\n\n**Default:** ``'flavour'``\n\n\nThis is not directly what you want?\n=============\n\n*django-mobile-threadsafe* is implemented as Astract factory with django_mobile.Middleware as creater and django_mobile.DjangoMobile as product. Now it has only one implementation, this is in django_mobile.session. You can always write your own.\n\n\n\nChanglog\n========\n\n0.3\n----\n\n* Internal implementation became threadsafe, usage became more explicit.\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": "UNKNOWN", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/demidov91/django-mobile", "keywords": null, "license": "BSD", "maintainer": null, "maintainer_email": null, "name": "django-mobile-threadsafe", "package_url": "https://pypi.org/project/django-mobile-threadsafe/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/django-mobile-threadsafe/", "project_urls": { "Download": "UNKNOWN", "Homepage": "https://github.com/demidov91/django-mobile" }, "release_url": "https://pypi.org/project/django-mobile-threadsafe/0.3/", "requires_dist": null, "requires_python": null, "summary": "Detect mobile browsers and serve different template flavours to them.", "version": "0.3" }, "last_serial": 790093, "releases": { "0.3": [ { "comment_text": "", "digests": { "md5": "889f41fbb6a413f787ad0176f7bbdf76", "sha256": "fbeeaeb50a25b89fb67e8fc71f2ee6977de6f17ad28dad4691c1c2bb8289c386" }, "downloads": -1, "filename": "django-mobile-threadsafe-0.3.tar.gz", "has_sig": false, "md5_digest": "889f41fbb6a413f787ad0176f7bbdf76", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 11561, "upload_time": "2012-09-27T08:14:03", "url": "https://files.pythonhosted.org/packages/43/bc/aa65060c00dd0bbb26902627c7952fe4d4b6d4b3dabb950aae669e939b76/django-mobile-threadsafe-0.3.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "889f41fbb6a413f787ad0176f7bbdf76", "sha256": "fbeeaeb50a25b89fb67e8fc71f2ee6977de6f17ad28dad4691c1c2bb8289c386" }, "downloads": -1, "filename": "django-mobile-threadsafe-0.3.tar.gz", "has_sig": false, "md5_digest": "889f41fbb6a413f787ad0176f7bbdf76", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 11561, "upload_time": "2012-09-27T08:14:03", "url": "https://files.pythonhosted.org/packages/43/bc/aa65060c00dd0bbb26902627c7952fe4d4b6d4b3dabb950aae669e939b76/django-mobile-threadsafe-0.3.tar.gz" } ] }