Sometimes we need to build a ChoiceField from data in a Model or more than just one model via fk's but the ModelChoiceField is not *that* flexible. So, in order to obtain a list of tuples with pk and a descriptive text for the choices parameter of the ChoiceField use this little function.
Allows Amazon S3 storage aware file fields to be dropped in a model. Requires the boto library.
Based on http://www.djangosnippets.org/snippets/592/, a simplified recurse template tag that will explore dict and list objects. Useful and straightforward for JSON documents (for instance from couchdb :p). Actual usage example: {% recursedict mydictionary %} <ul> {% loop %} <li>{% if key %}<b>{{ key }}</b>: {% endif %}{% value %}</li> {% endloop %} </ul> {% endrecurse %} The main tag syntax is "recursedict var" where var is your dictionary name. The "key" property will contain the current key, or None if the current value comes from a list (in other words the list (a, b, c) is handled like a very hypothetical {None: a, None: b, None: c} dictionary.) {% value %} will output the current value, or recurse if the value is a list, tuple or dict.
Put this in a base.py file. And config this settings: DATABASE_ENGINE = 'path.to.module.with.base.file' DATABASE_STATEMENT_TIMEOUT = 60000 # milliseconds (Idea from: http://www.mailinglistarchive.com/html/[email protected]/2009-02/msg00024.html)
Django loads tests found in models.py and tests.py (if present) or actually a module or package named 'tests' under the app. Since tests can be a package, one can create a 'tests' directory, split the test cases across multiple files under 'tests' and import them from tests/__init__.py with: # tests/__init__.py from test_mod1 import * from test_mod2 import * ... from test_modN import * For a small number of files that's not too bad but it gets old as more files are added, plus it is error prone (e.g. test cases shadowing others with the same name). The snippet above simplifies the test splitting without importing everything into the same namespace. Typical usage: # tests/__init__.py from ... import get_suite suite = lambda: get_suite(__name__)
This is a django view that can return a PDF made using rml2pdf from reportlab. This RML is written with django templating system, to view the rml code and download a fully working version visit [reportlab](https://www.reportlab.com/software/documentation/sample-projects/rml-with-django/)
This is a quick hack to address the SSL info leakage covered here: http://www.freedom-to-tinker.com/blog/felten/side-channel-leaks-web-applications Don't use this in prod without testing. :-) I'll get some feedback from django-dev and update here.
Generate model data with this django management command! Data is generated based off of the model field types. And will also correctly generate foreign key's to other randomly generated records for join tables. And generate images with random colors and random words in the image - for image fields. You can supply quite a few parameters that control how the data is generated. And you can control it per field, per model. Or you can supply your own callable function which you can return your own random data. **SEE THE DOCS / EXAMPLE IN THE CODE SNIPPET FOR AVAILABLE OPTIONS, AND HOW TO CONTROL GENERATED DATA PARAMETERS** You can generate data that looks like real content, without having to write fixtures and such. Just generate it! It can generate data for these types of fields: EmailField SlugField BooleanField DateField DateTimeField TimeField IntegerField DecimalField TextField CharField IPAddressField URLField SmallIntegerField PositiveSmallIntegerField PositiveIntegerField ImageField There are also a few callables included that you can use to generate this kind of data: zip, extended zip, hashkey and uuid It's also worth noting that I keep this project up to date on my own git repository. There are a few fonts you'll need if you want to generate imaages, included in my git repo. http://gitweb.codeendeavor.com/?p=dilla.git;a=summary
This is a ModelChoiceField where the choices are rendered in optiongroups (this is already posible with a normal Choicefield) For this to work properly the queryset you supply should already be ordered the way you want (i.e. by the group_by_field first, then any sub-ordering) See [related blog article](http://anentropic.wordpress.com/2010/03/23/django-optiongroups-for-your-modelchoice-field/)
Serves images from a local directory, but if it doesn't find it locally, then go look for it on a server. This is useful for sites with very large amounts of static content. Instead of copying all your prod images to dev every time you update the database, simply use this in your URL patterns to serve the images: `(r'^(?P<path>.*)$', 'static_fallback.serve', {'document_root' : '/path/to/my/files/'})` By default, it caches the images locally in the path it was supposed to find them. The fallback server URL can be specified in urls.py or settings as FALLBACK_STATIC_URL. Thanks to Johnny Dobbins for the idea. Based on the Nginx pass through image proxy concept. For more info [http://menendez.com/blog/using-django-as-pass-through-image-proxy/](http://menendez.com/blog/using-django-as-pass-through-image-proxy/)
You can specyfy max width and height which image can have, and it never exceed that size.
This template tag attempts to get specific GET variables from request.GET. If such variables exist, it shows them as a query string (with optional "include_ampersand" mode when it puts an "&" at the end if there is a result string, or a "?" if there's none: it is used when you need to add a new variable to the query string) or as hidden input fields ("html_form" mode).
In principle it's a DRY code of a template node that can be used for creating project-wide template-tags. These can be used to display conceptually common blocks in templates with applications specific looks and content. E.g.: 1. application-specific info message, 2. model instances details in the list context, 3. login messages like 'Please login or signup to [some app-dependent text]' with appropriate url's, 4. standard forms (e.g with same CSS classes, displayed with uni_form). The code is profusely commented so look it up for details. Basically, when you have your project-wide `SubIncludeNode` tag defined, then just define appropriately named templates in applications template subdirectories e.g. `'profiles/_show_item.html'`. ** Example usage: login or signup message ** Let's say we are editing template rendered by the view indicated by the pattern named 'project_list' in the 'projects' app: {# those are equivalent #} {% login_or_signup %} {% login_or_signup project_list %} {% login_or_signup "project_list" %} {# academic purposes direct sub_include usage #} {# those two includes are also equivalent if there is no template called '_login_or_signup.html' in the 'projects' subdirectory #} {% url acct_signup as signup_url %} {% url acct_login as login_url %} {% url project_list as next_url %} {% sub_include "_login_or_signup.html" %} {% include "_login_or_signup.html" %} {# and those two are also equivalent if there is a template called '_login_or_signup.html' in the 'projects' subdirectory #} {% sub_include "_login_or_signup.html" from "projects" %} {% sub_include "_login_or_signup.html" %} {# also equivalent include if there is no variable called 'projects' in tempalte's context #} {% sub_include "_login_or_signup.html" from projects %} {# those are examples of using custom subcontext #} {% url acct_signup as signup_url %} {% url acct_login as login_url %} {% sub_include "_login_or_signup.html" from "default" with login_url,signup_url,next_url="/welcome" %} {% sub_include "_login_or_signup.html" with login_url="/login",next_url="/welcome",signup_url="/signup" %} ** Mored advanced usage proposal ** Say you have an subclasses of some model from the original app in a separate extending apps. You want to display subclasses instances differently using the original app templates. In the original app you do not know what the set of subclasses is (as the original app is not aware of the extending apps). Subclassing the `SubIncludeNode` you can override the `default_subdir` method such that it returns the app label of a model instance that was passed as a argument of your tag. This way you just put templates like `_show_instance.html` in extending apps subdirectories and voila - you have implementation of the overrideable templates displaying appropriately details about the model subclass instances.
A simple django-admin filter to allow a boolean-like filter for IS NULL/IS NOT NULL. By default it applies to CharField, IntegerField, and FileField, but you can change this by editing NullFilterSpec.fields.
Based on #1381 Use this piece of code to add IPv4/IPv6 and network support to Django. An IPAddressField allows you to find IP's for a given subnet. An IPNetworkField allows you to find a subnet for a given IP or find a subnet within a subnet. For starters, simply paste it into a new file in your app called fields.py. IPAddressField example # models.py from fields import IPAddressField class IPTest(models.Model): ip = IPAddressField() To search for an IP within a given subnet from ipaddr import IPNetwork IPTest.objects.filter(ip__in=IPNetwork('10.0.0.0/24')) IPNetworkField example # models.py from fields import IPNetworkField, IPNetworkQuerySet class IPTest(models.Model): objects = IPNetworkQuerySet.as_manager() network = IPNetworkField() To search for a subnet with a given IP from ipaddr import IPAddress IPTest.objects.network('network', IPAddress('10.0.0.1'))