[Chicago] Web Frameworks?

[Ian Bicking]

Massimo Di Pierro wrote:
> Hello everybody,
> 
> as you know I teach web development with Python at DePaul and I would 
> like to share my views on Django, Turbogears, Pylons, etc.
> 
> About the database-access API:
> 
> The Django API are better than SQLObjects and SQLAlchemy. They would be 
> even better if they could take advantage of the “>=” syntax (like 
> SQLObjects) instead of the __gt syntax. SQLAlchemy goes in the wrong 
> direction by making life too difficult for the developer. Teaching 
> SQLAlchemy would be as difficult as teaching SQL. Storm.Canonical API 
> seems even better than Django's API.
> 
> About template languages:
> 
> Kid/Genshi are the best. Students know XML therefore Kid is easy for 
> them. Moreover it is the only template language that forces users to use 
> write good XML. We teach students that they should use XML for nearly 
> all web data exchange therefore Kid is perfect.

I don't think this is that important for a professional web developer, 
but educationally a markup-based language seems really good -- it should 
get the students thinking about the document as a tree, not as text.

Definitely Genshi is the better of the languages.  You also get an 
introduction to some nice XMLisms like XPath.

I've always considered template-based XML generation to be weird.  I 
think it should be generated directly in Python.

> About Urls and Routes:
> 
> I do not like Django urls.py because they go in the direction of 
> duplicating information instead of forcing users to follow good 
> practice. For example, if I change name to a controller I also need to 
> edit urls.py and vice versa; moreover I can have a form action with a 
> different name than the name of the corresponding controller. This is 
> very confusing to students. CherryPy and RoR instead enforce good 
> practice. The ability to match arbitrary URLs should be optional and 
> specified at the level of the controller (perhaps with a decorator).

CherryPy and RoR definitely *don't* enforce good practice.  It's a lot 
more convenient than an explicit enumeration of every URL in the system, 
but it's not better practice.

Pylons is like RoR here, with both explicit routes like Django and 
implicit ones like CherryPy.

> WSGI and mod_python:
> 
> WSGI is an excellent idea but if it does not work with mod_python it is 
> useless today. mod_python is faster, easier to deploy, and does not 
> require advanced Apache knowledge. mod_rewrite is  difficult and way 
> beyond the scope of a typical web development course.

Eh?  There are some WSGI/mod_python hookups, but for some reason they 
aren't well maintained.  I think there's one that is better maintained 
now, though.  mod_python is not widely supported in shared hosting 
situations -- quite the contrary, it's things like FastCGI that are more 
likely to be supported.  And if you really want Apache integration then 
mod_wsgi is both faster and I think more clear in scope than mod_python.

> Forms:
> 
> There is a perfect language for creating forms: HTML+CSS! Students know 
> how to do it. Widgets add too much structure and will never be as 
> flexible as HTML+CSS. WebHelpers are the best way to go. Pylons has them 
> but they are not well documented and therefore unusable. WebHelpers 
> should also generate javascript code for client-based validation 
> (although this should not be a replacement for server-side validation).

Note in Pylons they use FormEncode, which separates validation from form 
generation, and includes htmlfill, which separates form filling from 
form generation.  So it gives you a lot more flexibility.  (TurboGears 
uses FormEncode too, but Django chose note to.)

I think WebHelpers Javascript stuff is a horrible crutch that you 
shouldn't use in an educational setting.  If you want to use a 
markup-based templating language they'll also work fairly poorly.  I 
might be inclined to use jQuery in an educational setting, as it 
presents a nice way of thinking about dynamic pages -- maybe a bit too 
magic, but I think it's one of the relatively more benign kinds of 
Javascript magic.

One of the things that a student won't get is the experience of working 
in a diverse team that might include someone more focused on UI.  I 
suppose this is inevitable, but it's in that situation when form 
generation really falls down.  So they are probably less likely to 
appreciate the problems with form generation in a classroom setting.

This is my own longer opinion on form libraries: 
http://blog.ianbicking.org/on-form-libraries.html

Ben noted to me that the WebHelpers docs are fairly complete (though 
maybe not easy to find): 
http://pylonshq.com/docs/module-webhelpers.rails.html

> Debugging
> 
> Pylons seems to be better than Django and Django is better than 
> Turbogears (CherryPy).

Thanks (I wrote the Pylons one).  The other people *could* use the same 
one as Pylons, but they choose not to.  Well, TG will with 2.0 of course 
(since it's built on Pylons), but they actually were entirely able to 
use it with 1.x.

> Anyway, there should not be a debug ON/OFF setting. There should be a 
> standard error page that allows login as administrator. If administrator 
> is logged in he/she can see the debug information. If a user gets an 
> error page, the error should be logged and the administrator should be 
> contacted.

The Pylons interactive debugger is quite inappropriate for any 
production setting -- everytime there's an exception it saves all the 
stack frames in case you want to further inspect them.

We have talked about some kind of backdoor to view the stuff immediately 
even if debug is off, but never got around to it.  It shouldn't be part 
of the normal authentication system, as it should be something that 
works when other things are broken.  And it should work when you are 
logged in as any user for testing.  So it really would have to be 
another parallel authentication system.  This has been discussed more as 
a means of further restricting debug information than further showing it 
off.  E.g., force any non-localhost user to always be authenticated to 
see a traceback.

Pylons includes a setting to email errors.  They don't include the value 
of locals, but really they should.  I should fix that sometime.

> Django Generic Views, Turbogears Identity, etc.:
> 
> Django generic views are useful and so are Turbogears identity and 
> registration but, these are optional features. They should be 
> implemented as a set of advanced API to be used inside the controller. 
> Otherwise there is too much magic going on.
> 
> General design issues:
> 
> There should be a single configuration file for the database (that 
> defaults to SQLlite) and for email settings, like in TurboGears.
> Sessions should always be on and should always be file based. 
> Page caching a la Django is a good idea and should be available as an 
> optional feature via decorators.
> There should be a small set of core API accessible via a single module. 
> Django, for example, has too many modules and remembering which contains 
> what is a major task.

I've actually encouraged Pylons to create a package in an application like:

   from pylons import request, response, ...

And then controllers would only import from within the application's 
package, making it easier to override things later.  But I think people 
thought this was a little too weird.  Pylons does this a bit with the 
base controller module, which contains all the common imports.

Of course Pylons gets away with a fairly small API through the cloud of 
external packages which are commonly used with Pylons.  But the core is 
still usable and small.

> The bottom line:
> 
> There is too much choice in the world of Pyhon web frameworks (and too 
> many of them are 0.x) and this prevent us from making the case for each 
> one of them against the Java dinosaur frameworks.

I was recently looking at the Python wiki page on web frameworks, and 
was surprised by few viable frameworks there are these days.  There's 
only four serious web frameworks at this point: Django, Pylons, 
TurboGears, and Zope.  There's some small things that are still actively 
developed, like web.py, yaro, and a couple others.

Depending on what you are trying to teach, smaller web frameworks could 
actually be better -- they can bring you a little closer to HTTP, which 
I think is good.  HTTP is easy, but frankly most frameworks make it seem 
mysterious and difficult.  But it depends where you are trying to get 
with the students.  Frameworks are a little more vocational, HTTP a 
little more CSy.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers