Slashdot Mirror
TurboGears: Python on Rails?
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.'"
If you're up for small Wikis, there's always HeyHeyWickie, a Python Wiki in under 4K lines of code (using EmPy and docutils).
> 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 change, when the change was made, and by whom.
You have to code, normalize, index, and select from these tables in a particular way otherwise you'd end up with extremely inefficient code. I just don't see how a persistance layer can handle this.
Another thing, one thing I've learned is that for enterprise applications, data outlives the application and in many cases, it predates the application. In essense, the persistence layer will need to be retrofitted into the application. Top-down GUIs like the ones presented for Rails appear to be of no use. We already know the exact representation of the data so Rails will need to work from the bottom up by default.
As a side note, I don't see why people are so afraid of a little SQL. Sure it takes time to learn how to master efficient SQL coding, but it's well worth it. It's the most efficient way to deal with most data, and because it's a declarative language, it's often more intuitive than the imperative language you're working in. It's also supported by most languages, so it's universal. If you're using a strict model-view-controller paradigm, database access will be restricted to the model and recast into data objects that can be used by the view and controller. If done correctly, you can rewrite the data code of several applications every day of the week without affecting the view and the controller (i.e. the bulk of your code). From what I've seen, that clarity of what exactly is happening and how complex things are mapped really helps with maintenance and optimization. From trying to maintain persistense layers, I'm left trying to figure out "what on earth is the persistense layer trying to do that is causing so much trouble".