Slashdot Mirror
Web Development with TurboGears and Python
rdelon writes "TurboGears was previously mentioned here as "Python on Rails". It has since made tremendous progress and is now a popular Python web MVC framework (along with Django). IBM developerWorks just published a great article about TurboGears and a book is on the way. Unlike Rails and Django, TurboGears is made up of several pre-existing subprojects. One of the great features of TurboGears is the 'toolbox,' which allows you to configure and check various aspects of your application and database in a browser."
Excellent! For those who (like me) can't decide which Python web framework to pick and learn, this is a two-part series on both Django and TurboGears from IBM, one can learn the basics of each one and decide.
python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
that's awesome
Both TurboGears and Django are excellent. Furthermore, each has strengths for different kinds of projects, with TurboGears at its best for web applications and Django for big, industrial strength web content sites. Twisted and Zope are great too, but for most developers, Django or TurboGears is going to suit them best. Both are under rapid, well coordinated development and are proven solutions that will scale well over time. TurboGears' best of breed component approach is, in my opinion, a winning strategy, especially in the Python community since Python is blessed with so many great projects (some people think too many projects), giving a plethora of high quality, well maintained and best of breed components for TurboGears to choose amongst. There are multiple good tutorials on both frameworks here, http://www.awaretek.com/plf.html , as well as related podcast material about TurboGears and related Python material.
The article was interesting, but I disagree with their claim that, "TurboGears is more community-driven than Django because it was built with pre-existing, open source components." From everything I've seen, Django has a strong community behind it. I don't think I've ever seen an open-source project whose maintainer is as helpful to users and contributors than Adrian Holovaty is. He's extremely respectful and responds quickly to bug reports and suggestions. In addition to its clean, unified feel, the community is one of the main reasons I was attracted to Django.
In other words, if you have any other way to work with data in a database, you don't need "Toolbox".
"A side benefit of the TurboGears framework is that it is a megaproject with a megacommunity. TG has become a powerful, central force, driving interest and involvement into the core components that make up TurboGears. It is the tide that raises all ships."
Sounds like the author has a hard** for TurboGears. Comparison shoppers beware...
Just the other day in the Ruby for Rails review thread, someone was saying:
Soon to be obsoleted by Airways for Python
Guido Van Rossum heard exclaiming that he was developing with SNAKES on a PLANE
FYI Guido van Rossum prefers Django (from his blog).
And people that use web frameworks in Python will probably be interested in WSGI 1.0 (the Python Web Server Gateway Interface) that will be added to the standard library in Python 2.5: it will probably be supported by all the major Python web frameworks.
There's a hidden treasure in Python 3.x: __prepare__()
I've been using Python for scripting glue at work for about a year now, but I recently had a small side project come up that was better served having a web interface to a database. Like everyone else, I downloaded/installed Rails. I had given Django a peek, but given that this is a side project, I didn't have the time nor energy to keep up with a rapidly developing platform. Django's website cautions about framework upgrades until 1.0 when the base API will be locked, so I went with Rails. Other than learning yet-another-scripting-language, using Rails (without even really understanding it) hasn't been much of an issue.
Choice is both good and bad, in my opinion. It sounds like TurboGears and Django specialize in different things, when it would be preferred for occasional users like myself that there were one clear winner that was evangelized and well supported for all applications. Perhaps out of this competition this will happen for both platforms -- this is where choice is good!
It looks impressive, but the template system seems a lot more complicated do deal with than ERb in Ruby on Rails.
I watched the 20 minute wiki video and the biggest thing I noticed was that the AJAX page list took a LOT more code than the same functionality would in RoR. Other than that it looks nice, and it's good that RoR has some real competition.
Sort of in-between the two is [yet] another Python project, Pylons. Borrows from Rails most heavily in controller/routing/helper(prototype/scriptaculous) areas, and it's extremely flexible, supports whatever DB layer you want, template layer, and URL dispatch. It heavily uses WSGI but you can ignore that fact if you don't need or want to bother with it to start. It runs on top of Myghty which is a python port of Mason(perl) and runs some heavy sites like bittorrent.com.
Good job on the PHB marketdroid post. Always nice to be able to play buzzword bingo while reading slashdot.
One excellent Python project that doesn't get enough publicity is my favorite ORM tool by Michael Bayer - SqlAlchemy http://sqlalchemy.org/. Think Rail's ActiveRecord with Hibernate power.
There was some talk of integrating it with TurboGears to create some competition for SqlObject. Not sure where this stands currently.
From a quick glance it wasnt apparent how this is licensed.
---- Booth was a patriot ----
Darn.
---- Booth was a patriot ----
> Unlike Rails and Django, TurboGears is made up of several pre-existing subprojects.
You mean like Rake, ActiveSupport, ActiveRecord, ActionPack, ActionMailer, and ActionWebService?
$ gem dependency rails
Gem rails-1.1.4
rake (>= 0.7.1)
activesupport (= 1.3.1)
activerecord (= 1.14.3)
actionpack (= 1.12.3)
actionmailer (= 1.2.3)
actionwebservice (= 1.1.4)
In an attempt to combine all the best of web frameworks into one event, I interviewed Adrian Holovaty of Django on the Ruby on Rails podcast: Adrian Holovaty on the Rails Podcast He's a smart programmer and it helps to see the different philosophies behind the way popular web frameworks were constructed.
How did you get from Guido's statement that "Django's gaining steam" to your statement that "Guido prefers Django"? Prefers it over what? Is that from your personal communication with him, something he said in public somewhere else, or are you reading something into that blog posting that I can't see? He doesn't mention anything about TurboGears or his preference in web frameworks, he simply states that Django is gaining steam in a big way. You're jumping to conclusions if you think that blog posting implies that he preferrs one web framework over another.
I'd be interested to know what Guido thinks of Zope, since he worked for Zope corporation in the past. And what he thinks of Zope Page Templates, since he worked on that code.
-Don
Take a look and feel free: http://www.PieMenu.com
"""= 146149
I took a brief look at Django, and while I like their website (pretty and easily navigable and chockfull of useful information), I'm not keen on the particular tools they provide (it doesn't help that they begin every example with "from mumble.something import *").
""" - http://www.artima.com/weblogs/viewpost.jsp?thread
doesn't sound like he likes it much either...
While the article mentions Catwalk (toolbox app to set up initial database objects) it does not mention some of the very nice new features in Turbogears 0.9a6 (supposed to be real close to 1.0 now):
- Identity Management
- Widgets / Forms
- Internationalization support
- Optional support for SQLAlchemy instead of SQLObject
The newly added toolbox offers the following tools:The turbogears quickstart can now create a set of customizable standard classes to handle standard authentication and authorization. A User Group Permission model coming with easy-to-use identity decorators for exposed methods. ( Identity Management Documentation )
A system to create reusable Form Widgets (with optional scripting / styles) and to use them in forms -- including support for error display and data retention.
Database tool meant to ease the creation of initial data. Sure, you can always just use plain SQL to set them up, but managing relations between tables can be slow and bothersome, especially for N-to-M relations (RelatedJoins in SQLObject terms)
Toolbox tool helping to design your models. (Showing diagrams etc)
Allows browsing through all available Widgets with working examples, example code and configuration help
Tool to collect internationalized strings and create new language catalogs
I started playing around with Turbogears some time ago and like it very much. The documentation is a bit thin at times, but the source code is easy to read and accessible (using ipython to interactively explore things also helped a lot.) I implemented my blog in python and had only minor problems. And the code size also turned out to be relatively small.. For the metrics fetishists:
Blog with tagging, User handling (subscription, email confirmation etc), Image handling (upload, admin, thumbnails), atom feeds (general + tag based feeds) plus some minor things:
- python code : 1181 lines, 40762 bytes
- kid templates : 610 lines, 21200 bytes
plus some style sheets, javascript code and images..while (!asleep()) sheep++
One of the most appealing aspects of Turbogears imho is the work to supersede the db layer, currently SQLObject, with SQLAlchemy. The problem with most web frameworks is that their ORM db layers treat the db as just an object store, rather than as a relational database. This works for relatively simple 37signals-esque websites, but not for more complicated sites that require a relational algebra engine, for example any relativley complicated web-based BI application or booking engine. For example, one of the fundamental features of the relational model is that the result of any query against a table or number of tables is another table. In that respect, SQLAlchemy lets you map classes not just to tables, but also to joins, unions, and subqueries (which are themselves tables). Turbogears is the only framework I know of so far that is attempting to integrate SQLAlchemy. They're still in the relatively early stages of the integration, it seems, but are working to provide an easy migration from SQLObject to SQLAlchemy when the latter is ready, making TurboGears top on my list of webframeworks to consider/recommend for new projects.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
Guide van Rossum writes :
So no, he doesn't prefer Django. It's official: he makes no endorsement whatsoever, except for the low level WSGI standard. He's using Django for at least one application, but he encourages people to compare and contrast all web frameworks.
-Don
Take a look and feel free: http://www.PieMenu.com
Indeed. Turbo gears is not a project. The guy took (the best of) four other projects and made a stack. He did not write any code. The developers of the four other projects are supposed to support TG because it uses their project. This is a matter of a political aliance/merger thing.
In its web page it sais: """The TurboGears Project Philosophy is all about building on the work of great open source projects, not replacing or supplanting them.""". But Turbogears is itself replacing the work of Pylons, Subway, Django, Plone and a few other millions of OPEN SOURCE web frameworks written in python. The advantage of TG compared to the others is that TG uses four python projects and has got their support (except from Cheetah who don't kiss ass). But it is supplanting hard work of others with zero code.
And following the classical scum where thei create a mailing list with 1500 fake members and posting messages from very excited users with fake accounts, their are trying to overcome the threshhold, and be in the top 3, and profit.
I've just completed a large project using TurboGears, and I'm quite happy with it, considering how new it is (not even to version 1.0 yet).
The Kid templating system is wonderful and well designed: very Pythonic, XML centric, practical and easy to use. But it's pretty hard to trace and debug problems with templates, and it's not very smart about stripping out unnecessary white space (not a big deal, but the Kid compiler could be smarter about optimization, and inject extra information to make debugging easier).
So many other template systems attempt to fight against Python or XML, and end up with a big mess that tries to reinvent the wheel and ends up with something much worse than the sum of its parts. But Kid is straightforward and honest with Python and XML. You don't need to learn another weird half baked language.
I've done a lot of work with Zope and Plone, and I'm sick and tired of Zope's sloppy DTML, awkward TAL, inexplicable METAL, casterated "secure" python scripts, brittle SQL methods, insane acquisition, unidentified flying object models, and all of Plone's fractal complexity and self perpetuating bureaucracy, so Kid is a refreshing breath of fresh air.
I was already using SQLObject before I started using TurboGears (which was one reason I found it so easy to switch to TurboGears). I like it, and it works well for my current purposes, but I'm interested in learning more about SQLAlchemy, and maybe using it with more complex projects.
The project I just finished has about 12,000 lines of Python code, and it's quite template-heavy: about 300 templates, comprising more than 32,700 lines, almost a megabyte of XML Kid template source code. I consider the kid template content to be the crown jewels of the project, just as important as any of the Python source code, so it's all nicely indented and easy to read and maintain, like Python code. There's no place for sloppy templates, just as there's no place for sloppy code.
The idea that a templating system should't allow you to write any code is just as foolish as the idea that the templating system should invent a totally new programming language. I'm already quite happy with XML and Python, and have invested a lot in learning them and their associated tools, and I don't need to be protected from myself. Python and XML are both well designed and universally supported, so I have no need for a templating system that doesn't let me use the full power of Python, along with with the pure standard syntax of XML.
-Don
Take a look and feel free: http://www.PieMenu.com
I don't do web stuff for a living but I recently had to do a little bit.
I looked at and discarded both django* and turbogears**. Furthermore, I'd screwed around with Zope before and it's all expenses paid trip to the land of most surprise isn't my thing.
I guess I'm fuckall lame because I bailed and wrote some small python cgis with sqlite and, after downloading and comparing numerous python template engines, a small, stupendously-elegant, and boringly-named library written by Terrence Parr (www.stringtemplate.org).
With all that said, if Django and Turbogears were my only choices. I'd grudgingly choose django for its consistency. While django at least feels like a product, turbogears is more like your puke after lunch at an Ethiopian restaurant.
*I had install problems, the tutorial was broken, and it was just damn unintuitive.
**all the consistency and cleanliness of perl (installation dependencies dump turds all over your system) with the conceptual elegance of a bash script running on cygwin.
That complaint was leveled before a major refactoring to "remove the magic" from Djago was merged with the codebase.