Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

TurboGears: Python on Rails?

Posted by Zonk on Mon Oct 10, 2005 03:29 AM
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.'"
+ -
story

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
More
Loading... please wait.
  • by VC (89143) * on Monday October 10 2005, @03:34AM (#13755017) Homepage
    How do the python crowd expect to get taken seriously when implementing a wiki takes an whopping 125% as long in python as in ruby!!!!!!????

    (oh wait, they did ajax as well.. ;-)
  • no sql? (Score:3, Insightful)

    by ambilio (798801) on Monday October 10 2005, @03:35AM (#13755020)
    ...not a single SQL query in sight...

    Why is this an advantage?

    • Re:no sql? (Score:5, Informative)

      by quigonn (80360) on Monday October 10 2005, @04:01AM (#13755074) Homepage
      It shows a high level of abstraction when you access the DB by simply loading/persisting objects instead of having to handle queries, result sets, records and all the other low-level stuff. And abstraction (in this case) is good, as it helps the developer concentrate on the relevant parts of the program.
      • Re:no sql? (Score:3, Insightful)

        by holle2 (85109)
        It shows a high level of abstraction when you access the DB by simply loading/persisting objects [...]

        Last time we used an object-to-sql mapper was quite some time ago, so my info might be outdated:

        We attempted to create objects (in Python) to store a lot of attributes ( > 30 ). The design explicitly asked for a "flat" database.
        All this happened inside Zope [zope.org]/Plone [plone.org], so we tried out the Archetypes [plone.org], which come with a hand attributes (or better PropertySheet) to SQL mapper. But the code was that ugly, it crea
          • In other words, I want a single layer of cleverness: My domain model. Object-orientation is all about encapsulating clever. Letting it sieve half ways through to the database is a terrible violation of those fine intentions. And I want no part of it.
            This works fine if you only have one program accessing the database but is terrible if you have multiple clients for example. Even worse if you have real "enterprise" environment with legacy apps and such.
    • SQLObject rocks! (Score:5, Informative)

      by SimHacker (180785) * on Monday October 10 2005, @04:09AM (#13755093) Homepage Journal

      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

      • Re:SQLObject rocks! (Score:3, Informative)

        by Osty (16825)

        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.

        There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes (I don't care how well you think you're filtering your input, chances are you missed something, especially if you're trying to do so in a DBMS-agnostic way). While an abstraction

        • Re:SQLObject rocks! (Score:5, Informative)

          by Trejkaz (615352) on Monday October 10 2005, @06:15AM (#13755409) Homepage

          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.

          • In this case, stored procedures shelter you from SQL injection attacks

            I'm not sure that they do. In fact, I'd go so far as to say that this doesn't make much sense at all. Not that its hard to protect against injection attacks, though.

            Let's say you have a stored procedure called "getnumber" that takes two args.
            Your goal is that this procedure is going to protect you from injection attacks; that you can put two untrusted args into it and you won't have to worry about someone using the procedure to do some
        • by njyoder (164804)
          if it's mixing in dynamic SQL queries there's a good chance it also has SQL injection holes.

          I'll take that "if" to mean you haven't read the documentation and didn't actually watch the video. Stop frothing at the mouth about SQL injection holes. If you had bothered to watch the fucking video (which you didn't), you'd notice it has specific mechanisms to deal with them.

          Also, its main purpose isn't to "catch bugs", it's to make things easier on the programmer. Abstraction toolkits like this are good. God
          • by moro_666 (414422)


            stored procedures and triggers *are* code - its a hack to follow the "do it all in the database" mentality.

            no kidding, they are indeed code, but this code mostly is on the other side of the database pipe/socket/stream/ which is very important. for example if you update 500 000 records then a database side trigger is affordable ... but any hack in sqlobject or is just awfully slow and inefficient.

            dont get me wrong here, i like the sql to object and vica versa mappings, the idea is cool ... but it al

    • Re:no sql? (Score:5, Informative)

      by wootest (694923) on Monday October 10 2005, @04:31AM (#13755151)

      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.

    • Re:no sql? (Score:3, Insightful)

      Why is this an advantage?

      It makes it easier for the programmer.

      However, I really wrote this to say what it is not an advantage. I have two words for you: Outer Joins.

      First of all, an Outer Join (of which LEFT JOIN is the most common) is used to get information from two tables, whether or not the information in one table has matching information in the other table. A real world example would be a list of customers and the number of orders they've placed with your business. With a normal (inner) join

    • Re:no sql? (Score:5, Informative)

      by mixmasterjake (745969) on Monday October 10 2005, @05:25AM (#13755281)
      Persistance layers are cool for a lot of reasons. Though, it definitely takes some getting used to for those of us who have developed a lot of SQL driven applications.

      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.
      • Re:no sql? (Score:3, Informative)

        by jrcamp (150032)

        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?

        If there is something you need to specifically query by hand in SQL you just use find_by_sql in Rails. I'm not sure how this is configuring and tricking it?

      • Question (Score:3, Interesting)

        by g2devi (898503)
        > 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?

        That raises a question about these persistence layers. Most of the tables we create use an "always insert, never update or delete" model so we can keep track of who made the chan
  • My Experience (Score:3, Informative)

    by HogynCymraeg (624823) on Monday October 10 2005, @03:35AM (#13755024)
    I've used Python/SQLObject/CherryPy on a project before. It's very quick to code something useful. SQLObject will change the way you think about how you integrate DBs to web applications. All in all, it's well worth checking out.
  • by barcodez (580516) on Monday October 10 2005, @03:42AM (#13755040)
    as natural as writing a function.

    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)

    by The OPTiCIAN (8190) on Monday October 10 2005, @04:07AM (#13755090) Homepage
    What software do people use for making these neat videos? (I realise this is bordering on off-topic :) )
  • OpenDoc Cookbook (Score:4, Insightful)

    by Graymalkin (13732) * on Monday October 10 2005, @04:20AM (#13755120) Homepage
    I'm definitely not an expert in Python, in fact I've only ever given it a cursory look. However that tutorial was damn impressive. Obviously he had some prior knowlege of Python and using TurboGears but it is really not all that difficult to build something like a Wiki using that framework. As far as web work I've slowly become disenchanted with PHP. It's a good language to be sure but it's simplicity is short-lived. As you want to do more complex things you end up having to work around PHP more than you get to benefit from it. A large web project in PHP ends up structured like a project of similar size in Perl or Python. Between TurboGears on Python and Ruby on Rails it looks like I have some reading to do.
    • Re:OpenDoc Cookbook (Score:3, Interesting)

      by Bogtha (906264)

      As far as web work I've slowly become disenchanted with PHP. It's a good language to be sure but it's simplicity is short-lived. As you want to do more complex things you end up having to work around PHP more than you get to benefit from it.

      That's exactly what I found. I was already familiar with Python in non-web application domains, so I started looking around for decent web application platforms for Python. I settled on mod_python, but the templating was awful, and none of the alternatives seemed

  • Tried it, too bitty (Score:3, Informative)

    by Boffy (881935) <[moc.liamg] [ta] [rehswob.luap]> on Monday October 10 2005, @04:32AM (#13755154)
    Tried TurboGears, but the fact that it's a glue was way too appparent. I then moved on to trying Django [djangoproject.com] and fell in love. All the stuff TurboGears can do Django can too, but natively.
    • by aleph (14733)
      Still downloading the movie from TurboGears (tried streaming, but well.. That wasn't happening too well :)), but I have been playing with Django a bit the past few days.

      It does look kind of cool, the admin interface is good for _simple_ objects, but seems to start to fall down when you want to construct interesting relationships between the objects, and I haven't started to look into doing custom (or using generic) create/update templates yet.

      That being said I'm still suffering a bit of paradigm lag since i
  • Small Wikis (Score:4, Interesting)

    by xihr (556141) on Monday October 10 2005, @04:44AM (#13755183) Homepage
    If you're up for small Wikis, there's always HeyHeyWickie [python.net], a Python Wiki in under 4K lines of code (using EmPy and docutils).
  • Twisted (Score:5, Informative)

    by jcr (53032) <jcr@NOspaM.mac.com> on Monday October 10 2005, @05:33AM (#13755296) Journal
    Also worth checking out: Twisted [twistedmatrix.com]. I haven't had occasion to use it myself, but people I know swear by it.

    -jcr
  • by Greyfox (87712) on Monday October 10 2005, @09:00AM (#13756211) Homepage Journal
    I've tinkered with rails a bit and I think it's a step in the right direction. What I want to know is, why doesn't anyone in the industry make it this easy? All the commercial solutions seem to be going in the opposite direction, constantly adding more XML files and more layers of API to try to cope with HTTP's deficiencies as an application development protocol. Meanwhile a bunch of amateurs with a semi-obscure scripting language manage to upstage all of them. And if I'm not mistaken, you have to do any xml httprequest stuff in the commercial packages by hand, while rails seems to do it all more or less automatically.

    Rails is another example of innovation in the open source community, and will be conveninetly forgotten by the people who say there's no innovation in the open source community.

  • by MrBlic (27241) on Monday October 10 2005, @11:17AM (#13757296) Homepage
    I've been following python web development for a while, and currently have a few sites running with Zope + Zope Page Templates + ZSQL Objects + MySQL and they work great. The only problem is that I want a more lightweight faster server.

    I am all ready to try TurboGears, but I have not been able to get mod_python + apache2 running on my mac mini. Does anyone know of a howto that will make my TurboGears web app start when the mac starts and mix TurboGears with static content? I really want to follow this example http://www.jamwt.com/mpcp.py [jamwt.com] but don't quite know how to get past some compilation errors with mod_python on my mac (OSX 10.3) and convert this to be TurboGears-aware instead of just cherrypy aware.

    The Kid templates are a great alternative / improvement over the Zope Page templates. The pages are cleaner and I don't have to look up how to do tal:defines as often. I would probably not use SQLObject, but instead start with Durus.

    I'm just waiting a few months for it to become even more of a no-brainer for me.

    -Jim
    • by DavidNWelton (142216) on Monday October 10 2005, @04:13AM (#13755103) Homepage
      Ok, so some of these tools are not suitable for running Amazon. But guess what - most people are not running Amazon! A lot of people don't have the development resources that amazon has, either, so what they are really looking for is a sweet spot that lets them get going quickly, and will grow within reason.

      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.
    • Re:Does it scale? (Score:5, Insightful)

      by Scarblac (122480) <slashdot@gerlich.nl> on Monday October 10 2005, @04:28AM (#13755141) Homepage

      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.

    • Re:Does it scale? (Score:3, Insightful)

      by Qbertino (265505)
      Wrong.
      If you're building Amazon or a simular service (million visits/day) everything scales. I don't know the exact budget the Amazon portals had, but buying Guido von Rossum or Larry Wall and ten of their favorite programmers for life would've probalby been less than a month of amazons electricity bill.

      If I were to rebuild Amazon I'd actually consider Python. If the VM doesn't cut it, I'd hire 20 programmers to optimize it. Which, btw, I don't think would be neccesary.

      Another scenario is even more realisti
    • Slashdot itself uses Apache/mod_perl/MySQL, and there's little between mod_perl and mod_python in terms of performance. Slashdot handles 3 million pages per day without any trouble. Does Slashdot not count as a 'large site'?

      The idea that J2EE is the only system that can handle high traffic sites is a myth.
    • Re:Does it scale? (Score:3, Insightful)

      by m50d (797211)
      Google uses python all the time.
    • I was pleasantly surprised that the TurboGears site not only came up, it came up fast. Quite unusual for a new developer framework appearing for the frist time on Slashdot. Especically since 'Python', 'Ruby on Rails' and 'AJAX' were mentioned, I'll bet they got hammered pretty hard in the last few minutes. So at least we can see that the server scales pretty well with the number of users. This could mean nothing more than the site uses a cached home page and we are seeing the value of (something like) S
    • by hexene (68121)
      Although only recently open-sourced, Django has powered real-world sites for several years now. So whilst the project will borrow ideas from other frameworks where it makes sense, it's more of a case of parallel evolution than trying to ape Rails.
      • I was very interested in Django since I love Python. It looked simple enough and I was able to get through the tutorials and thought that Django was my holy grail. But then I tried to adapt it to an existing database system I had. And here is where the project failed for me.

        The problem I have with Django is that it wants to hijack your database. Sure, they make it real nice to start from scratch. You write classes, run some scripts, and next thing you know, its created a database and all the necessary
    • Re:Rails everywhere. (Score:5, Informative)

      by arevos (659374) on Monday October 10 2005, @06:35AM (#13755470) Homepage
      To me it seems like a silly exercise to replicate rails in python or what have you. Ruby is easy to pick up and a nice language to boot. Why bother really? Just learn ruby and get on board.

      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.

      • by TheLink (130905) on Monday October 10 2005, @07:29AM (#13755706) Journal
        Yeah, that's the part that gets me wondering. People keep talking about hiding away the SQL. But if they don't want SQL, then why are they using an SQL RDBMS in the first place?

        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 ;) ), rather than it being neatly stored with 1000 other nonrelated SQL statements (as functions or otherwise).

        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.
        • A necessary evil (Score:3, Insightful)

          by Kaseijin (766041)

          But if they don't want SQL, then why are they using an SQL RDBMS in the first place?

          It's a robust data store that isn't tied to any one application language or object model. Often, SQL per se isn't the problem, but differing dialects are.

          How would you achieve this when you're so abstracted away from the SQL database?

          Use a mapper with the required feature or drop down a level. Abstraction isn't all-or-nothing.

          Those sort of queries are likely to look different on different RDBMSes. You could make a func

    • Re:Rails everywhere. (Score:5, Informative)

      by Ian Bicking (980) <ianb@colCOLAorstudy.com minus caffeine> on Monday October 10 2005, @10:42AM (#13756986) Homepage
      To me it seems like a silly exercise to replicate rails in python or what have you.
      1. TurboGears is not a Rails clone.
      2. Most parts of TurboGears existed before Rails: CherryPy [cherrypy.org], SQLObject [sqlobject.org], FormEncode [formencode.org] (and Python of course).
      3. Kid [lesscode.org] is most closely related to Zope Page Templates [zope.org] (from the Python world), not anything from Rails.
      4. MochiKit [mochikit.com] has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype [pythonmac.org].

      Rails has taught us some important lessons, but they aren't really technical lessons:

      1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
      2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
      3. Things like screencasts are nice.

      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.

      • by archeopterix (594938) * on Monday October 10 2005, @05:47AM (#13755337) Journal
        Because, like it or not, functional programming has been trying to hit the mainstream for decades without result because functional programming is not as easy and straightforward as imperative programming.
        Ruby is no more functional than Python, even by the most twisted definition of 'functional'. Yup, it uses closures (aka blocks) and that is how far it goes towards functional. For a language to be functional it is essential to restrict side effects (haskell with monads, ocaml with 'mutable'), or at least have some good support for no-side-effects programming: currying, higher-order functions, the "let x = expr1 in expr2" (aka non-destructive assignment) construct and so on. Both Python and Ruby make routine use of destructive assignment, which is the epithome of side effects.
          • Ruby is far from perfect and declaring that we should drop all development in other languages and immediately switch to it is just plain fucking stupid and lacking in any pragmatism whatsoever.

            Perhaps he's not saying Ruby should become a new standard, but that people like you should open your mind just a little, tiny bit, open the door and walk outside - and try a new language for a few hours sometime.

            People like you like to get stuck in a rut and cling to what you know, forsaking everything else. For year
    • You're comparing apples to tacos here. The SQLObject example contains the definition of the table, so that it can be automatically created if it does not already exist, where the ActiveRecord example depends on the existence of the table in the database.

      As for the page example, clearly you have no idea what you're talking about. It says:

      1. Expose an "index" URL as this method with the "wiki20/templates/page.html" template
      2. Look up the content of the page in the database
      3. Use docutils to parse the conten