The Usware Blog - Django Web Development

Moving home

shabda — Tue, 08 Jun 2010 14:59:46 +0000

Tl;dr version:

We are moving our site from Uswaretech.com to Agiliq.com. Please update your book marks and the like.

Longer version:

We have moved. Our new, cool, and amazing site is Agiliq.com. Built with Django, pixie dust and pink unicorns, its is sure to amaze you. Please update your bookmarks.

Gory details:

New url: http://agiliq.com/
New Blog: http://agiliq.com/blog
Twitter: http://twitter.com/agiliqdotcom
Github: http://github.com/agiliq

If you are client of ours, the Unfuddle and billing details would be changing soon. (You should also have received an email from us.)

Unfuddle: http://agiliq.unfuddle.com/
Freshbooks: http://agiliq.freshbooks.com/

Thanks for being with Usware/Agiliq, and we are excited to start a new pahse in our journey, and have you with us.

No related posts.

Great Indian Developer Summit 2010: A Review

lakshman — Mon, 26 Apr 2010 19:52:27 +0000

Great Indian Developer Summit, is the India’s largest developer conference, held at Bangalore, India; in its third edition this year. The conference concluded last Friday. The summit had about a 1000 visitors on the first day and a comparable number on the other days.

The conference basically caters to the enterprises, and hence their focus on the .Net, Java and Flash. There were many star speakers.

I gave a talk on django, introducing it and then explaining the standard community conventions to make good reusable applications. Django, being a social software, developed by a community, it is important to cover the community aspect, and the innumerable number of reusable application that exist. So, there is enough of that.

Building Pluggable Web Applications using Django

View more presentations from scorpion032.

The slides themselves were created using Beamer class, in latex. The code is on Github, and there are some custom commands. How the beamer class that was created specifically to create bullet point presentations can so totally create web2.0 kind of slides with images and text on them, by just a simple command, and continues to be not only relevant, but also best in class presentation creator, gives me a kick. I always hated PowerPoint and could have in no way done so many slides using it, that way. “Write the relevant text and give the path of the image to include”, or “give the path of the file that has code in it, to include in this slide” is the way I think and slide maker should create slides from. So glad beamer and latex could do that. It should be relatively easy to write a markdown to ppt compiler, given the presentation format. Until next time.

I am no expert in .Net and given an option to, would avoid working with Java. Nevertheless, the sessions by Venkat Subramaniam were interesting. It was a good experience to meet many great developers and people. Matthew_McCullough is an expert in large number of things. Session by Scott Davis was definitely awesome. It was overall a great experience.

CSS Frameworks

saikiran — Tue, 30 Mar 2010 09:27:23 +0000

A framework is a basic conceptual structure which you can use as a “scratch” for your web-projects. For instance, instead of defining global reset, consistent baseline, typographic rules or basic styles for forms over and over again — every time you work on a new project — you can prepare a default-style once and reuse it in all your future projects. This is what you call a CSS Framework.

Major Advantages of CSS Frameworks

Increase productivity.
Cross Bowser Compatibility
Clean, Well structured easy to maintain code base.

Disadvantages of CSS Frameworks

Takes time to understand the CSS framework.
You might inherit someone’s bugs or mistakes.
You get a bloated source code.

Among most of the CSS Frameworks that i have come across Blueprint & YUI frameworks seems to be the most powerful frameworks.

Blueprint CSS Framework Blueprint is a CSS framework, which aims to cut down on your development time. Blueprint Grid CSS Generator helps you generate more flexible versions of Blueprint’s grid.css and compressed.css and grid.png files. Whether you prefer 8, 10,16 or 24 columns in your design, this generator now enables you that flexibility with Blueprint.

Blueprint CSS Framework provides

reset.css , CSS reset for default browser styles
print.css , A stylesheet for printing
typography.css, For basic typographic rules,
grid.css , For grid-based layouts or
form.css for basic form styling
Blue Print also provides psd file for basic understanding of grid based layout.

