Blue Sky On Mars

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?

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.

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