Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

TurboGears: Python on Rails? 279

Posted by Zonk 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.'"
This discussion has been archived. No new comments can be posted.

TurboGears: Python on Rails? More

TurboGears: Python on Rails?

Comments Filter:

  • 20 mins vs 15 mins!! (Score:3, Funny)

    by VC ( 89143 ) * on Monday October 10, 2005 @04:34AM (#13755017)
    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 @04: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 @05: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.

      • It shows a high level of abstraction when you access the DB by simply loading/persisting objects

        An idea that is at least 15 years old, and has never worked very well either. The problem is most relational database schemas (structure, types) do not map cleanly C++ or Java to objects. From what I've seen in corporate applications the design of database and software are typically done by separate teams with different modelling skills and design priorities. As a software developer I want speed and simplicit

        • David Heinemeier Hansson (one of the RoR progenitors and its most recognizable evangelist) recently addressed this dichotomy [loudthinking.com] on his blog.

          Active Record is opinionated software, just like the rest of Rails... And the opinion goes as follows: I don't want my database to be clever!

          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 wa

          • 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.

      • 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

    • SQLObject rocks! (Score:5, Informative)

      by SimHacker ( 180785 ) * on Monday October 10, 2005 @05: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

      • I haven't used much of Ruby on Rails, or Ruby in particular, but doesn't ActiveRecord do all this stuff for you?

        • ActiveRecord basically autogenerates methods to link classes together based somewhat on the data found in the SQL database.

          What people are talking about here is the exact opposite... generating the SQL from the code.

          Of course, Ruby also has at least one method to do this already... it just isn't part of Rails. Yet.

          • Of course, Ruby also has at least one method to do this already... it just isn't part of Rails. Yet.

            Ruby already has Og/Nitro [rubyforge.org], which drives the SQL from the code. Developers can focus on thinking in terms of their object model and object relationships, and let Og, the ORM part, handle the database work.

            Many developers find this way of working far more natural than spreading their object definitions over multiple locations (SQL definitions and Ruby code).

            Good to hear, though, that Rails continues to pick

            • Ruby has Migrations, which allows you to create database tables from pure Ruby code.

              I'ts what I use. So I never have to manually create any database fields or tables.

      • Re:SQLObject rocks! (Score:2, Interesting)

        by ambilio ( 798801 )
        Sounds like an Object-Relational Mapper. You can find these for just about any platform out there: Ruby - ActiveRecord, Java - Hibernate (and *many* more), PHP - Propel. Explicit SQL is also optional with these.

      • 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 @07: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
            • You seem to forget one basic thing. Arguments in Stored procedures are typed. And types can have a hell lot of restrictions, which being one of the major points of a database.

              And you seem to forget another basic thing. Even if you too the unrestricted type string as the parameter type, simply using stored procedures pretects you from all SQL injection. Stored procedures are compiled. All the statements in the procedures need no parsing anympore, they are already executable binary. No matter what you write i
              • Arguments in Stored procedures are typed. And types can have a hell lot of restrictions, which being one of the major points of a database.

                Like that number I used in the injection was typed? It was clearly a number, and the stored procedure would have recognized it as such. Didn't matter, did it?

                No matter what you write in those arguments, at runtime there is no parsing anymore and no ambiguities by cleverly chosen strings matter to the parse anymore...since it is simply not used.

                That only works if you ca
        • There's one issue with database portability, and that's that each database uses different languages for stored procedures. This is getting better in some areas, and some DBs now have a basic procedural language that's mostly compatible, but it's not really good from a DB portability point of view.

          Of course, for the plain SQL procedures that many or most of your stored procedures will be that's no problem at all. Porting your procedural stored procs isn't going to be too bad so long as they're all well docum

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

          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
        • I'm programming "database applications" with python. I'm storing with zodb or simple pickle. Of course, they're not big apps, but that's the point. For small apps, why bother with an SQL engine/server?
          About optimization. If you need to do lots of specific lookups, you can do your own indexes. Have an extra dict that points to a list with the ids for that record. {'kw1':[id1,id2],'kw2':[id3,id1],}. Or better, use ZODB + ZCatalog.
      • 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.

        This [rubyonrails.org] doesn't look at all like database dependent SQL code... SQL queries are an option in Ruby on Rails, but active record tries to make you avoid them as much as possible.
      • 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.

        Hmm, SQLObject sounds interesting, but I'm confused.

        All the Ruby demos I've watched made a point of showing that you didn't have to write SQL statements. You wire Activerecord up to a database you've made (the "wiring" can be as simple as specifying the server/db/table - and it infers the rest so you can build what

        • Tell me - how and where does one start writing SQL when you're using Ruby's Activerecord (which sounds like a building block for making Ruby objects similar to Python's SQLObject but without writing a single line of SQL)?

          In pretty much every Ruby tutorial I've seen (including Agile Web Development with Rails [pragmaticprogrammer.com] ), the sequence goes: write the SQL, write the class, let Rails infer what isn't worth specifying.

          More specifically: Rails makes a vast number of assumptions about the manner in which you store your

      • 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. ...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.

        I'm going to assume you haven't actually

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

      by wootest ( 694923 ) on Monday October 10, 2005 @05: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)

      by VGPowerlord ( 621254 )
      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 @06: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.
      • found this on http://www.eod.com/devil/ [eod.com]

        Ruby on Rails, proper noun: The VisualBasic of the
        Web, making the first ninety percent of what you need to do easy by
        making the last ten percent impossible.

      • 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

    • Re:no sql? (Score:2, Funny)

      by ammoQ ( 454616 )
      Because SQL with its subqueries, joins, unions, aggregate function etc. is way to powerfull. It doesn't match the OO paradigm, therefore it must be bad.
      It's obviously much more efficient to retrieve a million records, create a million objects and count those objects with a certain property than runnig a simple "select count(*) from x where y=z" against the database.
      If this assumption does not hold, you should build caching, optimizations etc. into the persistence framework, until you have a database sitting
    • SQL its self isn't the problem. SQL in apps, however:

      - is an absolute PITA to assemble dynamically, involving lots of icky string mangling;
      - is often rather ugly; and
      - is not trivial to do safely - it's way too easy to expose SQL injection holes.

  • My Experience (Score:3, Informative)

    by HogynCymraeg ( 624823 ) on Monday October 10, 2005 @04: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.

  • What is natural about that? (Score:3, Interesting)

    by barcodez ( 580516 ) on Monday October 10, 2005 @04: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 @05:07AM (#13755090)
    What software do people use for making these neat videos? (I realise this is bordering on off-topic :) )

  • torrent (just in case) (Score:2, Informative)

    by Anonymous Coward
    torrent [mujumbo.com]

  • OpenDoc Cookbook (Score:4, Insightful)

    by Graymalkin ( 13732 ) * on Monday October 10, 2005 @05:20AM (#13755120)
    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

  • Anybody?

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

    by Boffy ( 881935 ) <paul.bowsher@gmail. c o m> on Monday October 10, 2005 @05: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.

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

      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 @05: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).
  • Interesting. It's good to see a number of people taking on the project of providing RAD tools with database access.

    I have a competing project: http://entropy.homelinux.org/axis_not_evil [homelinux.org]

    It's a collection of Perl modules:

    - Gtk2::Ex::DBI ( forms )
    - Gtk2::Ex::Datasheet ( datasheets )
    - PDF::ReportWriter ( reports )

    It's all open-source, cross-platform goodness. It of course uses Gtk2 as the widget toolkit ( which is now a push-over to install on Windows thanks to a number of people providing single-cli
    • Interesting project. We use Access extensively at my office, and I am the main "programmer", but that's really only about 1/3rd of my job. There are 3 of us in the IT staff, and we handle everything from remote access to printer issues to networking to phone system wiring to appliation development, so there is never a shortage of issues to be dealt with. We will be tied to the Windows platform for a very long time due to government reporting requirements, and software doesn't exist for other platforms th

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Monday October 10, 2005 @06:33AM (#13755296)
    Comment removed based on user account deletion
  • So, do you think he actually wrote a regular expression off the top of his head, or do you think he had it memorized or written down somewhere? I didn't think any human being could write regular expressions that quickly. =P

  • Visual Programming (Score:2, Interesting)

    by youval ( 921754 )
    My project, Tersus, uses an alternative approache to web application development. Take a look at http://www.tersus.org/ [tersus.org]

  • Amateurs Versus The Industry (Score:3)

    by Greyfox ( 87712 ) on Monday October 10, 2005 @10: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.

    • Why do you think the Rails developers are amateurs?

      Anyways, the answer is probably something along the lines of "more complexity = more enterprisey = more money". Corporate execs are big fans of "enterprise" software, cuz enterprise software is adventureous and complex and hard and stuff.
  • So... do I have to run it on the "built in" webserver or will it run under mod_python? Doesn't appear to do so.

  • I'm ready... but I can't get it working (Score:3, Interesting)

    by MrBlic ( 27241 ) on Monday October 10, 2005 @12:17PM (#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

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close