Django Formsets, the worst thing ever?

This kind of thing really attracted me to django, but then the usability of it goes entirely out the window when you take a closer look.

Formsets are basically a container for an arbitrary collection of forms. A form is a abstraction layer for UI, but I’ve seen they (or rather ModelForms) can be somewhat helpful as a funnel for POST vars and validation of the model. Maybe my issue is that the use I’ve found for them is not the primary concern people have.

from https://docs.djangoproject.com/en/dev/to…

>>> ArticleFormSet = formset_factory(ArticleForm, formset=BaseArticleFormSet)
>>> data = {
...     'form-TOTAL_FORMS': u'2',
...     'form-INITIAL_FORMS': u'0',
...     'form-MAX_NUM_FORMS': u'',
...     'form-0-title': u'Test',
...     'form-0-pub_date': u'1904-06-16',
...     'form-1-title': u'Test',
...     'form-1-pub_date': u'1912-06-23',
... }
>>> formset = ArticleFormSet(data)
>>> formset.is_valid()

See, how you would expect something like this to work is it would take in a list, or at least a dict with a list. But no, they have you cat “form-n-” to the field name. This is just so sloppy I have to point it out.

They spent so much time figuring out how to take away customizability from the front end, they weren’t paying attention to the backend.

Django nonrel (noSQL) (app engine)

I’ve been working with this for the last couple weeks. I have been doing this for a couple reasons.
1) I wanted to play with noSQL
2) I’m developing and deploying with the google app engine — the app engine does have a mySQL option (Cloud SQL), but they have no free version of this — so to do a GAE app (entirely (including data) in GAE), you have to use the google data store or pay for SQL.

Now doing the design in a key-value noSQL wasn’t too bad. I just had a design that had each object containing the ids of the other objects that were associated with it both ways. This was somewhat redundant she thinking about it in a relational way, but it made queries simple and fast. The overhead is making sure the software keeps the ids updated in all related objects I.e. if something is deleted.

That wasn’t so bad. It was a fun to design things differently than I’m used to. Then I fleshed out the models in django.

The issue I ran into was django-nonrel. This is the project that converts django to be able to deal with non relational DBs. This changes core django abstraction models and consists of apps that can be installed locally or globally. So I installed them locally because I don’t like the idea of altering the framework globally.

It did not work with the latest version of django.

So I read through the docs a little more carefully to discover the core team quit this project over a year ago. Because noSQL wasn’t right for their projects and Cloud SQL was now available for app engine. The guy who took it over isn’t keeping it up to date with django. He’s about a year behind. It’s working with django 1.3. Current version right now is 1.5.1. That is enough to throw errors.

If django is making changes in point releases that cause the django-nonrel to become out of date, either django isn’t doing a good job at maintaining backwards compatability or (much more likely) django-nonrel project isn’t doing a good job keeping away from hacky implementations that rely on very specific django references.

I don’t have the time to debug django-nonrel. It’s like 4 apps that go in your django project.

Additionally I worked out what the cost of Cloud SQL would be for development and I can deal with less than $2 a month. When it goes production I can worry about dealing with my teams extremely poor mysql management or get my group to pay for a more substantial Cloud SQL instance.

Harmony Lab

One of the nice things about my job is being able to take credit for interesting student projects. We’ve got an awesome pool of kids that are always doing stuff. They have cool ideas, write up a sloppy implementation and don’t want to maintain it. So it comes to us and we have the opportunity to polish it and expand it for use to a broader audience.

The most recent of these projects to come along is the newly named “Harmony Lab”. (Formerly GoFigure / Piano Lab) This is a nice application that allows you to hook up a midi keyboard to your computer and get information about music theory stuffs (and by “music theory stuffs” I mean I haven’t yet wrapped my head around everything the application does).

Currently it is an application that uses an applet to get the midi data from the keyboard and a ton of javascript for visualizing the key/chord. And a ton of javascript is never a pretty thing.

We are giving it a backend for some authentication, cleaning up the javascript where we can, and adding some extra functionality — hopefully not too much extra. This is a cool project, but it’s usefulness is limited to one or two classes.

What’s cool about this is it’s a (potentially) simple application so it lets us play with (learn) something new (to us). So we went for python Django.

It’s available on github from the start.