django has two classes called ValidationError

4 February 2010

There is one in django.core.exceptions and one in django.forms.util


Using that space age IDE Eclipse I have to say I'm enjoying how much time I've saved just going shift-command-O to organize and resolve all of my imports.  But today I've just lost a few hours due to my ok-ing the wrong class.


Quite mysterious it was, I raised a ValidationError (core exceptions one) in my form's clean() and watched as the try: except ValidationError: in django's full_clean() completely ignored my error and propagated it up.


But what is the django crüe doing naming two classes that ?  django.core.exceptions is quite vague, it just says "An error while validating data."  Its used for db Field validation errors.  


I guess its as confusing as naming two entire class heirarchies 'Field' : one for db fields and one for html form fields.  As though the two always went hand in hand, which they don't.  


Another large problem I have recently is that a form field and its form widget are never allowed to talk to the object model, only to a single db field. I often have built fields that need to save to several fields on the model, and the clearest place to do this is by concentrating most of the power into the Form class.  


An example is an address input that I use that has a display address, postal address and map address.  The interface is complex, uses google maps and in the end also saves longitude,latitude, geo_accuracy, address, street, zip, city,state, and country objects. As a field or widget its not allowed to do all that.  It has to be tied to a form or the form has to call a function on the field to offer it access to the Model.


Another pet peeve (while we've got me in a tizzy still):


 


    # Give this new form class a reasonable name.

    if form == ModelForm:

        class_name = model.__name__ + 'Form'

    else:

        # CX: leave a clue that the form IS the form that you passed in

        # otherwise you have no clue what happened to your form class

        class_name = form.__name__ + "FromFactory"

 


    # Give this new form class a reasonable name.


    if form == ModelForm:


        class_name = model.__name__ + 'Form'


    else:


        # CX: leave a clue that the form IS the form that you passed in


        # otherwise you have no clue what happened to your form class


        class_name = form.__name__ + "FromFactory"


In django's normal trunk they take the ModelForm class that you wrote, they jack it into some cyborg reconstruction routine wherein it seems that your class is copied into another class and then ...  given the same name as your class and even inserted into the module that you wrote yours in.  This makes debugging hell.  You think you are looking at your class, but its been factoried.  Hence my change above to the naming convention so that the poor programmer can be informed that something happened.


ok, back to unit testing hell.

 


 


 


  • more posts in tech notes
    • django.db.utils.DatabaseError: relation "django_content_type" does not exist

      p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco} I was getting an error while running unit tests and the test database was failing to be created.django.db.utils.DatabaseError: relation "django_content_type" does not existeventually found the problem.  I had the following in a file that was imported to a models.py:hrd_type = ContentType.objects.get_for_model(HttpReferrerDomain)The idea being that it can just set the var when it loads up and after that its always there.  But this means for creating a fresh database, the db is ...

    • GDAL fails to build: `.rodata' can not be used when making a shared object; recompile with -fPIC

        libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtbeginS.o .libs/libgdal.la.lnkscript  -L/usr/local/lib /usr/local/lib/libgeos_c.so /usr/local/lib/libgeos.so /usr/local/lib/libexpat.so -L/usr/lib -lpq -lrt -ldl /usr/lib/libcurl.so -lssl -lcrypto -lz -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crtn.o         -Wl,-soname -Wl,libgdal.so.1 -o .libs/libgdal.so.1.13.2 /usr/bin/ld: /usr/local/lib/libz.a(crc32.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libz.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libgdal.la] Error 1 make[1]: Leaving directory `/home/crucial/tmp/gdal-1.6.2' ...

    • installing MySQLdb on Ubuntu (mysql-python)

      MySQLdb is the python support bindings for MySQL.  Not that the name would lead you to beleive that. Its sourceforge page calls it http://sourceforge.net/projects/mysql-python/ which makes more sense. you need setuptools, which you usually already have:     sudo aptitude install python-setuptools You need MySQL-devel to compile, but its not called that, its called: libmysql++-dev on Ubuntu     sudo apt-get install libmysql++-dev download MySQLdb itself from:     http://sourceforge.net/projects/mysql-python/     # the version you download will be more recent     tar xfz ...

    • postgres login as admin user postgres

      When installing postgres a user will be created named 'postgres' with a password of '!!' which means "cannot login".  But yet you need to login as that in order to run psql (the postgres db shell) to create other users and to create database templates. The solution is to first log yourself in as root (in your normal shell): su root (enter password...) then you will no longer be subject to password checks and you can login in as user ...

    • Full index for tech notes
Strategy Decay
Luv n' Liv (Timeblind mix) Timeblind mix : Liv n Luv
Luv n' Liv (Timeblind mix) Timeblind mix : Liv n Luv

RSS Subscribe