So, my recent problems with Zope 3 that were making me want to resume smoking? Yeah, I’m a smoker again. Two months clean. The stress just got to be too much.
I reported my problems to the community, with long and detailed explanations and explorations and pleas for help. The responses? Very few. Far fewer than I would have hoped. I had to scrap upgrading a customer to Zope 3.3 after losing a day of work trying to upgrade their database, unsuccessfully. Back to 3.1 they go. And now maybe we’ll forget about this for another year and have an even harder time upgrading next year.
Combined with another day lost chasing an obscure bug (moral of the story - sometimes saying that you implement the interface you implement can be bad, at least in cases where people do identity checks against self when attempting to retrieve keys out of a system), I’m pretty pissed. I really want to leave it all behind. I can’t. But right now, I’d like to. Even when Zope 3 is working, there are some common activities that seem to take way too long to accomplish. I feel like I’ve been spending a vast chunk of my time in recent months focusing on building tools and classes on top of Zope 3 that could bring at least some of what I see and like in Rails and Pylons while taking advantage of Zope 3’s strengths.
I think Zope 3 can be good for CMS type applications. And even for big business and public applications, it can be a good system. The so-called “MVC” stack of the new breed of systems bugs me. I have mixed feelings on templates these days. I think that with good objects, one can generate simple HTML out of Python (or any other programming language) which can then be styled up with CSS. It’s not appropriate for all situations, but it can be a great tool.
But, I must admit, I like what I’ve seen of Pylons. I installed it yesterday and ran through a couple of the tutorials (not even getting to the Wiki tutorial). Last night, I decided to convert the Basic To-do Application that I wrote up last year to Pylons, using SQLAlchemy as the storage mechanism. Fortunately I had some recent (and inspired, if I do say so) SQLAlchemy work done for Zope 3 whose ideas I was able to borrow to get the basic Alchemy session and engine management working in my application. I had just a single table and thus a single model class (keys: ‘id’, ‘description’, and ‘done’).
I decided to go for the same minimum of functionality that I had gone for in the Basic To-do scenario: have a single page that lists completed and incomplete items, with a small form to add new items to the system.
I got this done - including the writing of the simple SQLAlchemy bridge - in about an hour or hour and a half. No time wasted writing ZCML. No time wasted turning off the ZMI. It was generally quite easy. I made a few faltering steps along the way, but not many.
I think Pylons may be the sleeper hit out of all of the Python “web frameworks”. TurboGears got to be overwhelming, immediately. I think that I’ve just never been a fan of its core components. No offense to their authors. Django is also a bit overwhelming. It’s more like Zope: more of a complete environment. That can be great for many uses, but it can be a hindrance for others. I think Django is a terrific system from what I’ve seen of it, but it’s too big for me. I have one big system in my life already.
I have a bit more admiration for the core bits of Pylons. While I’m not a big fan of its syntax, I do think that Myghty (a port of Mason) has a substantial amount to offer beyond just being a templating language: namely lots of caching options and intelligence. SkunkWeb was the only other Python web system that I’ve seen that seems to make caching such a priority. The alternate templating languages one can use in Pylons - Kid and Cheetah - are not at all appealing to me.
WebHelpers are alright as a collection of useful functions for use in templates and controllers. I’ve had a blast taking the helpers concept and implementing it in our new Zope 3 based sites. It makes a big difference. With a good base set of helpers that are easy to expand on, it becomes much more desirable to use Python expressions straight up in templates. When I saw the ERB code in many Rails projects, I was impressed - it didn’t look like the typical mess of common PHP / Classic ASP style development; nor did it have to create yet-another-language on top of its base with hard to learn bind / call semantics. One doesn’t have to translate::
<% h.text_field(name='description', size=35, maxlength=100) %>
into “what Python or template or other thing does that there code call?” compared to::
<f:text name=quest label="Question:" />
The latter coming from Spyce, from an entry on the Spyced Blog.
Actually, I was starting to want to use Spyce in my Zope projects in spaces where we had Helpers doing many common tasks (like seen above) and ZPT was way way way too verbose:
<input tal:replace="structure python:view.h.text_field(...)" />
But Spyce has grown up into a richer system, where all I really want is a good basic Python Server Pages style system. But I’ve never come across one that I’ve liked: something small, simple, fast, easy to bind, meant to work with others (ie - not meant to be standalone pages with big blocks of Python, but rather to work with a view/controller class and helpers).
Back to what I like about Pylons - the last two are Routes, which does the URL dispatch (writing maps like in Rails and Django); and the aggressive use of WSGI / Paste. These seem to be bringing the Component Architecture dream of Zope 3 closer to reality as there are additional filters and middleware one can put around one’s application. Paste provides all sorts of cool features. There seem to be a lot of options for interchangeability.
I’m hoping that Zope 3’s “eggification” will make it easy to write Zope 3 style applications without having to use Zope 3. There are a lot of great libraries and toolkits in the heart of Zope 3 whose liberation would be most welcome. Even without that, I hope to look into what might happen if Zope 3’s libraries were just added to the Python path so that a Pylons application might be written up, using Zope 3’s concept of Views (Multi-adapters) and Transactions with objects pulled from SQLAlchemy without all of Zope’s security and nonsense.
Posted by Jeff Shell at
3:41 PM
