Tag: django

After nearly more than a year of development Brian Rosner merged the newforms-admin branch into trunk last night. This marks the last missing branch getting merged into trunk before the 1.0 release. Big kudos and thanks to Brian and everybody else involved in the development on this branch.

Another big change happened last night: newforms is now finally the "official" forms library for Django. At least it now resides directly within django.forms.

Both of these changes are backwards-incompatible, yet fully documented (1, 2). For everyone running on trunk (and who hasn't been preparing for this merge) this means some work esp. if you've messed around quite a lot with oldadmin. Also some of the styling in NFA looks a little bit different than before thanks to the move away from the old form manipulator modules which added some special classes to each form-element. If it annoys you, check out #5609.

About a week ago I wrote about bringing some OOP into Django views and also posted some code for that. Since I use this in one project and want to move it also into some other project of mine, I've put this (together with some very simple pagination templatetag) into its own pluggable app and uploaded it github for everybody to slap me around for my coding style

So if you want to use this code, simply install the app available here (or just import the django_zsutils.utils.oopviews module).

Malcolm Tredinnick today merged his queryset-refactor branch into Django's trunk, which means everyone using trunk will finally be able to for example using a more sane syntax for ordering resultsets (no table names anymore), update multiple objects with just one query, tell select_related() which fields it should follow (instead of every foreign key it comes across) and much much more.

A couple of days ago, a topic came up on the django-users mailinglist where someone asked how to avoid code repetition in views if the views mostly do the same (for instance do some processing on the request parameters or check a certain session variable etc.).

There is one question you have to ask yourself first, though: Does this common processing require request-specific data like session-data or request parameters?

Since I started messing around with JavaScript a little more for work and also finally used this opportunity for getting some knowledge when it comes to YUI, I was about to look into ways to efficiently deploy separated JavaScript files (or at least I planned to get into this topic this weekend). I guess for Django, there is now - thanks to Pedro Vale Lima - a really nice management command that makes packaging and compressing multiple JavaScripts easy.

Naturally you could also write an external script using one of the many packers that are already out there, but with the integration right into Django it's just much cleaner

Jonathan Buchanan just released version 0.2 of the django-tagging app which comes with quite some significant changes in how tags are detected. It's now also possible to have multi-word tags and as such tags no longer have to be separated by spaces but instead can now also be separated by commas.

Besides these and other new features as well as some bugfixes this update also comes with 2 backwards-incompatible changes:

1. The database tables are now named tagging_tag instead of tag and tagging_taggeditem instead of tagged_item.
2. The tagging.utils.get_tag_name_list function was removed. From what I can tell, tagging.utils.parse_tag_input is basically its replacement.

For more details check out Jonathan's announcement and django-tagging's project page

Hmm... just noticed a big change in Django's newforms API which happened in r6844 (so basically on Dec 2nd): form_for_model and form_for_instance got deprecated in favor of the the new ModelForm class. The motivation behind this move is quite well documented on the django-dev mailinglist, but for me personally it seems to boil down to replace form_for_* with a much more declarative syntax (which is a good thing).

So if you for instance have a model Game like this (if I understood it correctly)

class Game(models.Model):
    name = models.CharField(max_length=150)
    ...

you could easily create a form class for it like this:

class GameForm(forms.ModelForm):
    class Meta:
        model = Game

I really can't wait to actually play around with this since it just makes everything all so much more consistent

For some details checkout the new modelforms documentation page.

Seit gestern gibt es auf django-de.org eine neue deutschsprachige Community-Seite für Django. Hauptziel ist derzeit die Übersetzung der Dokumentation ähnlich den Initiativen, die es bereits für die spanische und französische Community gibt. Wer mithelfen möchte, findet unter http://www.django-de.org/participate/ genauere Information.

Ein herzliches Dankeschön an Jannis Leidel und alle anderen, die mitgeholfen haben, django-de ins Leben zu rufen

In case you were at the Barcamp and couldn't check out my little presentation about the Django web framework, couldn't read the slides or simply couldn't get to the Barcamp at all: Here are my slides (and even hopefully with less errors ).

For the last two days I've been now playing a little bit around with the Symfony framework, which is somehow comparable to what Rails does in the Ruby world, while being written in PHP. I especially like how i18n is handled there ...