[Chicago] Web Frameworks?

[Brantley Harris]

Man I wish there was a professor teaching this stuff at DePaul when I was there.

One thing about the Django ORM API. It uses __gt syntax for a few
different reasons. First, you have to create a special "magic" object
to interact with the ">=" correctly.  In SQLObject you have the
Table.q, SQLAlchemy uses Table.c.  During the magic removal
discussions this idea was explored, but was found to be more
error-prone and just as crufty, e.g. Object.c.date >= date vs.
date__gte=date.  The __ also opens up other functions that aren't
available as operators: date__between=(start, end),
name__icontains='name', etc.

It's interesting to hear your points of view but many seem to come
down to a difference of perspective: practical vs. academic.  A lot of
my choices are made from the standpoint of practicality, i.e. get it
done as well and fast as possible.  Whereas, inevitably, a lot of your
choices are made from the view of academia, i.e. imagine the best way.
 Now, you have the foresight to envision Python as part of your best
way, which I think is great.  But I hope that you pay close attention
to this dichotomy, because I think you'll see a number of differences.
 (Actually it's a trichotomy, practicality, academia, and microsoft,
but I'm not going to go into that.)

Truly if I could infuse anything into my DePaul experience, it would
be more time spent on practical problem solving.  If I could write the
curriculum, most classes would be centered on specific projects that
stretched these muscles.

On 8/17/07, Massimo Di Pierro <mdipierro at cti.depaul.edu> 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.
>
> Massimo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>
>