Login

All snippets written in Python

2957 snippets

Snippet List

Binding pre-existing tables with dynamically created class models

This snippet proposes a solution for pre-exisiting database tables that have no counterpart in your django application models.py module. My use case was a comercial systems where pricing tables were created on-the-fly as a result of a stored procedure's execution inside the database. These pricing tables had no counterpart class model. Therefore, to access these tables from Python code you had to bypass Django's ORM and use plain-old SQL through cursos.execute(). This snippet's strategy is to create a (model) class on the fly and inject that class inside models.py namespace. After that you can use the generated class and Django's ORM machinery to access the tables, as if they were created by syncdb.

  • orm
  • dynamic-model
Read More

Random code tag

This tag solves for me a simple need: generate random and compact codes for some of my applications. Codes are not guaranteed to be unique. **Usage** {% randomCode "num" %} **Example**: {% randomCode "8" %} generates a random 8 characters code. Create a file on your favorite template tags folder called randomcode.py and paste the code. Don't forget to include {% load randomcode %} in your templates

  • tag
Read More

BabelMiddleware

Originally posted on [skam.webfactional.com](http://skam.webfactional.com/blog/2007/07/16/babel-integration-django/) This is a very simple middleware that uses babel (http://babel.edgewall.org) for accessing locale data in request objects through request.LOCALE attribute. It also provides a function to get locale data outside views. settings.py: MIDDLEWARE_CLASSES = ( ... cut ... 'django.middleware.locale.LocaleMiddleware', 'middleware.locale.BabelMiddleware', ... cut ... )

  • middleware
  • i18n
  • l10n
  • locale
  • babel
Read More

DefaultValueWidget

Can be used if a form field should not be editable, but the current value or the value that will be automatically used should still be visible to the user. __init__ takes two additional parameters: **value** is the actual value to be used when saving the form, while **display** determines what is shown to the user when rendering. If *display* is not specified, *value* itself will be used instead. If *display* is a *ModelChoiceField*, *value* is assumed to be a primary key of the model, and the widget will automatically try to retrieve and use the string representation of the corresponding item.

  • newforms
  • forms
  • widgets
  • widget
Read More

"Approved" field with timestamp

I wanted to make the objects of a particular model approvable and store the timestamp of when that happened. In other frameworks/languages, I used to combined those in one "approved_at" field, which would be NULL if an object was currently unapproved. I tried different approaches to implement this in django, and this is the best I came up with so far. Basically, the code in __setattr__ makes sure that the field, once set, will not be updated again. Overriding setattr__() could also be a solution to determining if a field value has changed in save(), a question that seems come up from time to time in #django.

  • newforms
  • models
  • fields
  • forms
  • save
Read More

Pass db.Field to newforms.Widget

Deprecated. I don't use this any more. Hi, I want decimal input which uses a comma as decimal seperator. It was quite complicated, but it works. It can be used as an example how to create an own subclass of an existing db.Field class and how to pass the dbfield to the widget, and use it in its render() method. I think my snippet is too complicated, but couldn't find a better solution. If you do, please tell me.

  • newforms
  • i18n
Read More

sqlallall.py

A simple script to run 'manage.py sqlall' on every app in a project.

  • sql
  • manage.py
  • sqlall
Read More
Author: jkl
  • 0
  • 2

UUIDField

UUIDField is a field which stores an uuid generated by pythons new uuid module. it's included with the python 2.5 distribution by default, but if you run an older version of python you can happily copy the file from 2.5 to django/utils/uuid.py or your project directory.

  • fields
  • field
  • uuid
Read More

Validation for 'unique' and 'unique_together' constraints (different version)

This is a slightly different and extendend version of this snippet: http://www.djangosnippets.org/snippets/260/ Unique constraints for single fields are validated in a clean_FIELD, instead of globally in the form's clean() method, so that the error messages are correctly assigned to each field. Additionally, you can specify mappings for unique_together constraints to assign those error messages to a specific field as well (instead of having them in non_field_errors(), where they would normally be.

  • newforms
  • forms
  • validation
  • unique_together
  • unique
  • constraints
Read More

Django & cache headers

This takes advantage of a recently added feature to django, being able to give it real functions as the view instead of having it be a string that is has to look up itself. It takes advantage of how decorators work and how `cache_control` works, normally you'd do something like this: @cache_control(private=True, public=False) def view_stuff(request): # ... return response Which is equal to doing `view_stuff = cache_control(private=True, public=False)(view_stuff)` after definition. `cache_control` is a function factory, more or less, which we use to our advantage.

  • cache
  • decorators
Read More

Javascript HTTP response

I've been using this along with [prototype](http://www.prototypejs.org) to make simple ajax calls. In essence you make the calls from the client with... new Ajax.Request('url',{parameters:{'someparam':$('someparam').value}}); return false; On the onsubmit event of a form, onclick or whatever. Note that the return false is important to prevent the page from reloading. Sending some javascript to be executed back to the client is then as simple as setting up your view to return: return HttpJavascriptResponse('alert("boing");') So, yeah, prototype does the real work and this class does little other than make it clear what our intentions are and reduce the opportunities for typos. But it works for me.

  • ajax
  • javascript
  • prototype
  • return
Read More

Repeat blocks with new context / simple Jinja-like macro system

A simple macro system that makes it possible to reuse previously defined blocks, optionally with a custom context, similar to the macro functionality in Jinja. It requires some workarounds/hacks because we cannot reach all the data from inside the django template system that we need, but it seems to work pretty well so far. It is, however, also pretty untested at this point, so use at your own risk. Examples: base.html: <!-- This is mandatory if you want to use the repeat-tag in a template. It should as placed as earily as possible. See below for how to mix with template inheritance. --> {% enablemacros %} <!-- Note that {{ param }} does not exist. --> {% block foo %} A standard django block that will be written to the output. {% if param %}{{ param }}{% endif %} {% endblock %} {% macro bar %} Pretty much the same thing as a django block (can even be overridden via template inheritance), but it's content will NOT be rendered per default. Please note that it ends with ENDBLOCK! {% if param %}{{ param }}{% endif %} {% endblock %} <!-- Render foo for the second time --> {% repeat foo %} <!-- Render foo bar the first time --> {% repeat bar %} <!-- Render both blocks again, and pass a parameter --> {% repeat foo with "Hello World" as param %} {% repeat bar with "Hello World" as param %} {% macro form %}do stuff with: {{ form }}{% endblock %} {% for form in all_forms %} {% repeat display %} <!-- will have access to {{ form }} {% endfor %} extend.html: <!-- {% extends %} requires that it be the first thing in a template, and if it is, everything except for block tags is ignored, so {% enablemacros %} won't work. Instead, use: --> {% extends_with_macros 'base.html' %} {% block foo %} Will override "foo" in base.html {% endblock %} {% block bar %} Will override the macro block "bar" in base.html. Whether this is defined as block or macro doesn't matter. {% endblock %} Todo: * This (both tags used) results in infinite recursion: {% extends_with_macros "somefile" %}{% enablemacros %}

  • templates
  • macro
  • jinja
  • repeat
  • reuse
  • variables
Read More

Default Template Loading

One of the things about Django that has always irked me is that there seems to be no standard facility for just loading a page and displaying it, simply. Yes, there is the flatpages module, but it is primarily designed for loading content from a DB. While you specify a custom template and put in junk values for the DB content, it just feels like extra, unnecessary work. Thinking about the problem some more, I borrowed from the idea of flatpages and implemented a view that will load an otherwise unmapped template off the filesystem and render it. This is very useful when converting an existing site over. Just copy your files over. No need to map anything in the URL conf or use the admin to add any flatpage entries. Since it'll render the template, too, you can even use tags and what not, so it need not be a static page.

  • template
  • loader
Read More