The other point of criticism that I agree with is that the frontend side of web development needs more emphasis and attention. I think the concept of model-driven user interfaces can be extremely convenient and powerful (just look at what the Plone community is doing with Archetypes, and also with UML-driven development).
I think that content management systems and web apps are really quite different. You can implement either using the other, but it's probably not worth it. In the case of a CMS you really have to be much more abstract about your models, because you are operating on content objects in generic ways, and you probably have a lot of runtime-extensible parts of the system and UI. For a traditional web app (what someone would build with Rails, for instance) this isn't the case -- the UI is mostly fixed (but heavily designed), and it's not too bad to create ad hoc UI extensibility when the need arises.
I still find it very peculiar that no one seems to be writing a CMS with Zope 3, as that seems like the place where Zope 3 is most applicable.
Anyway, I think it's important to keep the CMS/webapp distinction in mind. Zope was used for webapps a lot back in the days of DTML and through-the-web development. It let developers sidestep lots of problems, and at a time when there wasn't as much collective knowledge about things like deployment and development practices so letting people move forward regardless of those issues was beneficial. But as we all know, that style of development didn't scale to more complex projects. At that point Zope took a turn towards a level of abstraction that is appropriate for a CMS (or for building a CMS), but too complex for banging out webapps.
And perhaps that's just fine. There's a lot of other frameworks that are working hard on the tools for webapp development, and it probably won't be that successful for Zope to try to get in on that directly. There's a lot of opportunities to embed (and be embedded by) those tools, and to use REST-style techniques to communicate between systems. I personally am really drawn to RESTful collaboration between tools because it's so incredibly unclever, crude and explicit and localized... I want to see more of that kind of thing.
"I still find it very peculiar that no one seems to be writing a CMS with Zope 3, as that seems like the place where Zope 3 is most applicable."
There's a simple answer for this: People are writing CMSes with Zope 3. Since we already have a bunch of powerful CMSes in Zope 2, they're doing it with Five in Zope 2. :) There are also some CMS initiatives in Zope 3, but nothing that got really prominent just yet. That will come.
Is it possible that with the ease of reusability of Zope3 components that a CMS isn't even necessary anymore? Instead of "fighting the framework", perhaps "there is no framework." What I find very interesting about Zope3 is that it doesn't really seem to be anything. It's more of a philosophy and a big big bag of (interoperable) components.# Kevin Smith
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)
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! ;-)# Martin Aspeli