linuxbutler

When learning about formsets, it was never clear to me how many submit buttons there would be:

• one per form
• one for the whole formset.

It turns out, there is one submit button for the whole formset.

I created a django project and application and the associated database. I created the tables with syncdb over a couple of development iterations. I can still run ./manage.py syncdb in the original project with no output. I tried copying the project to another directory, creating a new (empty) database (db-dev) and adjusting the settings.py in the new project. When I run ./manage.py syncdb in the new project, it says:

psycopg2.ProgrammingError: relation "fileshare_language" does not exist

Shouldn’t django create the relation (table) as part of the syncdb operation? models.py:

    class Language (models.Model):
        '''
        Class to represent the choice of languages available so far
        '''
        language = models.CharField (max_length = LANGUAGE_LEN)
    
        def __repr__ (self):
            return self.language
    
    
    class Clients (models.Model):
        '''
        Class to represent the clients.  This class is associated
        with the Django User Model (where the name and email address are stored).
        '''
        user = models.ForeignKey (User, unique = True)
    
        filedir = models.CharField (max_length=FILE_PATH_LEN)
        language = models.ForeignKey (Language)

    ...
    
    class AddClientForm (forms.Form):
        '''
        Form for adding a client
    
        Also adds a django user and creates a directory
        '''
        username = forms.CharField (label = ugettext_lazy (u'Username'),
            widget = forms.TextInput (attrs = {'class' : 'form_object_bg' }),
            required = True)
        firstname = forms.CharField (label = ugettext_lazy (u'First Name'),
            widget = forms.TextInput (attrs = {'class' : 'form_object_bg' }))
        lastname = forms.CharField (label = ugettext_lazy (u'Last Name'),
            widget = forms.TextInput (attrs = {'class' : 'form_object_bg' }))
        email = forms.EmailField (label = ugettext_lazy (u'Email'),
            widget = forms.TextInput (attrs = {'class' : 'form_object_bg' }))
        filedir = forms.CharField (label = ugettext_lazy (u'Files Location'),
            required = True)

        language_qs = Language.objects.all ().order_by ('id')
        language_choices = []
        for ll in language_qs:
            language_choices.append ((ll.id, ll.language))
        language = forms.ChoiceField (choices = language_choices,
                                      label = ugettext_lazy (u'Language'))
    
        is_admin = forms.BooleanField (label =
                                       ugettext_lazy (u'Is administrator'),
                                       required = False)
    
        password = forms.CharField (label = ugettext_lazy (u'Password'),
            widget = forms.PasswordInput (attrs = {'class' : 'form_object_bg' }),
            required = True)
        pwd_confirm = forms.CharField (label = ugettext_lazy (u'Password Confirmation'),
            widget = forms.PasswordInput (attrs = {'class' : 'form_object_bg' }),
            required = True)

It turns out that the attempt to put the language choices in a dropdown list in the form is causing syncdb (and every other ./manage.py command) to fail with that traceback. I suppose the quick fix is to create the table and populate it manually in the empty database, and then run syncdb. Later I can fix up the form so it doesn’t have code in the middle of the field declarations. Oops.

I wrote a small app to allow people to sign up to declare publicly, in a theme-based community, their intention of completing a project by a certain date. It was good practice to learn about django users and authentication and forms.

I wanted to allow the users to sign up and make their own accounts — but obviously I didn’t want them to mistakenly use a username that was already taken. But there is no obvious way to do that in the Django framework. The form validation takes place in a class that does not have access to the request information (where the user id is kept).

Fortunately for me, Ian Ward has already run into that problem and has solved it, both for plain old forms and for modelforms, in a very neat and elegant way.