Usage: {% load helper_tags %} {% get_available_languages as languages %} {% for lang_code, lang_name in languages %} <link rel="alternate" hreflang="{{ lang_code }}" href="{% change_lang lang_code %}"> {% endfor %}
Converts a passed decorator to one that can be applied to a class based view (ie. automatically decorates dispatch). This means no more overriding dispatch for every view / request method you want to apply decorators to. Works in Django 1.3 but I suspect it probably works in 1.2 as well.
Add this to your apache config: `<Directory /path/to/media> WSGIAccessScript /path/to/access.wsgi </Directory>` Save the snippet as access.wsgi. Set up the paths, and do some authorization checking.
Simple piece of middleware that redirects all requests to **settings.FIRSTRUN_APP_PATH**, until a lockfile is created. Tested on 1.3 only, but I do not believe it requires any special functionality beyond that provided in 1.1 This is useful if you need to force a user to run an installer, or do some configuration before your project can function fully. At first glance, such a thing would generate a lot of hits on the disk. However, once the lockfile has been created, the middleware unloads itself, so when a project is in a production environment, the lockfile is only checked once per process invocation (with passenger or mod_wsgi, that's not very often at all). Once your user has completed your FirstRun app, simply create the lockfile and the project will function as normal. For it to function, the following settings must be configured: * **settings.PROJECT_PATH** - absolute path to project on disk (e.g. */var/www/project/*) * **settings.FIRSTRUN_LOCKFILE** - relative path of the lockfile (e.g. */.lockfile*) * **settings.FIRSTRUN_APP_ROOT** - relative URL of the App you want to FirstRun (eg.*/firstrun/*)
Based on discussion on [http://thebuild.com/blog/2010/12/14/using-server-side-postgresql-cursors-in-django/](http://thebuild.com/blog/2010/12/14/using-server-side-postgresql-cursors-in-django/) and [http://thebuild.com/blog/2010/12/13/very-large-result-sets-in-django-using-postgresql/](http://thebuild.com/blog/2010/12/13/very-large-result-sets-in-django-using-postgresql/) but instead implements them via extending the psycopg2 backend which allows you to use all of django's machinery without having to resort to using raw cursors. Usage: qs = Model.objects.all() with server_side_cursors(qs, itersize=100): for item in qs.iterator(): item.value if random_reason_to_break: break Setup: In your own project create the package hierarchy myproject.db.backends.postgresql_psycopg2 and place the code in base.py. In your settings.py set the database ENGINE to be 'myproject.db.backends.postgresql_psycopg2'. If you using south you'll have to let it know its a postgresql_psycopg2 backend by adding to SOUTH_DATABASE_ADAPTERS (see south documentation). Note: Make sure your using psycopg >= 2.4 for efficient named (server side) cursor iteration.
**You can save these codes into a templatetag file in your django app. Then use codes like these in your template files:** **************************************************************************** {% load *yourtags* %} ... <img src="{% thumb *yourmodel.picturefield* 200 300 0 %}"/> <img src="{% thumb *yourmodel.picturefield* 500 400 yes %}"/> ... The parameters are: imagefield ImageField width Integer height Integer rescale [1, yes, true, 0, no, false] **Some codes come from <djangosnippets.org>**
Generic function to merge model instances. Useful when you need to merge duplicate models together, e.g. for users. Based on http://djangosnippets.org/snippets/382/, with several enhancements: * *Type checking*: only Model subclasses can be used and testing that all instances are of same model class * *Handles symmetrical many-to-may*: original snippet failed in that case * *Filling up blank attrs of original when duplicate has it filled* * *Prepared to use outside of command-line*
Sometimes you want to add CSS classes to HTML elements that are generated by Django using their `__unicode__` representation, eg. you can output a form field with `{{ form.name }}`, but if you would like to add a certain CSS class to the outputted input or select tag you would have to assort to plain HTML. Using this filter you can simply do something like `{{ form.name|add_class:"span-4" }}` which will render an input like `<input type="..." name="..." class="span-4`.
Just like it says -- set it up and run. Use it for server migrations, for project handoffs, in cron jobs, you name it. I have never had problems exporting models to individual fixtures in this way, and only one bout of trouble re-importing them (and that was, like, an impossible-triangle of OneToOneField dependencies anyway, and they were going from a sqlite file to a postgres schema that totally had inappropriate nullable columns in it). I find that the json files named for what they contain is helpful when and if manage.py does freak out during an import, as the output from `loaddata` command is so opaque it's autistic, basically. A trivial refactoring effort could make it into a management command -- it already makes use of the builtin `dumpdata` command class internally. However I did not feel like overthinking it enough to set it up in a repository (doubtlessly padded with unrelated 'utilities' and explanatory .rst files) and then writing a blog post to sell it to you. That is why you are reading this code here, instead of on GitHub. Don't get me wrong, GitHub is awesome, and like a consummate host... but not the way I love me some quick and dirty snippet code, these days. Whatever, you say lazy, I say productively relaxed, potato/potahto. Erm. In any case please do enjoy this model fixture-exporter. Yes.
Code how to save ajax.in a form
This is what I use to send simple status emails from my sites. Instead of a django.core.mail.send_mail call, which can take an irrritatingly, nondeterministically long time to return (regardless of error state), you can stow the emails in the database and rely on a separate interpreter process send them off (using a per-minute cron job or what have you). You then also have a record of everything you've sent via email from your code without having to configure your outbound SMTP server to store them or anything like that. Usage notes are in the docstring; share and enjoy.
Model field that stores serialized value of model class instance and returns deserialized model instance. Example usage: from django.db import models import SerializedObjectField class A(models.Model): object = SerializedObjectField(serialize_format='json') class B(models.Model): field = models.CharField(max_length=10) b = B(field='test') b.save() a = A() a.object = b a.save() a = A.object.get(pk=1) a.object <B: B object> a.object.__dict__ {'field': 'test', 'id': 1}
I never found a good snippet or tutorial to get the app_list (in django.admin) on other pages except the index page. So i started asking on irc j00bar has given me a very nice answer, but first i didn't know what to do with it till now. Anyways this snippet is very handy for the people who wants this but don't know how to get it. This is special made for the django version 1.1 Installation is quite easy, it is a context processor, so download this file put anywhere in your project, i got it in a app called cms_theme (theme and template related stuff.) and put the location in your settings.py file, example: `TEMPLATE_CONTEXT_PROCESSORS = ( 'django.core.context_processors.auth', 'django.core.context_processors.debug', 'django.core.context_processors.i18n', 'django.core.context_processors.media', 'django.core.context_processors.request', '****cms.cms_themes.context_processors.theme', '****cms.cms_themes.context_processors.applist', )` The '****' stuff is nothing, i replaced my company name with it. Of course you may put the context processor anywhere else, that is your choice. Good luck! Alexander
This Snippet allows a view to controle the printed forms on the templates, in a similar way to the fieldsets used by the django admin. How to Use: In the view in question, put: def some_view(request): ... fieldsets = ( (u'Title 1', {'hidden' : ('field_1', 'field_2',), 'fields' : ('field_3',)}), (u'Title 2', {'hidden' : ('field_5', 'field_6',), 'fields' : ('field_4',)}),) ) return render_to_response('some.html', {'fieldsets': fieldsets}) fieldsets = ( (None, {'hidden' : ('evento', 'colaborador',), 'fields' : ('acompanhantes',)}), ) Next, in the html just add: <form enctype="multipart/form-data" id="edit" method="post" ...> ... {% include "inc/form_snippet.html" %} ... <input type="submit" value="Submit"> </form>
This snippet for Piston allows you to offer a choice of authentication methods to clients.