Slashdot Log In
TurboGears: Python on Rails?
Posted by
Zonk
on Mon Oct 10, 2005 03:29 AM
from the i-like-choo-choos dept.
from the i-like-choo-choos dept.
gcantallopsr writes "If you liked Ruby on Rails and its 15m intro video (.mov) you will probably like TurboGears and its 20 minute wiki tutorial. (.mov) It shows you the development of a simple wiki in just 20 minutes, and there is a text version of the tutorial. TurboGears uses Python, SQLObject, CherryPy, Kid, MochiKit and some extra pythonic glue to help you to (in their own words) 'Create a database-driven, ready-to-extend application in minutes. All with designer friendly templates, easy AJAX on the browser side and on the server side, not a single SQL query in sight with code that is as natural as writing a function.'"
Related Stories
[+]
Technology: Web Development with TurboGears and Python 43 comments
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
20 mins vs 15 mins!! (Score:3, Funny)
(oh wait, they did ajax as well..
Re:20 mins vs 15 mins!! (Score:3, Funny)
no sql? (Score:3, Insightful)
Why is this an advantage?
Re:no sql? (Score:5, Informative)
Parent
SQLObject rocks! (Score:5, Informative)
One of the nicest features of SQLObject is that it insulates you from the peculiararities of the database's SQL syntax, so you don't need to put any SQL code directly into the Python code (but you can if you need to for efficiency or if you're willing to write non-portable code).
The SQL database abstraction layer is an important feature of SQLObject, that Ruby on Rails doesn't currently support -- you have to write database dependent SQL code mixed in with your Ruby code.
SQLObject lets you write generic SQL queries with normal Pythonic expressions and operators, which are automatically translated into the database dependent SQL syntax by the database driver. So you don't have to change any of your Python code to port it to a different database, and you don't have to mix together two different notations, or quote a bunch of SQL strings in your Python code. It's a much more "pythonic" way of database programming than raw SQL.
The great thing is that it's so convenient and the syntax is so simple, that you can use the interactive Python shell to browse and test out and edit your database. It's trivial enough to type in some Python code on the keyboard that loops over the results of a query, performs some complex logic, and validates and edits a bunch of rows in the database. Much more powerful and easier to use than anything you can do with raw SQL.
-Don
Parent
Re:SQLObject rocks! (Score:5, Informative)
There's a reason why stored procedures are important, and it doesn't have anything to do with perceived performance increases from not having to re-parse the same SQL code every call (that's definitely a benefit, but it's minor). In this case, stored procedures shelter you from SQL injection attacks
Whereas this is true, it's also true that using "?" parameters for any user-entered values can solve the SQL injection problem just as well.
Parent
Re:no sql? (Score:5, Informative)
Other people have answered in-depth, but the short answer is:
a) You do not need to worry about which vendor's dialect of SQL syntax you're using - provided you know how to create and populate the tables in any database system, you can switch at the drop of a hat if you need or want to.
b) Provided the layers are stable, it protects you from SQL query injections. The abstraction layer does the escaping for you.
c) Abstracted queries makes queries 'just another function/method call', and you get ordinary data structures back. This in combination with a) and b) and a competent framework (Rails, Django, TurboGears, Cake, Trax, WebObjects) makes coding much quicker as you don't have to keep the semantics of SQL and your database in mind - just the model itself.
There are *many* nuances to this, but the above three are some of the most pertinent ones. Peruse the other comments if you want to get in-depth.
Parent
Re:no sql? (Score:5, Informative)
Don't let anyone fool you into thinking that a persistance layer will be less development work for you - I have found this to be untrue. I can use automated tools to get myself 80% of the way there. For anything substantial, though, it always seem to wind up being more work as I figure out how to configure & trick the persistance layer into giving me my data in the most efficient way. This can be frustrating when you know how to accomplish the same thing in 5 seconds using plain SQL. Maybe it's just me?
But, if you do manage to get over the hump, the benefit is that your business logic layer is very clean with no DB code whatsoever. If you use it properly, you can get 100% separation between these layers.
If you're using a strongly typed language, you get the added bonus of compile-time checks for certain illegal assigment errors. You don't have to fumble around with things like converting dates into SQL. You don't have to check for SQL injection. Lots of other little things.
Parent
Re:There are too many ways to answer that (Score:3)
As opposed to...?
As opposed to using transparent persisting of objects, e.g. with ZODB [dion.ne.jp] (which doesn't use SQL at all) or other persistance frameworks (which translate everything to SQL behind the scenes).
My Experience (Score:3, Informative)
What is natural about that? (Score:3, Interesting)
So what is so natural about writing a function? I would have though if it is based on Python it would be OO with behavioral methods rather than procedural function calls.
Why is everyone clambering to find the 'next' language for programming in the small when quite clearly a good language for programming in the large is what is required - at least for enterprise applications (I'm going to include wikis in that for now).
Video software (Score:4, Insightful)
Re:Video software (Score:4, Informative)
http://www.ambrosiasw.com/utilities/snapzprox/ [ambrosiasw.com]
Parent
Re:Video software (Score:5, Informative)
What software do people use for making these neat videos?
vnc2swf [unixuser.org]
And to bring us (nearly) back on topic, the latest version is written in python!
Parent
OpenDoc Cookbook (Score:4, Insightful)
Small Wikis (Score:4, Interesting)
Twisted (Score:5, Informative)
-jcr
Scaling up, and scaling down (Score:5, Insightful)
I'm still mulling it over and working on it, but I talk some about "scaling down" in this article:
http://dedasys.com/articles/scalable_systems.html [dedasys.com]
You're right of course that you don't want stuff that falls over the first time traffic spikes a bit, but you absolutely must have something that you can use to produce a functional product. You can have the fanciest, most scalable system out there, but if you spend two months twiddling with XML config files, things just aren't going to work out.
Parent
Re:Does it scale? (Score:5, Insightful)
if you want to do something for your professional career, don't waste your time with those kind of frameworks.
If you want to do something for your professional career, get familiar with as varied a collection of tools as you can. Know the pros and cons of each. Actually test their performance, make toy projects, steal ideas and patterns. Be opinionated, but prepared to honestly choose the best tool for the job you're given, and to explain why it is the best, to suits and to techies. A few hours getting to know something new is never wasted.
Parent
Re:Does it scale? (Score:4, Funny)
A few hours getting to know something new is never wasted.
I once spent a couple of hours looking at VBScript.
I think I came away knowing less about good programming than before, *and* I was out two hours.
Parent
Re:Rails everywhere. (Score:5, Informative)
Whilst Rails is an excellent framework for web applications, I've found that it gets exponentially more difficult to work with when your database structures grow more complex than interconnected lists. I recently designed a double-booked accounts program in Rails, and whilst most of the code was simple to design, I quickly got bogged down in handling the accounts-tree and the double-booking of financial records. Here the documentation ran out, and I was forced to go through the Rails source to discover a solution to my problem, which turned out to be less than optimum.
Secondly, whilst I have done a fair bit of work in Ruby, I can't help but prefer Python. If there's little difference between Rails and, say, Turbogears, Django or Subway, then surely it comes down to personal preference. Python web frameworks appear to take a more piecemeal approach than Rail, which can provide a more flexible solution in certain situations.
Can't say I much like SQLObject's syntax, though; but CherryPy seems rather elegant.
Parent
Yeah, why use SQL halfway? (Score:4, Insightful)
Shouldn't they be using something else then? Otherwise they'll get the drawbacks of using an SQL database but fewer of the advantages. What happens if performance in a particular area is not good enough?
Say you want to store a session in a database and you want it to expire after X seconds of inactivity.
A simplistic method would be to update the session row each time there's activity. But this would cause lots of writes which would be slower in most proper databases (those that actually write to disk for writes). An alternative would be the databases equivalent of "update sessiontable set lastactive=now() where sessionid='$sessionid' and lastactive+'1 second' <= now()".
With this, you could have thousands of hits per second but only 1 forced write to disk per second due to that query.
How would you achieve this when you're so abstracted away from the SQL database? And it might look strange to others when you try to do the same thing N layers above the database. I'm sure there are better examples.
Those sort of queries are likely to look different on different RDBMSes. You could make a function that looks the same, but someone still is going to have to write the SQL for portability (and sometimes bad luck, it's not possible - DB doesn't support functions or that sort of function). Also, if only the program's session module does that stuff, then what's so bad about leaving the SQL in there? At least then there'll be some context to understand the SQL (and whether it's wrong or right
Sure it's ugly. But if people want it all so elegant and clean maybe they should write _everything_ in some version of Lisp, and not interface with the rest of the ugly real world.
Parent
Re:Rails everywhere. (Score:5, Informative)
Rails has taught us some important lessons, but they aren't really technical lessons:
After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.
As for Ruby: I think the two languages are largely equivalent [ianbicking.org] in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.
Parent
Ruby functional? Not. (Score:4, Insightful)
Parent
Re:Perl on rails? (Score:4, Informative)
Parent