Ian Bicking: the old part of his blog

Re: Zope 3 critique comment 000

I think the CMS-ish focus is a good point. When I first learnt Zope 3, the book I was reading built something CMS-ish and it wasn't immediately obvious to me how to do "floating" templates not bound to a particular context (answer: either make them registered on *, which means "any interface" and you can just invoke them anywhere)

System Message: WARNING/2 (<string>, line 1); backlink

Inline emphasis start-string without end-string.

There is a kind of mismatch here, though. I find it very awkward to build certain types of applications in Java, say, because it is so template focused. I make directories inside my WEB-INF directory, and they become part of the URL, like /foo/pages/bar.jsp comes from Webapps/foo/WEB-INF/pages/bar.jsp (yes, I know there are ways to do different URL dispatch, that's not the point). You start from a template that pulls data from some bean, and probably needs a query paramter to know which records to pull out. In a CMS-ish world, I want to represent my content structure in the URLs. This is where Zope makes a lot of sense - you have a model that is essentially hierarhical, and you have registrations that if you visit /foo/bar and bar is of type IBar, then you get the default view on an IBar as registered with Zope, or if you go to /foo/bar/edit.html you get the edit.html view registered for IBar.

If you have no need for that kind of hierarchy, then everything becomes a view on ISiteRoot or even on * (i.e. could be used on any type of object). Then the overhead of those registrations probably feels a bit wrong. Of course there are pages like that in CMF-ish applications too, but the number tends to be reasonably well-contained.

However, I've found that a surprising number of real-world (often business-focused) applications can be modelled quite successfully on the concept of semi-structured content managed hierarchially. This has a lot to do with the fact that this is how people organise the files on their computer, I think.

That debate is somewhat philosophical, and I've always been an advocate of right-tool-for-the-right-job. However, I do feel that Zope 3 offers some very elegant solutions to certain design problems. I quite like that there is a small number of concepts (interfaces, utilities, adapters) that is used widely and quite consistently. On the other hand, I agree that it's probably not the simplest system and requires more up-front investment in the concepts of component oriented development than something more "flat" (which in the extreme case is just PHP).

As for views, what I like a lot about using views is that they give you a very natural place to put the Python code that is essentially your rendering logic. This code prepares simple data structures that the Zope Page Template renders using only basic TAL expressions (render this, make this tag conditional, repeat this tag over this list). Compared to how we used to develop in Zope 2, for example, it's a blessing. I agree that it's often model-driven, and that auto-generated forms are a mixed blessing, but you don't have to use them - we're just all too lazy! ;-)

Comment on Zope 3 critique comment 000
by Martin Aspeli