Login

3110 snippets

Snippet List

Parse custom template tag's args or kwargs

Enhanced version of snippet [1113](http://djangosnippets.org/snippets/1113/) Usage example (not self-contained): @register.tag def groupurl(parser, token): ''' Syntax:: {% groupurl view_name group [key=val, [key=val, ...]] [as varname] %} Example:: <a href="{% groupurl blog_detail group slug=blog.slug %}">{{ blog.name }}</a> ''' bits = token.contents.split() tag_name = bits[0] if len(bits) < 3: raise template.TemplateSyntaxError("'%s' takes tag at least 2 arguments (path to a view and a group)" % (tag_name,) bits_iter = iter(bits[1:]) # view_name + group and url kwargs args, kwargs = parse_args_and_kwargs(parser, bits_iter, stop_test='as', tagname=tag_name) if len(args) != 2: raise template.TemplateSyntaxError("'%s' takes exactly two non-kwargs (path to a view and a group)" % (tag_name,)) view_name, group = args # as var asvar = None for bit in bits_iter: asvar = bit return GroupURLNode(view_name, group, kwargs, asvar)

  • tag
  • templatetag
  • parse
  • args
  • kwargs
Read More

Extended cacheable callables and properties

There are several snippets that provide a basic caching decorator for functions and methods (e.g. #202, #1130, etc.). The `Cacheable` class in this snippet extends them by (*if you don't see an unordered list below, the Markdown on this site is still broken...*): - Specifying how cache keys are determined in one of two general, flexible ways. - Exposing a few extra methods for (re)setting and deleting the cached value transparently. Given these methods, cache key management should follow DRY: keys are specified once (and only once) at instantiation time, without having to be repeated at later interactions with the cache. - Adding a variant for cacheable properties. Unlike some other snippets, the way cache keys are generated must be explicitly specified by the client; there is no automagic key generation for arbitrary `func(*args, **kwds)` calls (but can be added if desired). The reason is that all usual serialization approaches (`func.__name__`/`func.__module__`, `repr`, `pickle`, etc.) are generally fragile, unsafe, inefficient or all of the above. Explicit is better than implicit in this case.

Read More

Base class for RESTful Views

Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request. class View(Request): def DELETE(self, request): ... def GET(self, request): ... def PUT(self, request): ... Other snippets provided inspiration: * [436](http://www.djangosnippets.org/snippets/436/) * [437](http://www.djangosnippets.org/snippets/437/) * [1071](http://www.djangosnippets.org/snippets/1071/) * [1072](http://www.djangosnippets.org/snippets/1072/) The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).

  • views
  • rest
  • http
  • view
Read More

FormWizard inside view with proper context handling and site templating support, without having to use urls.py

Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)

  • requestcontext
  • views
  • context
  • form
  • urls.py
  • wizard
  • formwizard
  • views.py
Read More

Getting dynamic model choices in newforms

This is an excerpt from the form code used on this site; the tricky bit here is making the `choices` for the `language` field get filled in dynamically from `Language.objects.all()` on each form instantiation, so that new languages can be picked up automatically. It also adds a blank choice at the beginning so that users can't accidentally ignore the field and incorrectly end up with whatever Language was first in the list. If you use this, always remember that you have to call the superclass `__init__` _before_ you set your dynamic choices, and that you need to accept `*args` and `**kwargs` so you can pass them to it. In theory, `ModelChoiceField` will solve this, but it still seems to be a bit buggy.

  • newforms
  • models
Read More

Multiple-Submit-Button Widget for Choice Field

Django administration provides three buttons for submitting the currently edited object. Each of them has a unique name and depending on the name that is sent to the server, the specific action is performed. I see this as an ugly solution and prefer to have a choice field in the form which would render as submit buttons with different values. Then the values would be checked instead of the names. Therefore, I created the `MultipleSubmitButton` widget. When `<input type="submit" value="Go" />` is used, the value sent to the server always matches the text on the button, but if `<button type="submit" value="go">Go</button>`, the value and the human representation might differ. To use the `MultipleSubmitButton` widget, pass it to the widget parameter of a `ChoiceField` like this: SUBMIT_CHOICES = ( ('save', _("Save")), ('save-add', _("Save and Add Another")), ) class TestForm(forms.Form): do = forms.ChoiceField( widget=MultipleSubmitButton, choices=SUBMIT_CHOICES, ) When you print `{{ form.do }}` in the template, the following HTML will be rendered: <ul> <li><button type="submit" name="do" value="save">Save</button></li> <li><button type="submit" name="do" value="save-add">Save and Add Another</button></li> </ul> When you submit this form and check the validity of it, `form.cleaned_data['do']` will return "save" or "save-add" depending on the submit button clicked.

  • forms
  • widget
  • submit
Read More

Access transparently the user profile information

Splitting the information about a user across two models (User and UserProfile) is not to everyone's liking. This snippet monkeypatches the User model so that users can access transparently their profile information while still storing the data in two tables under the hood. Thus it is similar to the inheritance approach (http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/) but has the benefit of (a) not requiring a custom authentication backend or middleware and (b) loading the profile instance lazily, so there's no extra overhead if the profile infromation is not accessed. Read the docstrings for more details.

  • auth
  • profie
  • user profile
Read More

Django code generator

django-app-generator takes as an input your project (ORM) and generates repetitive code. At this moment there is only one example a simple RESTservice, but goal is to build alternative implementation of admin panel that will be fully customizable. The project is in the beta stage, if you encounter any problems feel free to create an issue.

  • Admin
  • REST
  • code-generator
Read More

create_template_postgis-ubuntu_lucid

The template creation script referenced [here] (http://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#ubuntudebian) doesn't work on Ubuntu Lucid, where the default PostgreSQL version is now 8.4 and some things have been moved around. I've edited the script to work on Ubuntu Lucid.

  • postgis
  • ubuntu
Read More

A RegexpField that clean the regex match using the desired format

I wanted a way to allow flexible phone number validation while making sure the saved data was uniform. ex. With: RegexFormatField(r'^\(?(?P<area>\d{3})\)?[-\s.]?(?P<local>\d{3})[-\s.]?(?P<subscriber>\d{4})$', format='%(area)s %(local)s-%(subscriber)s') input: (444) 444-4444 444 444-4444 444-444-4444 444.444.4444 4444444444 output: 444 444-4444

  • regex
  • format
  • field
Read More

ReportBug() (exception emails - ala django debug style)

ReportBug() allows you to send exception details to you, via email, but with far more detail than the default. It uses the base function for the traceback used by the Debug mode on Django. This is a first revision, so the emails have no decent styling, but it works, and shows scope on each stack. It will automatically generate a random serial number per error, so you can track them in your favourite bug tracker. It also has support for you to pass it a request variable, so the mail would also contain request/response context. Again, i'm gonna look into doing this manually in the future. Hope this helps! Mwah. Cal Leeming. cal [at] simplicitymedialtd.co.uk. Simplicity Media Ltd.

  • email
  • debug
  • mail
  • exception
  • report
  • bug
  • mail_admins
  • reportbug
Read More

Initially open collapsable fieldset class in admin

It's just an extension for the admin. Replace the collapse.js (collapse.min.js) and use it like this in the admin fieldset option: ´´**'classes': ['collapse', 'open']**´´. Without the 'open'-class, it will work as usual. *Needs possibly fixing for IE <= 8* because IE doesn't support the ´´:not´´ selector.

  • fieldset
  • collapse
  • collapsed
  • open
  • show
Read More