**[Improved and Released as Save The Change.](https://github.com/karanlyons/django-save-the-change)**
Django 1.5 added the `update_fields` `kwarg` to `Model.save()`, which allows the developer to specify that only certain fields should actually be committed to the database. However, Django provides no way to automatically commit only changed fields if they're not specified.
This mixin keeps track of which fields have changed from their value in the database, and automatically applies `update_fields` to update only those fields.
There is a lot of debate on whether there is a real future for the Django CBVs (class based views). Personally, I find them tedious, and just wanted a way to keep my views clean.
So, here is a really minimalistic way of having class based views, without the fuss.
This is a fork from:
http://stackoverflow.com/questions/742/class-views-in-django
http://djangosnippets.org/snippets/2041/
It was based in:
http://djangosnippets.org/snippets/1586/
Instead of doing this:
'attribute_name = forms.CharField(widget=forms.TextInput(attrs={'class':'special'}))`
You can do this in your template:
{{ form|cssclass:"attribute_name:special_class"|cssclass:"other_attribute:special_class" }}
**Your model:**
class TicketItem(models.Model):
hours = models.DecimalField(decimal_places=2, max_digits=6)
day = models.DateField()
order = models.ForeignKey(Order)
tickets = models.ManyToManyField(Ticket)
Now you want to auto save m2m fields in your forms.TicketItemCreateForm:
1. inherit from m2mForm-Class
2. define m2m_field(s)
**Example:**
class TicketItemCreateForm(m2mForm):
m2m_field = 'tickets'
class Meta:
model = models.TicketItem
Apply the `login_required` decorator to all the handlers in a class-based view that delegate to `cls.dispatch`.
Optional arguments:
* redirect_field_name = `REDIRECT_FIELD_NAME`
* login_url = `None`
See the documentation for the [`login_required`](https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator) method for more information about the keyword arguments.
Usage:
@LoginRequired
class MyListView (ListView):
...
This example assumes you have a form and want to highlight one of two fields
by setting <class="highlight"> in the html dynamically. This is an alternative to
<https://docs.djangoproject.com/en/1.3/ref/forms/widgets/#customizing-widget-instances>,
but now you're not limited to assigning the class to the fields html-output,
instead you can also assign it to a div around the field like done here.
After assigning a css-attribute to a field, we access the css via a templatefilter
*{{ field|css }}*
that looks up
*field.form.fields[field.name].css*
and not simply *field.css*, since the latter would try to access
a non-existing css-attribute on a BoundField-instance
EDIT:
The templatefilter is unnecessary. There is a much easier way, since the original field itself is an attribute of the BoundField named 'field'. So in the template, we can access the css via {{ field.field.css }}. Thanks to Tom Evans for pointing me at this.
If you're used to auto_render like I am (and think it's an awesome way to DRY code) and you want to support users with and without javascript enabled, this class is perfect.
You will need to provide the format requested, either through adding "(\.format)?" at the end of the url or through some middleware, but once you've done so this class will take care of rendering through the given template for normal users, JSON or JSONP for AJAX users.
From [fahhem.com](http://fahhem.com/) and [Recrec Labs](http://recreclabs.com/)
uses the system or specified locale to format a number. a css class called 'negative' would be added if the format is negative and the minus symbol would be replaced if it is the last char.
I work a little with [web.py framework](http://webpy.org/) and I like a lot the view definition.
For each view you define a class and in that class you can define two method, GET and POST. If the http request is a GET request the GET method will be called and if http request is a POST request the POST method is called.
Then you can define common stuff in another method that could be called inside each method, and you have a class for each view.
A lot of times we need to insert a specific **CSS class** into a Form instance for it to be rendered in the template.
The current method is to specify the CSS class in the Python code through the form field widget. But it would be easier for the designer to be able to specify the CSS class in the template directly.
For example rather than doing this in your Python code:
'name = forms.CharField(widget=forms.TextInput(attrs={'class':'special'}))`
You can do this in your template:
`{{ form.name|cssclass:"special"}}`
This template filter only works with Form Field instance.
This set of handlers allow one to isolate requests based on the method posted. Normally, in a view, we would do checks for request.method value and update the resource accordingly. This makes the view code pretty messy.
So one way to avoid these check each time is to have a handler method (resource_handler above), that checks for the method parameter and dispatches to the handler withe the prefix <method>_handler_<suffix>.
This also has the advantage of grouping related actions in a particular class. At the same time a new instance of the request handler is not created on each request (as with the google appengine handler?). Yet another advantage is by making the handler methods as class methods, the handler classes can be inherited to add further functionality to a resource "group.
The disadvantage however is the inability to restrict access to a handler method to only particular methods. Eg above the "r'obja/(?P<id>[^\/]+)/delete/" would map to the delete_handler_objects if themethod was "delete" and post_handler_objects if the method was "post". However this can be worked with a different suffix passed to the handler_params method. Infact setting the suffix to "objects_delete" would result in a "delete_handler_objects_delete" handler on delete method and a Http404 on all others.
Another inconvinience is the inability to detect a view handler by simply inspecting the url patterns. However, this information is carried within the handler_suffix and handler_class parameters which may infact provide greater insight into the semantics around the view handlers.
Needless to say, this easily extends rest based accesses.
Would greatly appreciate feedback and improvements.
After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class.
You could, for example, extend View to be JinjaView, just replacing render_template().
A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
This decorator allows you to wrap class methods or module functions and synchronize access to them. It maintains a dict of locks with a key for each unique name of combined module name and method name. (Implementing class name is lost in decorator? Otherwise it would have class name too if available.)
Effectively it functions as a class level method synchronizer, with the lock handling completely hidden from the wrapped function.