YUI CSS Framework One of the major advantages with YUI is it supports fluid-width (100%) layouts as well as preset fixed-width layouts at 750px, 950px, and 974px, and the ability to easily customize to any number and the documentation is very clear. The YUI Grids Builder — a simple interface for Grids customization. Photoshop template for use with YUI is not available.If it is provided it will be a great help for newbees to understand the system.

YUI CSS Framework provides

reset.css , CSS reset for default browser styles
fonts.css, For basic typographic rules,
grid.css , For grid-based layouts or

960 grid system

Custom CSS Generator works fine and you can chnage the number of columns and get the css code.Based on your templates you can customise it accordingly.Html layout generator is quite confusing, while I tried to use it.

Yaml Builder

Yaml is having a wonderful tool to make custom grid structure and the css is easy to understand and customise it. Newbees can work with this tool easily.We can create a grid of any size and we can mention the number of columns etc…DOM Tree is an interesting option in YAML builder, it allows you to easily recognise the divs , if you click on the code it shows that perticular div in marked in green color on the design.

Eventhough Blueprint and YUI have advantages and disadvantages, Blueprint seems to be quite comfortable for me to work with and in terms of flexibility as well.

No related posts.

Rails and Django commands : comparison and conversion

shabda — Sat, 20 Mar 2010 13:05:30 +0000

The most commonly used Rails commands and their Django equivalents

Rails	Django
rails console	manage.py shell
rails server	manage.py runserver
rake	None
rails generate	None
rails dbconsole	manage.py dbshell
rails app_name	django-admin.py startproject/manage.py startapp
rake db:create	manage.py syncdb

The salient points to note are,

Django has all commands via manage.py, Rails has it broken into rails and rake.
Overall there are more Rails+Rake commands available than Django commands
There is no one to one mapping between Rails and Django commands. Eg. There are no equivalent to rake doc:* or rake notes in Django.

Similarly there is no equivalent to manage.py createsuperuser in rails.

References

http://docs.djangoproject.com/en/dev/ref/django-admin/ http://guides.rails.info/command_line.html http://github.com/uswaretech/Acts-as-Django/blob/master/commands.markdown

The Rails and Django models layer Rosseta stone

shabda — Sat, 20 Mar 2010 10:42:50 +0000

Rails Active records and Django models are more similar than they are different. This is a quick guide to converting between Rails 3 and Django 1.2, and is available on github at http://github.com/uswaretech/Acts-as-Django

Defining models

Both Django and Rails keep the canonical database representation in ruby or python.

#Django

class Post(models.Model):
    name = models.CharField(max_length = 100, )
    slug = models.CharField(max_length = 100, )
    body = models.TextField()

class Comments(models.Model):
    post = models.ForeignKey(Post)
    username = models.CharField(max_length = 100, )
    comment = models.TextField()



#Rails

#db/schema.rb
ActiveRecord::Schema.define(:version => 20100319195739) do

  create_table "comments", :force => true do |t|
    t.string   "username"
    t.text     "comment"
    t.integer  "post_id"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "posts", :force => true do |t|
    t.string   "name"
    t.string   "slug"
    t.text     "body"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

end

#In apps models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

The main difference is that Django keeps it one file, while rails has it split over many files. In Django, the foreign key is specified only on the Child model via models.ForeignKey but in Rails both sides of relationship need to be specified via has_many and belongs_to.

Create a object without saving it

In [1]: from blog.models import *

In [2]: post = Post()

In [3]: print post.id
None



irb(main):001:0> post = Post.new
=> #
irb(main):002:0> post.id
=> nil

Set values and save to the database

In [4]: post.name = "Hello"

In [5]: post.slug = "hello"

In [6]: post.body = "Hello, this is a post"

In [8]: post.save()

In [9]: post.id
Out[9]: 1


irb(main):001:0> post = Post.new
=> #
irb(main):002:0> post.id
=> nil
irb(main):003:0> post.name = "Hello"
=> "Hello"
irb(main):004:0> post.slug = "hello"
=> "hello"
irb(main):005:0>  post.body = "Hello, this is a post"
=> "Hello, this is a post"
irb(main):006:0> post.save()
=> true
irb(main):007:0> post.id
=> 2

There is not much to see here, both DJango and Rails create the object in essentially the same way. Until you call save, the objects are not saved to the database.

Find object by the primary key.

In [10]: Post.objects.get(id = 1)
Out[10]: 

irb(main):008:0> pst = Post.find(2)
=> #

What Rails calls find, Django calls get.

More create methods

In [12]: Post.objects.create(name="Hi", slug="hi", body="Hi hi hi.")
Out[12]: 


irb(main):012:0> Post.create(:name=>"Hi", :slug=>"Hi", :body=>"Hi hi hi")
=> #


In [14]: Post.objects.get_or_create(name="Hi")
Out[14]: (, False)

irb(main):015:0> Post.find_or_create_by_name("Hi")
=> #

You can create in one step without calling save via a create in both Rails and Django. While rails has dynamically named methods, Django accepts named parameters in filter and get_or_create.

More find methods

In [15]: Post.objects.filter(id__in = [1, 2, 3])
Out[15]: [, ]

irb(main):017:0> Post.find(1, 2, 3)
=> [#, #, #]

In [16]: Post.objects.get(name="Hi")
Out[16]: 


irb(main):023:0> Post.find_by_name("Hi")
=> #


In [17]: Post.objects.all()
Out[17]: [, ]


irb(main):024:0> Post.find(:all)
=> [#, #, #, #]

In [18]: pp = Post.objects.filter(name="Hi")

In [19]: pp
Out[19]: []
In [20]: pp[0]
Out[20]: 


irb(main):032:0> pp = Post.where({:name=>"Hi"})
=> # pp[0]
=> #

In [21]: Post.objects.filter(name__in = ["Hi", "Hello"])
Out[21]: [, ]

irb(main):034:0> pp = Post.where({:name=>["Hi", "Hello"]})
=> # pp[0]
=> #
irb(main):036:0> pp[1]
=> #


In [29]: p = Post.objects.filter(name__in = ["Hi", "Hello"]).only("name")

irb(main):041:0> pp = Post.where({:name=>["Hi", "Hello"]}).select("name")

The query capability and syntax are similar with major differences being,

Rails has dynamically named finders, while Django accepts keyword arguments for same.
SQL operators like in are fired by __ in Django, while Rails infers it based on the data type.

Limit, offset and order

In [30]: p = Post.objects.filter(name__in = ["Hi", "Hello"])[:1]

In [31]: p
Out[31]: []

pp = Post.where({:name=>["Hi", "Hello"]}).select("name").limit(1)

irb(main):049:0> pp[0]
=> #
irb(main):050:0> pp[1]
=> nil

=> #
irb(main):067:0> pp = Post.where({:name=>["Hi", "Hello"]}).limit(1).offset(1)

irb(main):067:0> pp[0]
=> #
irb(main):068:0> pp[1]
=> nil

In [34]: p = Post.objects.filter(name__in = ["Hi", "Hello"])[1:2]

In [35]: p[0].name
Out[35]: u'Hi'

In [36]: p[1].name
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)

/home/shabda/Code/Django/Weblog/ in ()

/usr/local/lib/python2.6/dist-packages/django/db/models/query.py in __getitem__(self, k)
    185             qs = self._clone()
    186             qs.query.set_limits(k, k + 1)
--> 187             return list(qs)[0]
    188         except self.model.DoesNotExist, e:
    189             raise IndexError(e.args)

IndexError: list index out of range


In [39]: p = Post.objects.order_by("name")[1:2]

In [40]: p
Out[40]: []


irb(main):069:0> pp = Post.order("name").limit(1).offset(1)

Again fairly similar, both Django and rails provide ordering, offset and limits, while Django does this via array slicing, Rails does this via functions. Also both Django and Rails allow method chaining, and Sql is only evaluated lazily when needed.

Specifying Model associations.

Django: models.ForeignKey
Rails: belongs_to

Django: models.ManyToManyField
Rails: has_and_belongs_to_many

Django: models.OneToOneField
Rails: has_one

Django: No needed
Rails: has_many

Again Rails and Django are similar with Django automatically inferring the reverse relationships.

Polymorphic Associations and Generic Relations

You possibly have pictures in your application which can be attached to any object. Both Django and Rails provide options for it via Polymorphic Associations and Generic Relations

class Picture(models.Model):
    content_type = models.ForeignKey(ContentType)
    object_id = models.PositiveIntegerField()
    content_object = generic.GenericForeignKey()

class Article(models.Model):
    body = models.TextField()
    picture =  generic.GenericRelation(Picture)

class BioGraphy(models.Model):
    bio  = models.TextField()
    picture = generic.GenericRelation(Picture)



class Picture < ActiveRecord::Base
  belongs_to :imageable, :polymorphic => true
end

class Employee < ActiveRecord::Base
  has_many :pictures, :as => :imageable
end

class Product < ActiveRecord::Base
  has_many :pictures, :as => :imageable
end

Self Joins

Self joins are a special case of Foreign key where a Object has a relationship to itself. Both Django and Rails handle it normally via their FK mechanisms

class Employee(models.Model):
    manager = models.ForeignKey("self", related_name = "subordinates")


class Employee < ActiveRecord::Base
  has_many :subordinates, :class_name => "Employee",
    :foreign_key => "manager_id"
  belongs_to :manager, :class_name => "Employee"
end

References

guides.rails.info djangoproject.com/documentation/

Doing things with Django models – aka – Django models tutorial

shabda — Mon, 18 Jan 2010 05:00:17 +0000

Django abstracts most of the actions you would be doing with the Database. What it doesn’t abstracts, and doesn’t try to abstract is the Database modelling part. This is a quick tutorial describing to how model your data in Django models.py, and how to access and modify them.

Consider a hypothetical HR department, which wants you to build an application to track and manage their processes. They have employees who work for a department, contractors who work for multiple department. Let’s see how you you would do that in Django.

from django.db import models

class Employee(models.Model):
    name = models.CharField(max_length = 100)
    department = models.ForeignKey("Department")

class Department(models.Model):
    name = models.CharField(max_length = 100)

class EmployeeHistory(models.Model):
    employee = models.OneToOneField(Employee)
    date_joined = models.DateField()
    marital_status = models.BooleanField()

class Contactor(models.Model):
    name = models.CharField(max_length = 100)
    departments = models.ManyToManyField(Department)

Let’s see the type of relationship we created here.

An Employee has a Many-to-one relationship with Department, (i.e. One department will have many Employee, but one employee will have a single departments.)

So Employee has a field department = models.ForeignKey("Department"). See that the ForeignKey field was added on the class which has in many. In database, this creates a FK from in Employee table which refernces Departments.

A Contractor has many-to-many relationships with Department, so it has a ManyToMany field. This field can be created on either classes. At a database level this creates a new table which has a FK to both the tables.

A Employee has one-to-one relationship with EmployeeHistory. The thing to note here is that whatever we could do with OneToOneField, we can do by including the fields in the Other Class directly. However when there are fields which are only rarely needed with a given model, it is useful to separate them via a one-to-one field. The one to one field can be on either class.

Accessing objects.

Getting a specific employee.

Employee.objects.get(pk = someval)
Employee.objects.get(name= someval)

Given an department get all employees.

department.employee_set.all()

The department gets an attribute name _set.

Given an employee, get all colleagues.

employee.department.employee_set.objects.all()

To get siblings, get parents, and get all children.

Given an department, get number of employees.

department.employee_set.all().count()

Ok so the HR department bosses are happy with what they see, and ask you to track this data, who is the manager of each employee, who is the HOD of each department and when did each employee took leave.

from django.db import models

class Employee(models.Model):
    name = models.CharField(max_length = 100)
    manager = models.ForeignKey("self", blank = True, null = True)
    department = models.ForeignKey("Department")

class Department(models.Model):
    hod = models.ForeignKey("Employee")
    name = models.CharField(max_length = 100)

class EmployeeHistory(models.Model):
    employee = models.OneToOneField(Employee)
    date_joined = models.DateField()
    marital_status = models.BooleanField()

class Contactors(models.Model):
    name = models.CharField(max_length = 100)
    departments = models.ManyToManyField(Department)


class EmployeeLeave(models.Model):
    leave_taken = models.DateField()
    employee = models.ForeignKey(Employee)

So we now have new fields hod = models.OneToOneField("Employee") in department and manager = models.ForeignKey("self", blank = True, null = True) and a new model EmployeeLeave. Let su see the new realtions,

As one Department will have one Employee as hod, and Employee can head at max one Department, we have a one to one relationship
As many Employee will report to another Employee, so we have a FK on Employee, referencing self. As Employee will take many EmployeeLeave, EmployeeLeave has a FK to Epployee

Let us see some queries.

Get all leaves taken by an employee this year

import datetime
today = datetime.date.today()
start_of_year = datetime.datetime(today.year, 1, 1)
leaves_taken = employee.employeeleave_set.filter(leave_taken__gt=start_of_year, leave_taken__lt = today)

Get a list of all HODs.

#As there are going to be as many Employees as departments
departments = Department.objects.all()
employees = [department.hod for department in departments]

Get a list of all departments a contractor works for.

contractor.department_set.all()

Get a list of all contractor who work for a department.

department.contractor_set.all()

Note that each side of a many to many relationship get a Manager.

List of all managers in a given department.

Todo#(Can't think of any one query way to do this. If you know, let me know   )

List of all leaves taken in a given department.

EmployeeLeave.objects.filter(employee__department = department)

None that we used double underscores __ to do a filtering on a field across Entities.

List of all employees which joined a given department this year.

Employee.objects.filter(department = department, employment_history__date_joined__gte=start_of_year, )

Note that we used a double underscore __ twice, first to go across entities, and then to define the type of filter(__gte). Also we specified two filter conditions, so they were ANDed together.

List all employees which either report too a given employee, or joined before him.

Employee.objects.filter(Q(manager = employee)|Q(employee_history__date_joined__lt = employee.employee_history.date_joined))

Note the new construct Q, they are used to specify complex boolean operations. Here we used the | (or operator) to specify or condition.

Do you subscribe to our rss feed? The new feed has full text feed and many other goodness. So make sure you are subscribed to the new feed with extra fortified vitamins. Subscribe now.

WordPress and Django: best buddies

shabda — Sun, 17 Jan 2010 14:25:29 +0000

Summary: How to integrate a non Django database system in your Django code, using WordPress as example. The completed code is available at github or you can see some screnshots

Though there are quite a few good Django blog applications, our blog is based on WordPress. A number of plugin’s make moving to a Django based app a bad decision for us, and not in the spirit of “best tools for the job”.

We moved the other way, and decided to use Django to admin the Wordpress database. The completed code is available on Github

It is not too hard, with the the builtin Django commands. Django provides the inspectdb command which allows you to build your models.py from an existing non Django database.

Here we will see the steps followed for WordPress, but it would be about the same for all systems.

Take a back up of wordpress

mysqldump -u wordpress_user -p --database wordpress_database > data.sql

Create a new project, and set its settings to use the WordPress database.

    DATABASE_ENGINE = 'mysql'           # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
    DATABASE_NAME = ''             # Or path to database file if using sqlite3.
    DATABASE_USER = ''             # Not used with sqlite3.
    DATABASE_PASSWORD = ''         # Not used with sqlite3.
    DATABASE_HOST = ''             # Set to empty string for localhost. Not used with sqlite3.
    DATABASE_PORT = ''             # Set to empty string for default. Not used with sqlite3.

Get the initial models.py

./manage.py inspectdb > models.py

This will create all the database tables in a form Django can understand. Here is what this command creates for a my WordPress installation with the YARPP plugin. http://gist.github.com/278962

Create a new app and put this models.py there.

With this done, you can treat the non Django part as a standalone application. Since WordPress appends all its table with wp_ prefix, we name this applications wp to maintain table name compatibility with Django naming conventions.

You will notice that all models have the db_table populated, so we can rename tables, without changes to the database.

Differences between WordPress and Django style naming.

At this point you will notice some differences in how Django names things (in a best practice sort of way), and how WordPress does it.

a. Django table and model class name are (generally) singular. eg class Post(models.Models) leads to table app_post. Wordpress tables are (most of them) named plural eg wp_posts.

b. Django attributes are generally named without the table name part. Eg

class Comment(models.Model):
    author_name = models.TextField()
    content = models.TextField()

WordPress is explicit here and includes the table prefix with attributes.

mysql> desc wp_comments;
+----------------------+---------------------+------+-----+---------------------+----------------+
| Field                | Type                | Null | Key | Default             | Extra          |
+----------------------+---------------------+------+-----+---------------------+----------------+
| comment_ID           | bigint(20) unsigned | NO   | PRI | NULL                | auto_increment | 
| comment_post_ID      | bigint(20) unsigned | NO   | MUL | 0                   |                | 
| comment_author       | tinytext            | NO   |     | NULL                |                | 
| comment_author_email | varchar(100)        | NO   |     |                     |                | 

.....

I believe this is due to the way you would generally be using the code. In Django you would do comment.author where being explicit doesn’t add any value, while in WordPress, you would use, select comment_author, post_title ... from wp_comment, wp_post ... where join, where being explicit is useful.

You can decouple the Django and database names by using the db_table and db_column attributes. We choose to rename the Class names to match Django conventions while we let the column names remain the same.

Add Admin and other Django niceties.

WordPress doesn’t (seem to) have foreign key constraints setup correctly, and uses bigint(20) unsigned without foreign key constraints to refer to referred entities. This means Django creates all ForeignKeys as IntegerFields.

Modify them to use ForeignKey instead. Also add __unicode__, to your classes.

Add an admin.py to register all your classes.

And you are done! Now you can access, and work with your WordPress data inside Django and Django admin.

There are a few more things which will allow a easier WordPress setup.

Create template tags to show the latest posts and comments.

@register.inclusion_tag("wp/recent_posts.html")
def show_posts(num_comments):
    return {"posts": Post.objects.filter(post_type="post", post_status="publish").order_by("-post_date")[:num_comments]}

So you can see that there is nothing WordPress specific we need too do here.

Create a better admin.

Add ModelAdmin to generally used models.

Allows accessing attributes via the Django style names.

If you override __getattr__, you can access the attributes via other names. Eg in the current setup you need to do comment.comment_content, comment.comment_author etc, while we would like to do comment.content and comment.author as a shortcut.

class WordPressModel(object):    
    def __getattr__(self, v):
        if v in self.__dict__:
            return self.__dict__[v]
        else:
            new_v = "%s_%s" % (self.__class__.__name__.lower(),  v)
            if new_v in self.__dict__:
                return self.__dict__[new_v]
            else:
                raise AttributeError

It is highly debatable whether this is a good idea , but it is too convenient right now not to test this method out.

Here are some screenshots.

Do you subscribe to our feed? We recently made a full text feed available, so if you are using the old feed, you should change it. Subscribe now.

Doing things with Django forms

shabda — Thu, 14 Jan 2010 11:26:18 +0000

Forms are one of the best features of Django. (After models, admin, url routing etc ). Here is a quick tutorial describing how to do things with Django forms.

Basic form

Prob. You want to show a form, validate it and display it.

Ans. Create a simple form.

class UserForm(forms.Form):
    username = forms.CharField()
    joined_on = forms.DateField()

This wil take care that the form is displayed with two text field, and a value for them are filled in, and the second field has correct formatting for a date.

Prob. Create a form which has values populated depending upon a runtime value, eg you might want to show only the values corresponding to the current subdomain.

Ans. Create a form with an custom __init__.

class UserForm(forms.Form):
    username = forms.CharField()
    plan = forms.ModelChoiceField(queryset = Plan.objects.none())

    def __init__(self, subdomain, *args, **kwargs):
        self.default_username = default_username
        super(UserForm, self).__init__(*args, **kwargs)
        self.fields['plan'].queryset = Plan.objects.filter(subdomain = subdomain)

Here in the __init__ we are overriding the default queryset on field plan. Any of the attributes can similarly be overridden.

However the self.fields is populated only after super(UserForm, self).__init__(*args, **kwargs) is called.

Prob. The same form is used in multiple views, and handles the cleaned_data similarly.

Ans. Create a form with a custom .save()

class UserForm(forms.Form):
    username = forms.CharField()

    def save(self):
        data = self.cleaned_data
        user = User.objects.create(username = data['username'])
        #create a profile
        UserProfile.objects.create(user = user, ...some more data...)

You could have called this method anything, but this is generally called save, to maintain similarity with ModelForm

Prob. You need to create a form with fields which have custom validations.

Ans. Create a form with custom clean_fieldname

class UserForm(forms.Form):
    username = forms.CharField()

    def clean_username(self):
        data = self.cleaned_data
        try:
            User.objects.get(username = data['username'])
        except User.DoesNotExist:
            return data['username']
        raise forms.ValidationError('This username is already taken.')

Here we can validate that the usernames are not repeated.

Prob. You want to create a field which has cross field validations.

Ans. Create a field with a .clean

class UserForm(forms.Form):
    username = forms.CharField()

    password1 = forms.PasswordField()
    password2 = forms.PasswordField()

    def clean(self):
        data = self.cleaned_data
        if "password1" in data and "password2" in data and data["password1"] != data["password2"]:
            raise forms.ValudationError("Passwords must be same")

Problem.

You need a form the fields of which depends on some value in the database. Eg. The field to be shown are customisable per user.

Create a form dynamically

def get_user_form_for_user(user):
        class UserForm(forms.Form):
            username = forms.CharField()
            fields = user.get_profile().all_field()
            #Use field to find what to show.

This post provides much more details

Prob. You need to create a Html form which writes to multiple Django models.

Ans. Django forms are not a one to one mapping to Html forms.

#in forms.py
class UserForm(forms.ModelForm):
    class Meta:
        model = User
        fields = ["username", "email"]

class UserProfileForm(forms.ModelForm):
    class Meta:
        model = UserProfile

#in views.py
def add_user(request):
    ...
    if request.method == "POST":
        uform = UserForm(data = request.POST)
        pform = UserProfileForm(data = request.POST)
        if uform.is_valid() and pform.is_valid():
            user = uform.save()
            profile = pform.save(commit = False)
            profile.user = user
            profile.save()
            ....
    ...

#in template

    {{ uform.as_p }}
    {{ pform.as_p }}

Prob. You want to use multiple forms of same type on one page.

Ans.

a. If you want a datagrid style ui, use formset.

from django.forms.formsets import formset_factory
forms = formset_factory(UserForm, extra = 4)
#

Formsets are described much more comprehensively here

b. If you do not need a datagrid style ui, use prefix argument to forms.

Eg. you have a survey app, and you want a page with all questions from that survey displayed.

#IN views.py
def survey(request, survey_slug)
    ...
    questions = survey.questions.all()
    question_forms = []
    for question in questions:
        qform = QuestionForm(question=question, prefix = question.slug)
        question_forms.append(qform)
        ...
    if request.method == "POST":
        for question in questions:
            qform = QuestionForm(question=question, prefix = question.slug, data = request.POST)
        #Validate and do save action
        ...
    ...

Do you subscribe to our feed? We recently made a full text feed available, so if you are using the old feed, you should change it. Subscribe now.

Tools of Pro Django developer – aka What powers dinette and almost every app we write.

shabda — Wed, 13 Jan 2010 12:32:11 +0000

There are some tools and apps which we use with almost all apps we write, and in particular which, we used for dinette. Here they are broken into useful during development, and (also) useful post development.

During Development

Ipython and ipdb

Ipython is a enhanced shell for python. Ipdb similarly add extra capacity to the builtin pdb debugger. It is extremely convenient to drop into a ipython shell right where a complex piece of code is being hit.

from IPython.Shell import IPShellEmbed
ipython = IPShellEmbed()
ipython()

Of course this does not allow you to step through, so if you want to step through your code, you need to do

import ipdb
ipdb.set_trace()

Of course, you can just do pdb.set_trace(), but with tab completion and syntax highlighting, using ipdb is a no brainer.

South

South adds schema migration to Django. It has lot of advanced options, but just three command will get you along way.

Convert a normal app to use the south way.

./manage.py convert_to_south

Once you have made any changes to your apps model, write a new migration which can update the database to latest models.py

./manage.py startmigration appname nameofmigration --auto

Once you have written a migration, write a command to update the db.

./manage.py migrate appanme

Django test utils

When you are running tests, a huge time sink is the time spent dropping and recreating tests. You might add just a single test, and the default Django testrunner will spend a huge time recreating the database. Enter manage.py quicktest which reuses databases between test runs. One of the side effects of this is that if you modify models.py between test runs you should manually recreate the database.

The tests (or whatever little of it exists) for Dinette were written using testutils’ testmaker.

Django extensions

Django extensions, (earlier Django command extensions) is a app which adds extra commands to manage.py. It has lot of goodies, but just ./manage.py shell_plus makes it worthwhile. (It imports all the models from all the apps automatically).

Get the full list at Github

Django debug toolbar

I do not personally use it but some people on our team swear by it.

After development

Django-pagination

I have decided on a standard way to build apps which need pagination. a. Build apps without pagination. b. The night before release spend an hour and add pagination to all pages. Really this is all you need

{% load pagination tags %}
{% autopaginate queryset %}
....
{% paginate %}

There is no change required to the views.

sorl-thumbnails

To thumbnail an image.

{% thumbnail image size %}

“Things should be as simple as possible, but not simpler.”

django-compressor

During development we work with multiple unminified js and css files. Django-compressor takes care of minifying and compressing it when we deploy. All we need to do is,

{% compress css %}
...
all css files
....
{% endcompress %}


{% compress js %}
...
all js files
....
{% endcompress %}

Haystack

Haystack is “modular search for Django”. It make writing search views as easy as writing the admin. You declaratively tell what fields you want to search on, and Haystack can take care of creating and updating the index, and providing a generic view to handle the search. Check a search view written using Haystack http://uswaretech.com/forum/search/?q=django

To everyone who contributed to these apps, thanks. Django development won’t be the same without these great tools. This post was inspired by Kevin Fricovsky’s post post, The apps that power Django-Mingus and is stolen about 50% from there. Thanks.

We build Amazing web apps, and we can build it for you. Contact us today.

django-forum

shabda — Thu, 07 Jan 2010 11:19:03 +0000

twitter ready version:

We have released a Django forum application, with some cool features not in any other Django based forum. You can get it here or see it in action.

blog version

There are quite a few Django based forum applications, so why another? Its a bit of a rhetorical question, as the answer is “none of them met my needs exactly, so we created my own”, as you might expect.

Without further ado here is a list of features. It is available on uswaretech.com/forum/.

Based on, inspired by and ripped from PunBB. (Thanks!)
PunBB like 3 phased hierarchy [Forum]->Subforum->Topic->Post
Tightly integrated with Socialauth. (Screenshots)
Gravatar support
Moderation features (Close, stikify, make announcement etc.)
Ajax based posting

We are starting our forums based on this app, so we plan to be supporting and developing this for foreseeable future. Fork this on Github or check this out now.

Screenshots

Main page

Post page

We build amazing web apps. Contact us

No related posts.