Ian Bicking: the old part of his blog

Turbogearsandpylons comment 000

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.

Comment on Re: TurboGears and Pylons (a technical comparison)
by Ian Bicking

Comments:

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