[Chicago] Web Frameworks?

[Ian Bicking]

You didn't mention testing anywhere in here.  Testing!

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.
> 
> 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).
> 
> 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.
> 
> 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).
> 
> Debugging
> 
> Pylons seems to be better than Django and Django is better than 
> Turbogears (CherryPy).
> 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.
> 
> 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.
> 
> 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 have to teach this stuff therefore I can help the Python community to 
> market their products. So far I have only covered Django in my classes 
> because it is the only stable one and I was able to get the United 
> Nations to use it. Nevertheless I am still waiting for the community 
> come up with a real J2EE killer.
> 
> What I encourage you to do:
> 
> 1) Keep in mind that too much choice is bad, not good
> 2) Do not reinvent the wheel
> 3) Keep the API stable, work on improving implementation and documentation 
> 4) Have one person in change of usability and one in charge of security
> 5) Focus on a single framework (I suggest Pylons + Genshi + WebHelpers + 
> Django or Canonical ORM) that works with mod_python, defaults to SQLlite 
> and has sessions on by default. You already have all the pieces... just 
> put package them well.
> 6) Make sure the ORM works with Oracle
> 7) Write API for Generic View, Login/Logout and Registration
> 8) Write documentation...
> 9) Write documentation...
> 10) Write documentation...
> 
> You make this and I guarantee it will be used in a course at DePaul in 
> the winter quarter.
> 

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