A lot has been going on around these parts lately. Heartache, frustration, disappointment, new hopes, new beginnings, and more. First up is a new living/working space for myself as well as new office space. Thanks to some fancy rapid moves, I'll soon be living in an artist studio in a row of converted warehouses I used to marvel at when younger. As the euc.cx mini-empire grows, this is a huge benefit. I'll be able to return to larger paintings, more spray (and hopefully print) work. I plan on re-learning electronics as well so I can start building my own sound modules. I'll be giving up a wonderful view and my beloved gas stove, but will be surrounded by galleries and studios and a local 'zine. I'll also be near the summer Farmer's Market. And nicest of all, our new offices are just down the block from me. I won't even have to cross a street. At most, I'll have to cross through a gourmet food market where one can find glorious things like Squid-Ink Spaghetti and Kinder Eggs.
On the audio front, there's a new Eucci release, The Mercer, a quiet electro-acoustic composition. aodl has a healthy set of live performances lined up over the next few months, playing before artists international and one state over.
I've been impressed lately with tools like QuickSilver, Ta-da lists, and BaseCamp. I've also been really impressed with paper. Good old fashioned A4 sized legal pads for work, a couple of different notebooks for personal life (I'm excited for the new Moleskine Pocket Reporter Notebooks). It's been interesting to observe a similar excitement for paper going on around the digital world. There's something great about simplicity and manual syncing. I use Ta-da lists to keep tabs on groceries and books to get, and write them down as necessary.
HBO recently announced that The Wire Season 4 will come in 2006. Oh happy day!
Now that a simple skin has been established, it's time to add some views to the todo list. In a style inspired by the article on how to build a todo list in Rails, we're going to present the todo list in two parts on the same page: Incomplete Items, and Completed Items. In the middle will be a form to add a new item. Looking back at the code and interfaces for the basic todo list, you'll notice that there's no real logic here. Just basic 'model' stuff. The list doesn't really care about separating complete and incomplete todo items - that's a detail specific to our browser view.
So one of the first things we need to do is write a Python class that will be a view component for an ITodoList. Its responsibilities will be:
I hear and hear and hear and read and read and read and interpret that there are too many web frameworks for Python. Why does the Python community seem to think this is limited to just them? Yeah, So there's Nevow, Quixote, Zope 2, Zope 3, CherryPy, WebWare, Spyce, bla bla bla. There are just as many different things available for Java, if not more. I can't keep up with Java Server Faces, Struts, Tapestry, J2EE's web parts, JSP, Servlets, on and on and on. I even see Python people look at all of the development and excitement around Ruby On Rails. But on RubyForge's WWW/HTTP - Dynamic Content listing, there are numerous other "web frameworks" and other libraries/toolkits for dynamic content. A similar listing on the Python Package Index (PyPI) is also a fairly big list. The point is - who cares?
There will never be one and only one magnificent web framework. For any language. Ever. Different toolkits have different strengths and play to different audiences. I HATE those who say "there should only be one. Everyone else only has one!" It's just not true.
What I do wish is that people would better explore the unique features of their languages in their web frameworks. I think Ruby On Rails does this expertly in Ruby. Seaside does this well for Smalltalk. I think that Bobo did this well for Python and so did Principia / Zope 1 and 2. Those are unique systems. Yes, Zope 2 has its faults, but it is still wildly successful. Zope and its predecessors were not trying to copy Rails, JSP, PHP, ASP, ColdFusion, CGI.pm or Java Servlets. I see too much of this. Even I was guilty of that, writing my own in the mid nineties inspired too much by NeXT's WebObjects. A model that makes sense for Java does not necessarily make sense for Python.
So, I applaud Quixote, which seems to take some of the concepts of early Bobo/Principia and cleans them up a bit. I applaud Nevow, what little I've seen of it. I've seen even less of CherryPy, which I've seen even less of, but looks to be "pythonic" as well. To a lesser extent, I even applaud Subway. Subway is trying to be a stack similar to Ruby On Rails, but I give it credit for utilizing many pre-written components. So, it's half copy, half original.
I still throw my personal weight and preference behind Zope 3. Zope 3 is simultaneously young and mature. In its released form, it's young. But it's been in development for years and already has some rather successful deployments and projects. I've only barely started working with it myself, but I've liked my experiences. Loose coupling is a magnificent thing. As I'm trying to integrate a well written but monolithic Zope 2 forum product into a more general web site, I realize the benefits of loosely coupled systems written as small components instead of a large monolithic class. I like the way that Zope 3 encourages code structure. More small collaborating objects instead of large massive-inheritance classes.
When it comes down to it, I'd rather have many web frameworks than one way to do it. The chances that any one style will fit everyone in the Python community are slim to nil. Both 'Quixote' and 'CherryPy' claim themselves to be "highly Pythonic." But what does that really mean?
When we last visited the little todo application for Zope X3, we had made some very basic views for the Zope Management Interface (ZMI). At this point, no HTML had been written. No other view/controller code had been written. And we didn't have much of a todo application, but we did have editable Todo objects being stored in a Todo List in the object database. But what it needs now is its own look. To do this, we need to make a skin.
In getting back to showing how to make a Todo List application in Zope X3, I've made a new category covering the simple todo application. Coming up next, I'll show how to write a custom skin for the todo list to give the application its own look, and how to write some new views and adapters to start making the list usable.
But before I continue, I'd like to remind the audience that this is based on How to make a todo list program with Rails 0.9. It's a simple and well written application, and I'm wanting to show Python programmers that they needn't necessarily copy Rails - that there are existing solutions for Python that, in my opinion, fit the Python mindset better. If you want to program in Rails, by all means just learn Ruby and use Rails and enjoy it. But me - I like Python, I have existing applications and libraries in it, and as I start to really explore Zope 3, I'm getting really excited about using it, which hopefully I can do in near-future work related projects.
Using the Rails Todo List example is how I'm finally pushing myself to investigate building a simple but complete Zope 3 application. There may be better ways to accomplish some of what I try here. I'm no Zope 3 expert. I have followed its development and had a hand in some of the concepts early on (many years ago), but have not had the chance to build anything substantial until now. So I thank the authors of the "How to make a todo list program with rails" document for generating some excitement and giving me an idea of something to build, and I hope that they don't mind my usage of what they document as basis for my explorations.