This post originated from an RSS feed registered with Python Buzz by Carlos de la Guardia. Original Post: Web heresies and Python frameworks Feed Title: I blog therefore I am Feed URL: http://blog.delaguardia.com.mx/feed.atom Feed Description: A space to put my thoughts into writing. Latest Python Buzz Posts Latest Python Buzz Posts by Carlos de la Guardia Latest Posts From I blog therefore I am

Seaside is an innovative web application framework, written in Smalltalk. You may have heard something about it recently, probably referred to as a "continuation based framework". Avi Bryant, the mind behind Seaside, will be speaking about it from an interesting angle at the oncoming O'Reilly open source convention this July.

In his talk, Avi will present Seaside as a heretic web framework, because by design it goes against what he says are today considered as best practices for web development:

• Share as little state as possible.
• Use clean, carefully chosen, and meaningful URLs.
• Use templates to separate your model from your presentation.

This list made me wonder, how orthodox are Python web frameworks in this respect? A lot, I would say (not that this is a bad thing or anything).

The clean URL bit really is a point stressed strongly by some frameworks, like Zope. This seems to me to be a consequence of Python's own claims of readability and cleanliness and I think most Python frameworks strive for this.

Of course, Seaside doesn't just break this nice URL practice for the sake of ugliness, like some enterprisey CMS tools appear to do, but because it is necessary for its use of continuations. I see no reason why a Python framework would do this (well, unless it is built with stackless Python in mind).

The use of templates also seems to be a given for Python frameworks, though it is very hard to agree on a common way to do it. Template engines for Python are so varied and use so very different approaches and levels of flexibility, that one has to wonder if an API would at least reduce the time spent arguing about the merits of each template engine (of course, human nature being what it is, the flame war would then turn to be about the best way to design the API).

Seaside uses an HTML generation API for a number of reasons, the main one probably being the desire for writing all of the application using Smalltalk. In the Python world, this same reason has been used, for example, to criticize Zope's ZCML. A designer working with a Seaside developer would use CSS to alter the application's presentation. This can be done in a very elegant way, since Seaside uses a concept called halos to allow the designer to take a running copy of the application and alter the CSS of any defined element in place.

As for state sharing, the problem is, we all know, that the stateless request/response HTTP cycle makes it difficult to do this. You can use hidden fields or global sessions to get around it, but these are far from ideal solutions. Besides that, many session implementations requiere cookies and they can be turned off by the users. I think most Python frameworks use some kind of global sessions for this.

Seaside uses continuations to be able to store and recover the state of an application (actually, only those objects registered for this), which allows things like having the application flow to be expressed sequentially (but not necessarily executed in that order) or the back button really work like most users would expect.

Since Python doesn't support continuations, this kind of control flow tricks can't be done by Python frameworks (but see the reference to CherryFlow above). Still, I think it's interesting to see how Seaside and other frameworks attack this problem.

Seaside is a very interesting framework, worth looking at, if not for developing with it, at least to challenge our ideas of how web development should work. Like Avi said, just keep an open mind.