On some other criticisms of Zope 3 you mention.
ZCML is indeed XML and I think right now there's too much text and too little it really does. There was a drive towards ZCML simplification in Zope 3 that got a rid of ZCML directives. I think that this was a good initiative, but what is also revealed to me is that what remains of ZCML is not pulling its weight. Too many declarations, indeed. Later this week I'll be at a sprint to see what we can do with that insight. I think the concept of explicit configuration is extremely valuable as a base, but we need good conventions to make it less burdensome.
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 also think it sometimes can get in the way, and is not conductive to learning a system and can lead to rigidity in some cases. We're going to look into bringing some template-driven development back into Zope 3 at the sprint I already mentioned. I need to thank you for making this explicit in this and a previous comment on the same topic. I think we were already on the right track in our self-criticism, but you've provided some useful words I can reuse.
While I don't see what this has to do with the word "Pythonic", I do agree with the following: getting things done vs. doing things right, and thinks there's too much doing things right.
I think Zope 3 is in fact in a good place right now. We've focused on doing things right. We have a powerful architecture that focuses on reusable, pluggable components. We can do powerful model-driven development. With interfaces and doctests we have what amounts to a lot of awesome low-level documentation for developers. We have an explicit idea of declarations to hook things up. We're starting to gain a pool of lots of components to reuse when building an application.
Now we need to focus on getting things done. We need to focus on taking this platform and building on it: adding convenience for experienced developers, focusing on reducing verboseness (a consequence of our explicitness and pluggability), and making platform easier to learn and adopt for beginners. I am convinced we can do this: getting things done the right way. We're already in a good place, but let's see where we are a year from now.
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.# Ian Bicking
"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
Thanks for this comment which is very enlightening about Zope 3 philosophie.# Alex Garel