Richard Jones' Log: Django full of "headaches"

Impressively quick deletion!

Took longer to write (which was quite cathartic, and was most of the point of writing it). Only takes a few clicks to delete :)

Hi Richard, I would actually like to see what you had to say :-)

As a fellow web developer who is about to make a decision on whether to stick with Django or not, I would appreciate hearing any opinion you might have, if you wish to share it.

-Sw.

Given that all aggregators picked up the introduction, you could at least have kept that part around...

(I agree with Simon, btw. Maybe you could post a bullet-point summary?)

Ah, so I wasn't quite fast *enough*. OK, I'll put up a summary.

I must have been like, right on your schedule, since I saw the original rant.

My impression was just that you were trying to speed your development by using the form stuff in Django. But that was a bad idea. I suspect if you had hand-coded the public side of the web interface -- and ignored any potential features you could get from reusing code from the admin interface -- you would have done fine.

Which maybe implies that the admin reusability is something of a red herring, but not that it's actually *bad*. Just that, if it works out of the box, cool, if it doesn't, do it by hand.

When you say "the form stuff" are you referring to the Manipulators and FormWrapper? I definitely got the impression from the docs that it's OK to use them outside the admin interface.

I think so, but I don't know the terminology. I don't mean it's not OK, but maybe it's not a good idea, especially if you aren't making lots of apps, just a one-off thing (and thus the time invested in learning the form abstractions in Django won't necessarily pay off that much in the future).

My general experience with form abstractions are that there's lots of mental overhead to them.

The whole Manipulator, validation and model manipulation headaches are pretty nasty alright, I've been grappling with some of the issues. However there is hope, the magic-removal branch (which is due to land "real soon now") is going to fix a lot of these problems, in particular making the model creation and manipulation a lot more logical and nicer, and moving the validation into the models themselves. Apparently none of the django guys have been too hot on the whole manipulator thing as it stands either.

It does indeed seem that Django is not what you are looking for. We (http://us.pycon.org/) used Django to do alot of rapid development for some really nice schedualing apps, and the validation model was crutial (really complex validation with different validation types depending on the view (public or admin).

It seems your problem was trying to re-use the admin stuff, which is trying to be too generic and is extreemly slow for more complex cross-model editing.

With that said, if what you need is alot of custom permission views and transaction models, I would recommend Plone. Especially if you want to allow people to write python code to extend the site. Plone's restricting run python is very very cool, and their admin is the best, bar none. The plugin apps are great and the support is fantastic. The problem is the learning curve (realy the Zope learning curve). Plone is a huge framework which you mainly modify directly in a browser.

Plone is a great framework for content management style sites. Django is great for content publishing. TurboGears is great for Web2.0 apps. Use the right tool for the right problem. (Sorry CherryPy, but you are too primitive).

Django and TurboGears still have alot of rough corners, but both have vibrant communities behind them and are working hard to address the problems they have and are changing fast (this is good and bad). Plone is also still growing, but it has alot more history and development behind it and is very stable (which means some changes happen slower like the migration to Zope 3).

I certainly do not intend to contradict your experience, I mean, how could I. But I have found much to love w/ django. I don't use the admin at all. I see to many people on the list or IRC attempting to twist it to their delight only to be disappointed when it only gets them 80% there. It isn't meant for building applications necessarily but rather quick and easy CRUD.

I am quite fond of manipulators and the formwrapper; however, I spent six weeks basically re-writing portions of it to better fit my needs. Since having completed that, I have built several significant applications and can do things in 10 minutes that would easily take an hour or two doing it some other way. There is much w/ django that isn't for the faint of heart, I will agree. It is kind of ironic when someone complains about the documentation when you consider it relative to some of the other frameworks out there. In this light, I believe they are quite good.

Add to that the fact that you can actually make your way through the codbase, unlike oh I don't know... ZOPE and it fits my needs nicely.

No, I'm not trying to re-use or re-task the admin interface stuff. I'm just trying to use the Manipulator stuff (which I understood to not mean "re-use the admin interface" but I guess I could be wrong?)

My point w.r.t. the admin interface is that Django seemed to me to be geared towards using the admin interface for all data changes, and then the rest of Django for presenting that data, with minimal data manipulation through the non-admin interface.

I've found that the Django magic coupled with large gaps in the documentation has very much gotten in the way of my understanding a) what I should be doing and b) what it is doing. I am fully prepared to go and look in the source to solve a particular problem (hey, I'm a Zope developer by day) but with the Django magic it's simply not at all clear where to look in the code to figure out what the hell's going on.

My example with the file upload is a prime one. It took me a long time to figure out exactly where to look to discover that for a FileField I actually had to render the "content_file" widget to the user, not the "content" widget. That there was also a valid (though utterly useless) widget rendered when I used the "content" widget was something that had me chasing up wrong leads for hours.

I also don't have the luxury of six weeks to investigate and/or rewrite parts of Django. I just need something that works now and though I've finally gotten there (i.e. the framework is capable of it) it's taken much pain to do so.

Doug: the previous incarnation of the PyWeek website was a Zope site:)

It wasn't quite right though, and I was moving to new hosting, and I wanted to learn one of these new-fanged web frameworks, so...

Overall I'm happy and impressed w/ the documentation considering the pre 1.0 status and all. But, I had trouble with the file upload process and had to pdb through it to figure it out. That one, along with image uploads, comes up frequently.

And I definitely agree about the "magic". It isn't so overwhelming to muck through but it sure makes things needlessly painful. You are probably aware at least much of the magic is being weeded out in the magic-removal branch. But I wouldn't go looking there yet.