[Chicago] Web Frameworks?

[Christopher Allan Webber]

Hey Massimo.  Glad to hear from you again.  I remember having a C++
class with you some time back.. was quite good.

Now... on to details...

> And I do not want that when they turn off debug the administrator
> has no way to check whether a user has an error. I am just asking
> for a built-in ticketing number. This should be easy for Django
> since Django already has an excellent administrative interface.

Most frameworks these days ship with something called "error
middleware."  Django has it, Paste (and thus Pylons) has it... but
usually this is set up so that it emails the error (with traceback) to
the administrator (regardless of whether debug is set to True or
False).  I'm not sure what you mean by "ticketing".. are you
suggesting that instead these errors be stored in the database, and
there be a page to view them from the admin page?

In some ways I think that's a neat idea.  On the other hand, one error
that throws a lot of exceptions could lead to a lot of nasty extra
data in the database.  There was an error here at work not too long
ago that was sending about ten error emails a minute to one of the
project managers before I got to it.  Wasn't so hard to delete them
from her inbox once the issue was resolved, but an admin page might be
more of a pain.

As for the documentation issue, it's no secret that Django is doing
much better than Pylons in this regard.  A lot of components in Pylons
currently aren't very nicely documented.  Even when they are, there's
a fundamental problem... where should documentation be placed?  The
whole idea of complete decoupling sounds great in theory, but when it
comes to documentation it creates some serious headaches.  When I want
to look for documentation on paste, I'm often stuck looking in the
pylons wiki, or on the pylons mailing list.  This is even true for
less core components, or components that may be optionally swapped in
or out.  If Pylons was truly decoupled, then the documentation should
be too, rather than messily fragmented the way it is now.  (It's
especially frustrating for me, when I'm working in another framework
built off of many of the same components as Pylons, but I *still* have
to check the Pylons wiki.  Or sometimes I have to go to the Turbogears
community.  Etc, etc.)  I don't mean to complain too much: the Pylons
project is awesome, and I'm glad that it's there.  The documentation
issue is really just one that needs some serious attention... if there
*is* a possible solution to it.