A class called MetaOptions that enables decoration of Django models with meta classes in similar style to Admin and Meta. Included is an example usage to enable CSV export of any set of models. The package installs into django.contrib.options and is available for download at the [Python Cheeseshop](http://cheeseshop.python.org/pypi/django_options/r6)
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.
l = (1, 23, 60, 75, 3600, 36000) for n in l: print friendly_seconds(n) 00:00:01 00:00:23 00:01:00 00:01:15 01:00:00 10:00:00
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
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 ... )
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.
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.
You have an update form with many fields and want to populate it with data coming from multiple models.
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.
A simple script to run 'manage.py sqlall' on every app in a project.
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.
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.
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.
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.
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 %}