TurboGears on slashdot! And a TurboGears job!
by Kevin Dangoor
This is the kind of morning I like to wake up to. A very interesting one. The first thing I noticed was email saying my blog was down. (That’s due to a problem with my MySQL start up script… I guess the server rebooted but MySQL didn’t come back.)
Then I saw the mention that TurboGears has been slashdottted! Thanks to Guillem Cantallops Ramis for getting us on the front page!
And, I was really excited to see a message from Ned Batchelder letting me know that the first TurboGears job posting is now up at Python.org.
Wow. All of this on what is a weekend day for me.
I watched the twenty-minute wiki movie with interest and am going to dedicate some time to playing with TurboGears; it’ll be nice to do get re-aquainted with Python after spending a lot of time with Scheme and Ruby. I did notice a couple problems with the design of the Wiki that you may want to address in the next revision.
First, the regular expression for matching wiki words does not match CamelCase words with a single capital letter e.g. “Kid”. Assuming you want to only allow non-accented upper and lowercase Latin letters, the regular expression should look more like something like this:
(([A-Z][a-z]*)+)
Second, the code to save a Page should not take a “new” parameter, at least not one that works the way it does in the demo. What happens if two people click the TurboGears link, decide to write some content for it, and click “Save”? The first call of save will succeed; what about the second one? A more defensive approach would be to check for a page’s existence and then create a new page or update an existing page as necessary. That said, dealing with multiple concurrent users doesn’t always have an obvious solution, and addressing the problem fully could easily send you down a rabbit hole.
These are minor issues, but one of my pet peeves about introductory tutorials is that they often paper-over a lot of the complexities that real applications inevitably need to deal with. One might counter that the point of a tutorial is to give neophytes a taste of the flavor of a technology, and I agree, but they should give a taste of what it’s like to build a real application.
Just out of curiosity, why is it that the homepage for the advanced TurboGears web framework would use a table-driven design, especially since it clearly makes use of CSS for other things?
Ed:
Thanks for the thoughtful comments about the tutorial. There are a few different ways to interpret what a wikiword should be, but it didn’t seem that important for the purposes of the demo.
I do agree that a real wiki needs to deal with editing conflicts in some manner (and all good wikis do). This tutorial is the first, so it’s a quick overview of building an app start to finish. Dave Warnock recently posted a good list of follow on tutorials that would cover other areas. This seems like a good strategy to me: have an overview tutorial and additional tutorials that are more targeted.
As you said, it’s easy to get sent down the rabbit hole trying to deal with concurrency for the app, and that’s really not the point of the video.
Anonymous:
I’m not a designer. The designer who made that layout used PhotoShop to do the design, chopped it up via slices and then made some modifications from there. Working with a bunch of nested tables is not my idea of a good time, but I did like the way it looked.
Sebastian Jansson has redone the inner pages entirely with divs and far more pleasant CSS. This will be the site layout that comes with the next version of TurboGears.
Thanks for the reply. I like the idea of follow-up tutorials. In part two–or three, or five–you can say, “Remember what we did with page editing way back when? Let’s think about what happens when two people try to edit a page at the same time, or someone tries to create a page that already exists. How do we want our wiki to behave in those situations?” And so the wiki can evolve from naïve to polished and bulletproof.
Once you have beautiful, bug-free code, the next step is to extract the common logic and package it in some way that can be easily re-used. I haven’t yet gotten around to getting started in TurboGears, so I don’t know if such a mechanism yet exists in the stack. But whatever the mechanism is, having a movie show that too would be invaluable.
The company I work for is looking for a good CMS and a good application framework to rewrite some of our older PHP in. So sometime soon I’ll be testing out various frameworks including TurboGears (so far my personal favorite), Django, Zope/Plone, etc. The two main criteria I’ll be looking for are speed of development (TurboGears/Django winning this round) and ease of maintainability. There are only a few things stopping me from just throwing everything elese away and running with TurboGears as-is:
1) Sessions (Solveable with KID filters?)
2) Modularity (We have business databases, image galleries, etc. which can all be shared code.)
3) Handling of HTML entities in KID templates. shouldn’t kill the server.
We’ll see what happens when I get the OK for the project.
Though a single comments thread on Blue Sky On Mars is probably not the best place to have an in-depth yet wide-ranging discussion about TurboGears, I’ll toss out a couple of quick answers…
- Sessions: CherryPy 2.1 has entirely redone its sessions support. I have not yet used it myself, but from what I’ve read on the CP list it is far more powerful than the earlier session handling. So, that’s built in via CherryPy.
- Modularity: you can write your code in a modular manner, just as you can in Python. Python Eggs make deployment easier. The part of the picture that is not yet filled in is how you can plug web apps directly in to a larger site, which we’ll hopefully deal with by 1.0.
- Entities in Kid templates: yep, that’s a pain. Patches accepted, of course. I’m certain we’ll find a solution, but it hasn’t appeared yet.
Hey, I should thank YOU, TurboGears is really good. I just tried to bring the deserved attention to it. A nice slashdotting at the right time can make a difference for almost any project. Hopefully all this new visibility will make TurboGears even better! I wish you Good Luck. I will keep an eye on this
BTW: I wasn’t aware of the file size limits in the Coral Cache, fortunately they are doing transparent redirection. Well, it has been funnier for you this way