Archive for March, 2010

Free Software & Linux Days 2010

Monday, March 29th, 2010

Free Software & Open Source Days of İstanbul Bilgi University and Linux & Free Software Festival of Linux Users Association are united under the name Free Software & Linux Days this year. If you have attended before, you will probably make no other plans for April 2-3.

If you have never been to this event, registration is free and can be done at the front desk. If you are remotely interested in free software or hackerdom you will want to be there. …and, of course, you are welcome.

I will be giving a Django presentation on Friday. Please come and say hello if you happen to be attending.

UPDATE: You can find the slides from presentation here. Slideshare’s importer failed to import the file I’ve uploaded properly. So please download and view the slides with Acrobat Reader.

Bookmark and Share

What’s New in django-formfieldset 1.1

Saturday, March 20th, 2010

I have just released 1.1 version of django-formfieldset. I has been almost a year since version 1.0. Here is a summary of changes for this version:

New Example Project

There is a new and improved example project. It is designed to be some sort of documentation at the same time. When you run the example project and visit different pages you will see, for each examle, Python code, template code, text of rendered result and finally the result embedded.

If you have Pygments installed all the code will be nicely highlighted.

Fieldset & FieldsetMixin Improvements

Fieldset definitions are validated now. An exception will be raised if all of your fields are not included exactly once.

Template strings that are used by as_table, as_p and as_ul methods are now class attributes. You can simply override them instead of writing your own as_* method.

FieldsetMixin provides a fieldset_dict attribute. This dictionary has slugified fieldset names as keys and Fieldset instances as values. Your fieldset declarations can still be accessed from fielsets attribute.

Rendering Improvements

There are two rendering related improvements: individual fieldset rendering and renderform template filter.

Fieldset objects have as_table, as_p, as_ul methods just like forms. Errors from hidden fields are handled correctly, but you still need to call non_field_errors() to get the top level errors. Also it is template author’s responsibility to make sure all the fieldsets are rendered.

If as_* methods are not enough for you, with renderform filter you can render your forms or Fieldsets through a custom template. It works like this:

{{ form.fieldset_dict.mytitlerenderform:"myapp/mytitle_fieldset.html" }}

If you call it without an argument formfieldset/form.html template will be used.

Bookmark and Share

The Zen of CherryPy

Sunday, March 14th, 2010

An awesome presentation by Robert Brewer from PyCon 2010. Make sure you watch at a comfortable time.

It’s good to see CherryPy project is pretty much alive. It’s a web server and a web framework and more. Check it out if you haven’t!

Bookmark and Share

Developing Reusable Django Apps: Signals

Thursday, March 4th, 2010

I wrote “signals provide a great way to propagate the events generated from your app” earlier. I think reusable apps should avoid hardcoding any kind of event handling and send signals instead. App consumers might prefer an email over an on-screen notification. They may even choose to ignore the event silently. A reusable app should give this choice to the consumer.

Taking advantage of signals doesn’t necessarily mean providing no sane defaults. You can send signals and provide default event handling. Here is a couple of ideas how this can be done:

  • Your app can check if there are any listeners and connect the default handlers if there is none.
  • You can ship an auxiliary app that connects default handlers when added to INSTALLED_APPS.

I personally prefer the second approach since it’s simpler and more explicit. I’m sure there are other ways to implement default handlers for signals.

Dispatch_uid

Don’t forget to assign a unique dispatch_uid for each connect() call. Otherwise your handler can get connected twice. I would also suggest you to use both module path and your handler function’s name in your dispatch_uid:

"%s.%s" % (os.path.splitext(__file__)[0].replace(os.sep, '.')[1:],
           handler_name)

Now I should take my own advice and replace hardcoded User.message_set.create()s with signals in django-simple-friends.

Bookmark and Share