Posts tagged: WEB FRAMEWORKS

Even if all the recent interest in Django hasn’t stopped other people from trying to create Python web frameworks, I think it has raised the bar for what people decide to unleash on the world.

Enter TurboGears.

Though it’s billed as a “megaframework,” its structure is almost identical to plain ol’ frameworks Subway and Fanery: a stack combining SQLObject, CherryPy, and a templating system (in this case, Kid). TurboGears also adds Ajax support via MochiKit.

It’s installable via setuptools; even if this means you need to install setuptools first, the net effort required is still less than manually installing TurboGears and its four separate framework components. Dependency management is no small thing when you’re combining several pieces that are all evolving rapidly.

As of yesterday, Django has changed its model syntax. So code that formerly looked like this:

class Comment(meta.Model): 
    fields = (
        meta.TextField('comment', 'comment', maxlength=3000), 
        meta.CharField('headline', 'headline', maxlength=255, blank=True)
    )

will now look like this:

class Comment(meta.Model): 
    comment = meta.TextField(maxlength=3000) 
    headline = meta.CharField(maxlength=255, blank=True) 

Sweet. This brings Django more in line with the Rails philosophy that syntax matters. Making things easier for the developer to type, remember, and read can only bring good things.

Sam Newman has posted a useful high-level comparison of Django and Rails on his site. In it, I think he hits on one little-discussed reason why these two projects are grabbing so much mindshare right now:

[Rails and Django] … historically would have ended up being written in Perl or PHP - but ended up being written in Ruby and Python respectively.

When I heard DHH speak at OSCON, he mentioned switching to Ruby after giving up on trying to make PHP do the kind of stuff he wanted to do. Back in July I asked Simon Willison (of the Django team) about PHP; he said that both he and Adrian Holovaty had worked in PHP for years, but it was Python that “gave us the flexibility we needed to pull everything off.”

I sat in on most of DHH’s Ruby on Rails presentation this afternoon, and I have to say I’m in danger of catching the religion. Like a good cult leader, Hansson is energetic, intelligent, and unwavering in his faith that his is the right path. Within 30 minutes of the end of the session I had installed Rails via DarwinPorts, though my schedule hasn’t left me much time to play with it.

Ruby on Rails has inspired a lot of admiring imitators. In theory you can keep on using Python, Perl, PHP, Java, or C# while reaping the benefits of the Rails model. Ruby fanatics will tell you that the language’s intrisic qualities are part of the bargain, which may be true, but all this activity is not just faddishness – Rails is essentially doing evangelism for a structured style of rapid development that is unfamiliar to many people.

I’ve been on Web Application Framework Safari for the past couple weeks. The new hotness is Ruby on Rails, which has inspired lots of imitators. Not necessarily a bad thing. Because I do so much PHP work I was curious what kind of work had been done to bring this style of development to PHP. I found CakePHP.

I’ll say this for them, they write good enough documentation that I actually had a working mini-site at the end of the first tutorial I tried. Pretty good compared to some of the projects I’ve seen with more high-minded architecture and no usable documentation at all.

It was a busy week in the world of Python web frameworks.

The CherryPy project released its 2.1 beta.

Subway, a Ruby-on-Rails-style stack that builds on CherryPy, released its first milestone.

But the biggest news has been the release of the Django framework. Like Rails, Django grew out of real, production web apps and is going public with a lot of momentum. It seems to strike a nice balance between power and simplicity. Doesn’t hurt that the website looks pretty, either…