Ian Bicking: the old part of his blog

Re: TurboGears and Pylons (a technical comparison)

Perhaps this drifts off the topic, but I'm not terribly enthusiastic about any of the basic MVC frameworks, whether they be TG, Pylons, Maypole, Catalyst, or what's-that-obscure-Ruby-one? They all seem to provide little more than some basic abstraction over CGI, and most always depend on CGI-like handling of things like forms. Even where form abstractions are available, there's usually no support for concepts like viewstate (JSF, ASP.NET) conversation (Seam) or flow (Spring, Rife, Aranea). Heck, there isn't really even a similar concept to Stateful Session Beans, we're usually stuck pulling data out of a monolithic session object to restore session state, when we should simply be able to instantiate a new controller instance per session and let the server collect them when they're done.

I'm not saying MVC is "old and busted", since component frameworks invariably boil down to the style anyway, but it pains me to handle state the old fashioned way, by binding request parameters and form fields myself, reading session state myself, and initiating and committing extended transactions, sing along now, by myself.

There are some component frameworks like Prado for PHP (!), but nothing of the sort for Python. It'd be nice to look well beyond Rails, stop disparaging the "enterprisey" frameworks, and start mining them for their actual useful bits.

Comment on TurboGears and Pylons (a technical comparison)
by Chuck Adams

Comments:

They all seem to provide little more than some basic abstraction over CGI, and most always depend on CGI-like handling of things like forms.

CGI of course is a basic abstraction over HTTP, and so we are basically relying on HTTP-like handling of things like forms. I like handling things like what they are. HTTP is HTTP.

we should simply be able to instantiate a new controller instance per session and let the server collect them when they're done

Well, you could do this if you were so inclined. You could do something like:

def wsgi_session_app(environ, start_response):
    session = environ['some_session']
    controller = session.get('current_controller')
    if not controller:
        controller = session['current_controller'] = make_controller(environ)
    return controller(environ, start_response)

There's not a clear end scope for sessions in Pylons; they just time out eventually. And if you wanted stuff like a usable back button you'd need to start saving the controller at multiple points. All of this assumes that the controller only contains pickleable objects (and for more reasons than just because it may need to be serialized). But so it goes.

it pains me to handle state the old fashioned way, by binding request parameters and form fields myself, reading session state myself, and initiating and committing extended transactions, sing along now, by myself.

Then as you do that you should start to write library routines that abstract out your work. I haven't really worked with stuff like viewstate or conversations, but whenever I hear explanations it just sounds so complicated. Maybe I just don't write enough long multipage forms where it would be useful. Nevertheless, though probably more code could be written for this use case, I would be skeptical about solving the problem generally.

# Ian Bicking

Certainly a SFSB (Stateful Session Bean) isn't too hard of an idea to implement by just shoving it in a session myself. Not too scalable, and real EJB containers are a lot smarter about state replication than that, but it would work. But to wax flippant a bit, the entire framework isn't something I couldn't reimplement by myself too once I understand how it works. Yes, some pieces are complicated, and hard to get right, and that's precisely why frameworks are there to make them easy to _use_ so that the end user doesn't have to reinvent it in a buggy way that won't interoperate with anything else.

Viewstate is another of those "evil" things everyone loves to hate about ASP.NET and JSF, but that no one's really come up with a satisfactory alternative for (it's something you can store server-side too, which removes most objections to the hideous clutter it adds to the client side html).

I guess I'm just bemoaning the glut of classic MVC frameworks and the lack of anything else like a Prado or Seam -- let alone a Seaside.

# Chuck Adams

Viewstate is another of those "evil" things everyone loves to hate about ASP.NET and JSF, but that no one's really come up with a satisfactory alternative for (it's something you can store server-side too, which removes most objections to the hideous clutter it adds to the client side html).

Maris Fogels has just started playing around with a ViewState helper for Pylons:

http://pylonshq.com/project/pylonshq/wiki/ViewState

# Philip Jenvey