haggholm | Web framework musings: Django time?

Starting to get tired of wrestling with the recurrent bugs in my homebrewn framework that prematurely terminate sessions. I’m not too concerned about them since they do not threaten security—I wrote it in a rather paranoid fashion, and all session or authentication related bugs since the first week or so have had to do with premature termination rather than excessive permissiveness—but they do annoy me.

Perhaps it’s time I refactored my website, and maybe a webapp or two, to use Django. I’m sure I could fix these bugs with the help of improved logging, but is it worth the effort? Beyond the “just for fun” reason, I wrote my framework in order to learn about framework development, and to get an inside understanding of session management and security concerns like proper password management, authentication, CSRF protection, and so forth. I did not write it with either a belief or an intention that I would write my own production-worthy system to rival a major project like Django.

I’ve learned a lot of lessons¹, and written some decent code², but if I want to keep working on this framework, I will have to start to Do Things Properly—add unit tests, track down these pesky session termination bugs, and so forth. I consider unit tests, proper logging, and so forth essential to production code, but not to fun exploration projects. I’m rather beginning to think that my framework has reached the point where it should either be made serious, or phased out. The latter sounds more sensible, and less symptomatic of NIH.

Besides, it can’t hurt to learn Django, can it?

¹ Apart from learning about CSRF protection, the most interesting problem I got to solve was probably SQLObjectInherit, which provides (in SQLAlchemy language) single table inheritance for SQLObject, using decorators. It’s not perfect (there are some edge cases where you request an object from some class C and expect a subclass D, but erroneously get the parent class), and I was contemplating switching to SQLAlchemy largely for this reason. It’s also the one thing that makes me question the Django decision, but the lack of single table inheritance is probably a smaller deal, in the long run, than all the myriad problems it solves.

² Decent for a non-unit tested system, which is very different from a production ready or production worthy system.

Flat | Top-Level Comments Only

As you say, if the point was to learn about framework development, eating your own dog food for a while is necessary for testing and ongoing refinements; but if you consider that project (learning) formally done now , let somebody else deal with the nuts and bolts and let yourself focus on Making Things.

Django is certainly powerful, but it has a tendency to want to do _everything_ automatically, including database table design. If you want to design your own database layout, it actually gets in your way rather drastically.

I also found that doing simple things (such as form validation) tends to be overly complicated.

It's also rather slow.

I’ve only played a little bit with it thus far, but if it gets in the way of database layout, it’s not clear to me how. (python manage.py inspectdb was rather helpful in spitting out a Django representation of my existing database schema—excepting, of course, the Django-specific tables for users, authentication, etc.) Haven’t looked at form validation yet. Slowness is what it is; not too concerned at the moment.

Would you use a different framework? I haven’t really looked at Pylons, TurboGears, etc.—figured I might as well start taking a look at one of the big ones to see what it’s about, but am in no way wedded to the selection. It seems (http://wiki.python.org/moin/WebFrameworks) that Pylons and TurboGears, at least, offer the advantage of working with the more powerful SQLAlchemy…

My only real concern is to switch to something that does not require me to reinvent the wheel.

Web framework musings: Django time?

let it go

no subject

no subject