In the following the bold terms match the components discussed in my last article.
Routes is a Python implementation of the Ruby On Rails URL-to-object mapper. It is in use in several of the top products. The blog from the developer, Groovie, is a great source of information and informed opinion. In particular this comparison article is relevent here.
WebStack is a web server connection that I mention here since it supports no less than BaseHTTPRequestHandler, CGI, Jython/Java Servlet API, mod_python, Twisted, Webware and Zope 2.
SQLObject is the most popular object-relational mapper, used by Subway, TurboGears, and Pylons. Despite this, it is not preferred by those who have worked on large-scale systems. This seems to be one of those cases where an easy-to-use product at the entry-level provides barriers to use later one. You know, like PHP.
PyDO and especially SQLAlchemy get the nod instead. This last product supports SQLite, Postgres, MySQL, and Oracle, a standard list. It provides for thread-safe and pooled connections. Notable is the design decision to keep the actual database mapping and the class design separate. In particular, objects can map to joins, subqueries, and unions, not just simple tables. I think I need to shrug off my aversion to ORMs and try it.
Cheetah is likely the most popular Python template language. It provides a host of markup, an approach which I have already explained I do not like. The argument can be made that just because the markup is there doesn't mean you have to use it, but I prefer a tool that encourages best practice. That is one reason I am fond of Python itself.
The new, ahem, Kid on the block is similar, perhaps, though simpler. That's a good thing. It does not allow you to generate output within a code block, a restriction which discourages arbitrarily mixing code and markup. Already I like the look of this fresh-faced youngster!
Kid is not only based on XML, it guarantees well-formed XML output given a valid template. Output is compiled to Python byte-code so it can be used like any other Python module. Used in TurboGears, Kid would also be my choice, if I didn't have an enormous hunger to implement the Wasp templating system one more time. (That is a joke. I think.)
I've got my own session and cookie modules but I'm sure the counterparts that come with most WAFs are at least as good. The same goes for other components I don't specifically mention here.
FormEncode has rapidly become the default way of handling forms. It's in use by Subway, TurboGears, and Pylons. Who am I to argue? Oh, yeah, well, I might argue, except I hate my own way of managing this mess of HTML.
For installation tasks we have a brand new approach, courtesy of Paste Deploy. This module allows the configuration of WSGI applications using the soon-to-be ubiquitous Egg installation format. All it takes is a simple configuration file and your WAF can go from installation package to functioning web server in two commands. It's difficult to comprehend from the developer's terse site, but an explanation by Groovie helps, in case my own attempt was not good enough for you.
Did you notice I threw a new acronym at you? WSGI is a developing Python standard that unpacks to Web Server Gateway Interface. The proposal intends to add a level of conformity to all the WAFs wafting about. It works at about the same level as the DBAPI, which could be considered not strict enough. But it's a decent step in the right direction and will hopefully become "law". There's a bit of a technical intro at... wait for it... yes, you're right, it's at Groovie's site. Sure hope he appreciates all the new traffic I'm sending his way.
Now that we have chosen best-of-breed components we can take a stab at the major frameworks. That's the task ahead of us in Part 4, the conclusion of this little series, which will be coming your way in no time at all.
† What are you doing reading a footnote that has no reason for existence?
RELATED POSTS
No comments:
Post a Comment