检测移动浏览器并为其提供不同的模板风格。
django-mobile-threadsafe的Python项目详细描述
====
django mobile threadsafe
====
请注意！：
这是原始*django mobile*包的线程安全版本。如果您不能保证**python**请求处理的一部分由一个线程提供服务，请使用它。或者如果你喜欢这个包的**明确性**。apache不是线程安全的，但您可以将其配置为使用一个线程进行处理，原始的*django mobile*的问题将得到解决。
：：django mobile thread safe和django mobile之间的区别
1。它只包含"templateresponse"响应。语法实际上与通常的"render-to-response"相同，但可能有人不喜欢它。如果要呈现其他模板，应为移动版本注册单独的包含标记。
3.您应该在templatetags中显式声明模板名称。例如，django mobile使用`{%extends base.html%}`，django mobile threadsafe使用`{%extends mobile/base.html%}``，这将扩展相同的mobile/base.html模板。
4。是的，这是线程安全的。
这和原来的包是一样的，原来的包也有同样的管理方式。我之所以这么说，是因为它会影响到您的视图，其余的工作将在单独的模板目录中进行。
。_简介：
**django mobile threadsafe**提供了一种简单的方法来检测移动浏览器，并提供
您手头的工具来呈现一些不同的模板，以便向用户提供您站点的移动版本。
这样做的目的是对视图进行细微的更改，但要透明地交换用于呈现响应的模板。这分为两个步骤：
1。请求中间件决定客户端查看站点的首选项。例如，如果
他想使用移动风格或完整的桌面风格。
2."template response"中间件会根据中间件中检测到的味道选择正确的模板。
**django mobile threadsafe**需要您的视图返回"templateresponse"对象，而不是通常的"httpresponse"或"shortcut"render到responSE’。很容易更改您的视图以使用它们：
return httpresponse（t.render（c））
or:：
return render_to_response（template_name，some_dictionary_as_context，context_instance=request context（request））
但是饼干呢？！没有响应对象我无法设置它们！*
-一切都在控制之中。它们由"request.cookies"to"u save.add（cookies_dictionary，path='/'）``方法提供，该方法与django mobile具有相同的中间件。
_安装：
*先决条件："`django_mobile`"的默认实现取决于django的会话框架。因此，在尝试使用"django_mobile"之前，请确保会话框架已启用并正常工作。
1。确保"django mobile"将使用的所有视图返回在"django.template.response"中声明的"templateresponse"类的对象。
2。使用您喜爱的python工具安装"django mobile"，例如使用
"easy\u install django mobile threadsafe"或"pip install django mobile threadsafe"。
3.将"django-mobile.session.session middleware"添加到
"中间件类"设置中。确保它在`` sessionmiddleware``之后被列出。
阅读下面的
工作原理，以及可以调整哪些设置来修改**django mobile**的
behAviour.
用法
=
…_口味：
**django mobile**的概念是围绕您网站的不同口味的理念而构建的。例如，*mobile*版本被描述为
一种可能的*风格*，桌面版本被描述为另一种。
这使得提供许多可能的设计成为可能，而不仅仅是
区分完整的桌面体验和一种移动版本。
您可以提供多种移动风格，例如，一种用于iPhone和Android上的移动Safari，另一种用于Opera，另一种用于iPad等平板电脑上的移动Safari。
*注意：*默认情况下，**Django Mobile**只区分*完整*和
*移动*风格。
*请求*对象可以通过分配给"味道"字段的**djangomobile**类的h实例。您可以在视图中使用它来提供单独的逻辑。在python视图中使用request.flavor.**is_mobile**，request.flavor.**is_default**或request.flavor.**get**等方法非常有用。首先返回布尔值，最后返回一个字符串，即味道的名称。
所选模板将在实际要呈现的模板名称前面加上当前味道的前缀
。这意味着，当使用*mobile*flavor调用
`` template response（'index.html'，…）``时，
将实际返回使用
`` mobile/index.html`模板呈现的响应。但是如果这个风格化的模板不可用，那么只有在使用HttpResponse对象而不是TemplateResponse呈现该模板时，它才会优雅地退回到默认的"index.html"模板。在下一个版本中，我将尝试使templateresponse对象以相同的方式工作。
当调用您自己的视图时，通常已经在中间件中选择了正确的味道。在某些情况下，您希望
在您的视图或其他地方更改当前使用的味道。您可以通过简单地调用"django_mobile.set_flavor（flavor）"，来执行此操作。第一个论点是自我解释。但请记住，您只能传递一种您也处于"味道"设置中的味道。否则，"set-flavor"将引发"valueerror"。可选的
``permanent``参数定义是否记住同一客户端的
未来请求的味道变化。
他们只需要在对站点的请求中指定
"flavor"get参数。这将永久地
选择此味道作为他们查看网站的首选项。
风味=完整">；获得完整体验<；/a>；
<；li>；<；a href="？flavor=mobile">；查看我们的移动版本<；/a>；
<；li>；<；a href="？flavor=ipad">；查看我们的ipad版本<；/a>；
<；/ul>；
……_缓存：
django提供了一些方便的方法来轻松缓存您的视图。
其中一个是"django.views.decorators.cache.cache_page"。与**django mobile**一起缓存整个页面的问题是，django的
缓存系统不知道味道。这意味着，如果对一个页面的第一个请求
带有移动风格，第二个请求也可能
从缓存中获取带有移动风格的页面——即使
第二个请求是由桌面浏览器请求的。
**django mobile**也附带了自己的"缓存页面"实现来解决这个问题问题。PL轻松使用"django mobile.cache.cache_page"而不是django自己的"cache_page"装饰器的
您还可以使用django的缓存中间件
"django.middleware.cache.updatecachemiddleware"和
"fetchfromcachemidleware"。但是要让他们知道
的味道，您需要在"中间件类"设置中的第二个最后一项添加
``django-mobile.cache.middleware.cacheflavourmiddleware``作为
第二个项目，就在
``fetchfromcachemidleware``之前。
_定制：
django mobile**的行为可以通过一些点进行定制。这里列出了一些可能性：
设置
---
…_设置：
这里是一个由**django mobile**使用的设置列表，可以在您自己的"settings.py````：
flavours
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^/>
如果内置的MobileDetectionMiddleware检测到移动浏览器，则选择此项。
**默认值：**``Mobile`
如果您有许多风格，并且希望
将它们存储在一个公共子目录中，这将非常有用。
**默认值：*````````（空字符串）
风格获取参数
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
用户可以使用http get参数更改要查看的风格。
这决定了此参数的名称。将其设置为"none"以禁用。
**默认值：*``` flavor``
static_url_mobile
^^^^^^^^^^^^^^^^^^^^^^^^
这是一个很好的做法，使用你的模板，但不是必要的。如果你喜欢Desctop版本的话，也可以在移动版本中使用它。
**默认值：*```'/media/mobile/'```
此设置确定使用哪个会话密钥保存此
信息。
**默认值：*```味道'``
这不是您直接想要的吗？
==
*django mobile threadsafe*作为astract工厂实现，django_mobile.middleware作为creater，django_mobile.djangomobile作为产品。现在它只有一个实现，这是在django_mobile.session中。你总是可以自己写。
changlog
==
>0.3
---
*内部实现变得线程安全，使用变得更加明确。
<0.2.3
----
*fix:set*flavor*在所有情况下，不仅是在检测到移动浏览器的情况下。
感谢John P.Kiffmeyer的报告。
<0.2.2
----
*修复：Android上的Opera Mobile被归类为移动浏览器。感谢
dgerzo提供的报告。
*嗅探ipad，使其不被视为小型移动设备。
感谢ryan showalter提供的修补程序。
0.2.1
----
*修复了不包括django-mobile.cache包的打包问题。
感谢*scott turnbull*提供的报告。
0.2.0
----
*重新调整了项目布局，以从顶级目录中删除settings.py和manage.py。这解决了使用pip的-e选项安装
时的模块名冲突。感谢*bendavis78*提供的报告。
*添加了一个"cache-page"装饰器，它模拟了django的"cache-page"，但
考虑了味道。否则，缓存系统将缓存发生缓存未命中时当前处于活动状态的
味道。感谢
*itmustbejj*的报告。
*Akes Django的缓存中间件
了解味道。我们在内部使用"vary"响应头和"x-flavor"请求头。
0.1.4
----
*修正了模板加载程序中只实现了"加载模板源"而没有"加载模板"的问题。感谢tylanpince，
rwilcox和frédéric roland的报告。
0.1.3
----
*修复了"runserver"命令的问题，该命令没有处理彼此独立的所有请求。感谢bclermont和frédéric roland的
报告。
<0.1.2
----
*修复了"setflavourmiddleware"中的未引用变量错误。
0.1.1
----
*修复的"是可用于"django mobile.loader.loader"的"属性。感谢Michela Ledwidge的报告。
<0.1.0
----
*初次发布。
django mobile threadsafe
====
请注意！：
这是原始*django mobile*包的线程安全版本。如果您不能保证**python**请求处理的一部分由一个线程提供服务，请使用它。或者如果你喜欢这个包的**明确性**。apache不是线程安全的，但您可以将其配置为使用一个线程进行处理，原始的*django mobile*的问题将得到解决。
：：django mobile thread safe和django mobile之间的区别
1。它只包含"templateresponse"响应。语法实际上与通常的"render-to-response"相同，但可能有人不喜欢它。如果要呈现其他模板，应为移动版本注册单独的包含标记。
3.您应该在templatetags中显式声明模板名称。例如，django mobile使用`{%extends base.html%}`，django mobile threadsafe使用`{%extends mobile/base.html%}``，这将扩展相同的mobile/base.html模板。
4。是的，这是线程安全的。
这和原来的包是一样的，原来的包也有同样的管理方式。我之所以这么说，是因为它会影响到您的视图，其余的工作将在单独的模板目录中进行。
。_简介：
**django mobile threadsafe**提供了一种简单的方法来检测移动浏览器，并提供
您手头的工具来呈现一些不同的模板，以便向用户提供您站点的移动版本。
这样做的目的是对视图进行细微的更改，但要透明地交换用于呈现响应的模板。这分为两个步骤：
1。请求中间件决定客户端查看站点的首选项。例如，如果
他想使用移动风格或完整的桌面风格。
2."template response"中间件会根据中间件中检测到的味道选择正确的模板。
**django mobile threadsafe**需要您的视图返回"templateresponse"对象，而不是通常的"httpresponse"或"shortcut"render到responSE’。很容易更改您的视图以使用它们：
return httpresponse（t.render（c））
or:：
return render_to_response（template_name，some_dictionary_as_context，context_instance=request context（request））
但是饼干呢？！没有响应对象我无法设置它们！*
-一切都在控制之中。它们由"request.cookies"to"u save.add（cookies_dictionary，path='/'）``方法提供，该方法与django mobile具有相同的中间件。
_安装：
*先决条件："`django_mobile`"的默认实现取决于django的会话框架。因此，在尝试使用"django_mobile"之前，请确保会话框架已启用并正常工作。
1。确保"django mobile"将使用的所有视图返回在"django.template.response"中声明的"templateresponse"类的对象。
2。使用您喜爱的python工具安装"django mobile"，例如使用
"easy\u install django mobile threadsafe"或"pip install django mobile threadsafe"。
3.将"django-mobile.session.session middleware"添加到
"中间件类"设置中。确保它在`` sessionmiddleware``之后被列出。
阅读下面的
工作原理，以及可以调整哪些设置来修改**django mobile**的
behAviour.
用法
=
…_口味：
**django mobile**的概念是围绕您网站的不同口味的理念而构建的。例如，*mobile*版本被描述为
一种可能的*风格*，桌面版本被描述为另一种。
这使得提供许多可能的设计成为可能，而不仅仅是
区分完整的桌面体验和一种移动版本。
您可以提供多种移动风格，例如，一种用于iPhone和Android上的移动Safari，另一种用于Opera，另一种用于iPad等平板电脑上的移动Safari。
*注意：*默认情况下，**Django Mobile**只区分*完整*和
*移动*风格。
*请求*对象可以通过分配给"味道"字段的**djangomobile**类的h实例。您可以在视图中使用它来提供单独的逻辑。在python视图中使用request.flavor.**is_mobile**，request.flavor.**is_default**或request.flavor.**get**等方法非常有用。首先返回布尔值，最后返回一个字符串，即味道的名称。
所选模板将在实际要呈现的模板名称前面加上当前味道的前缀
。这意味着，当使用*mobile*flavor调用
`` template response（'index.html'，…）``时，
将实际返回使用
`` mobile/index.html`模板呈现的响应。但是如果这个风格化的模板不可用，那么只有在使用HttpResponse对象而不是TemplateResponse呈现该模板时，它才会优雅地退回到默认的"index.html"模板。在下一个版本中，我将尝试使templateresponse对象以相同的方式工作。
当调用您自己的视图时，通常已经在中间件中选择了正确的味道。在某些情况下，您希望
在您的视图或其他地方更改当前使用的味道。您可以通过简单地调用"django_mobile.set_flavor（flavor）"，来执行此操作。第一个论点是自我解释。但请记住，您只能传递一种您也处于"味道"设置中的味道。否则，"set-flavor"将引发"valueerror"。可选的
``permanent``参数定义是否记住同一客户端的
未来请求的味道变化。
他们只需要在对站点的请求中指定
"flavor"get参数。这将永久地
选择此味道作为他们查看网站的首选项。
风味=完整">；获得完整体验<；/a>；
<；li>；<；a href="？flavor=mobile">；查看我们的移动版本<；/a>；
<；li>；<；a href="？flavor=ipad">；查看我们的ipad版本<；/a>；
<；/ul>；
……_缓存：
django提供了一些方便的方法来轻松缓存您的视图。
其中一个是"django.views.decorators.cache.cache_page"。与**django mobile**一起缓存整个页面的问题是，django的
缓存系统不知道味道。这意味着，如果对一个页面的第一个请求
带有移动风格，第二个请求也可能
从缓存中获取带有移动风格的页面——即使
第二个请求是由桌面浏览器请求的。
**django mobile**也附带了自己的"缓存页面"实现来解决这个问题问题。PL轻松使用"django mobile.cache.cache_page"而不是django自己的"cache_page"装饰器的
您还可以使用django的缓存中间件
"django.middleware.cache.updatecachemiddleware"和
"fetchfromcachemidleware"。但是要让他们知道
的味道，您需要在"中间件类"设置中的第二个最后一项添加
``django-mobile.cache.middleware.cacheflavourmiddleware``作为
第二个项目，就在
``fetchfromcachemidleware``之前。
_定制：
django mobile**的行为可以通过一些点进行定制。这里列出了一些可能性：
设置
---
…_设置：
这里是一个由**django mobile**使用的设置列表，可以在您自己的"settings.py````：
flavours
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^/>
如果内置的MobileDetectionMiddleware检测到移动浏览器，则选择此项。
**默认值：**``Mobile`
如果您有许多风格，并且希望
将它们存储在一个公共子目录中，这将非常有用。
**默认值：*````````（空字符串）
风格获取参数
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
用户可以使用http get参数更改要查看的风格。
这决定了此参数的名称。将其设置为"none"以禁用。
**默认值：*``` flavor``
static_url_mobile
^^^^^^^^^^^^^^^^^^^^^^^^
这是一个很好的做法，使用你的模板，但不是必要的。如果你喜欢Desctop版本的话，也可以在移动版本中使用它。
**默认值：*```'/media/mobile/'```
此设置确定使用哪个会话密钥保存此
信息。
**默认值：*```味道'``
这不是您直接想要的吗？
==
*django mobile threadsafe*作为astract工厂实现，django_mobile.middleware作为creater，django_mobile.djangomobile作为产品。现在它只有一个实现，这是在django_mobile.session中。你总是可以自己写。
changlog
==
>0.3
---
*内部实现变得线程安全，使用变得更加明确。
<0.2.3
----
*fix:set*flavor*在所有情况下，不仅是在检测到移动浏览器的情况下。
感谢John P.Kiffmeyer的报告。
<0.2.2
----
*修复：Android上的Opera Mobile被归类为移动浏览器。感谢
dgerzo提供的报告。
*嗅探ipad，使其不被视为小型移动设备。
感谢ryan showalter提供的修补程序。
0.2.1
----
*修复了不包括django-mobile.cache包的打包问题。
感谢*scott turnbull*提供的报告。
0.2.0
----
*重新调整了项目布局，以从顶级目录中删除settings.py和manage.py。这解决了使用pip的-e选项安装
时的模块名冲突。感谢*bendavis78*提供的报告。
*添加了一个"cache-page"装饰器，它模拟了django的"cache-page"，但
考虑了味道。否则，缓存系统将缓存发生缓存未命中时当前处于活动状态的
味道。感谢
*itmustbejj*的报告。
*Akes Django的缓存中间件
了解味道。我们在内部使用"vary"响应头和"x-flavor"请求头。
0.1.4
----
*修正了模板加载程序中只实现了"加载模板源"而没有"加载模板"的问题。感谢tylanpince，
rwilcox和frédéric roland的报告。
0.1.3
----
*修复了"runserver"命令的问题，该命令没有处理彼此独立的所有请求。感谢bclermont和frédéric roland的
报告。
<0.1.2
----
*修复了"setflavourmiddleware"中的未引用变量错误。
0.1.1
----
*修复的"是可用于"django mobile.loader.loader"的"属性。感谢Michela Ledwidge的报告。
<0.1.0
----
*初次发布。
欢迎加入QQ群-->： 979659372
