Ian Bicking: the old part of his blog

Re: What Really Makes Rails Work

And after all of that, you can't even mention Zope 3?

While everyone seems to have gone off and tried to make a "more pythonic framework" than Zope, Zope continues to enjoy high use and popularity. There are a lot of lessons learned from it - good and bad. And Zope 3 is an effort to learn from those lessons. I wish that more people would get involved in contributing to and working with the Zope 3 community than making yet-another-clone of the latest hot-web-technology.

(Although, I do give the Subway group serious credit for using existing solutions instead of rolling out new ones).

Twisted 2.0 uses Zope 3's interfaces system, and I've heard from a couple of sources that Zope X3 3.2 will be able to work with Twisted (and, hopefully, cool Nevow technologies like stan and LivePage can be used with Zope 3 with little effort).

Zope 3 offers better than strict model-view-controller separation. Without hard restrictions on "this is the controller, this is the view" (most of the time, a controller and view are so intertwined, why not just connect them as a single View object and not really worry about the Controller?). The model is often just a handful of persistent attributes, but there are more objects that make up an intelligent web application than can be deliniated by such restrictions (bug dependency trackers, etc). I don't think dumping things into directories/packages named 'model/view/controller' is the most "Pythonic" thing in the world. The python package and module model is better than that.

I've been using Python and Zope or some predeccesor of Zope professionally for nine years now. It's been serving Python objects on the web since PHP was just a small collection of Perl scripts trying to be a better Server-Side-Include. Why wouldn't you want to work with the community that's trying to take that success and combining it with the hard lessons learned over the past 8-9 years into the next generation "highly pythonic" platform?

Comment on What Really Makes Rails Work
by Jeff Shell


Sorry to forget Zope 3... I think it was in my original writing but I edited it out that paragraph. Zope 3 is both better than Zope 2 for Python programmers, and maybe worse in terms of bringing in non-Python programmers. I don't really see it as accessible to an off-the-street programmer who isn't committed to Python already. But there's also a good possibility that something built on Zope 3 will provide that experience -- something that looks like Plone, perhaps. Or another application that is itself a framework, but a more directed framework than the open space of Zope 3 as a whole.

It's getting off the original topic, but I do have some problems with Zope 3 (I haven't used it a whole lot, so I might be looking at it wrong). But it seems to put modeling up front, with the web UI coming along for the ride. But I think modeling is really hard, but making a web UI is pretty easy. And I think it's best to do the easy stuff first. So I'd prefer a system where development of the application UI came first (in a crude procedural manner if necessary), and the model grew out of that. I don't think this describes Rails, or Subway, and certainly not Zope 3. I guess it describes PHP, except PHP is good for that first step and bad for all following steps. Rails I suspect is appealing to a more mature developer that has gone through the PHP (or PHP-like) process. Zope 3 is appealing to a developer with a level of maturity that, I think, is very uncommon.

That said, I'd certainly like to take ideas from Zope 3 as well in my future work. Once I figure out what they are ;) I've become wary of Adaptation, though I've only tried to use it once (but it wasn't very successful). I like interfaces, especially as documentation. I should learn more to figure out what else there is. Hopefully Zope 3 people will also start distributing more stand-alone packages, which I think will increase its visibility, and let people become incrementally more comfortable with its concepts before they jump in entirely.

# Ian Bicking

You've misunderstood Rails if you think it doesn't support building the UI first and extracting a model from that. That's exactly the way DHH likes to approach development. You can write a Rails app that doesn't use a database (e.g. Instiki, a great Wiki based on a pre-release Rails, that uses a RAM/disk backend).

That means you can cruft up a UI, store values in memory or whatever, iterate until you like your UI, and extract a proper model.

If that's what you want, I suggest you give Rails a try, Ian :) (Apologies if you already have.)

# Gavin Sinclair

Maybe I misread the point of Ian's post, but the biggest reason I don't lean more towards Zope is that the model isn't for me. While if I were writing my own ideal web system I would probably do so in Python (because I like the language), when I'm looking for something pre-existing the language is much less important. As Ian said, people choose Rails because they like how the model helps them work and Ruby comes from that choice, and people choose Zope for similar reasons and Python comes as part of that choice. If the python community wants to have a dynamite web development platform that draws in excited new people, then make one or refine an existing one, but perhaps the key to drawing developers is that it is a "dynamite web development platform", not whether it is in Python or not.

That said, I do need to look at Zope3 and reconsider whether it provides a model I'd be comfortable working in, and whether it would make my life as a developer that much better. It's been a few years now, I should probably re-codify the things I'm looking for and figure out what system will get me closest and let me easily engineer the additional things I want.

# Luke Opperman