I attended the tutorial on Zope 3 that Jim Fulton gave before PyCon. Altogether I was impressed, though I still have reservations (though that's not the topic of this post).
Particularly noticeable is how friendly Zope 3 is to external modules. Not just friendly, but enthusiastic -- the contact module in the tutorial specifically has no special Zope 3 bits. (I'd link to it, but the tutorial is a PDF... blech.) The module is fit into the Zope system through "configuration". (And presumably more advanced integration would be done through adapters, which also serve to separate Zope-neutral code from Zope-3-specific code.)
I put scare quotes around "configuration" because it's different than I usually think of configuration. It's not the kind of thing a system administrator would do, or something that you would do to install or customize a product, but something for a system integrator -- which is fully a programming task.
Anyway, that's all very refreshing compared to Zope 2. But it's also all very different than Zope 2. And there's no concrete plan for facilitating migration from Zope 2 to Zope 3. (There is "Frankenzope", which seems to basically be Zope 3 and Zope 2 both running in the same process space, and off the same ZODB.) And Zope 3 isn't (at least as advertised) ready for production (despite a couple production deployments which have already occurred). So, if you are excited about Zope 3, but you are mostly interested in application development (rather than framework development, which where Zope 3 is right now), what are you to do? How do you get ready for Zope 3?
One nice thing is you don't have to get ready for Zope 3, except to make good domain objects. Later you'll have to add configuration and views and other stuff, but that's life -- and if they do Zope 3 right, it shouldn't be too hard. But (in my experience) Zope 2 does not facilitate the creation of nice, neutral domain objects. It encourages the creation of objects that are as much "Zope" objects as they are domain objects -- if anything, the objects' Zopeness dominates their domain aspect.
So it occurs to me that the best way to develop for Zope 3 is to not develop for Zope 2. You might want to use some pieces -- Page Templates and ZODB, but the bulk of the Zope 2 environment is not present in Zope 3 (or needed).
This is all kind of ironic.
Writing good domain objects is indeed the right thing. I still write exclusively for Zope 2, but I've been using more and more 'zope component architecture' design principals in my designs.
The system integrator form of configuration is the part I'm looking forward to the most.
The question then: how possible is it to write Zope(2)-neutral domain objects to be used in Zope 2? The documentation I've looked at hasn't been much of a help -- much of it just describes how to do in-ZODB coding, often still in DTML, which seems like the worst of all worlds. So maybe I'm missing Zope's potential there... but then, I suspect most people are.
There's *very* little documentation on how to write *good* Zope apps. A bit more on the prerequesites you need to write not-so-good Zope apps.# Ian Bicking
Does "good" == "pure" Python domain objects? Everybody at least claims to want this, but much wrapping and componentization is required, and I suspect once people try to troubleshoot a fully componentized application, they will long nostalgically for the days when you just subclassed the shit out of stuff, because it's damned hard to backtrack through a componentized app that you didn't write yourself (or wrote two years ago).
But my best suggestion for separation of data and presentation in Zope 2 in its current state: write a class that is a "Zope class" (something that has all of the murky bits like the ZMI web interface and security declarations and whatnot) and either subclass a "pure" Python domain object or delegate to one from within this class. This is kind of a static adapter pattern I suppose.
But IMO you can write fairly good Zope 2 code that isn't componentized. You just need to accept its limitations and be at one with the fact that you're in a framework that dictates in certain non-negotiable ways how you should think about the problem. Otherwise, you end up in the hellish cycle of "fighting the framework" because you don't agree with some core assumptions made early in Zope's lifetime.
The best thing about Zope 3, IMO, is what it *doesn't* do, which is coddle the "through the web developer", who, also IMO, doesn't actually exist. There was this notion in Zope's early days that almost everything could be done through the web without writing Python class code. When it became evident that the work towards infrastructure required to support this was just too large of a task to chew off (e.g. ZClasses), the TTW stuff was rebranded to be the domain of "site developers" who could use the web interface to customize bits of a site with their browsers (edit Python Scripts, DTML, Page Templates), etc. However, these are the people who don't actually exist, because usually it's the developer who winds up doing this anyway. And to make matters worse, no developer actually ever wants to make coding changes inside the ZODB, because typically he needs to version control the code in some external SCM system. So... we wound up with "skins", which are filesystem files that pretend to be ZODB objects. This actually works really well for most apps. But you're right, it's damned confusing.
IMO the real issue isn't really one of "good" vs. "bad" code. Abstraction isn't always a good idea; if you need it, you can get it out of Zope 2, but if you don't, you're not forced to use it. The issue is that the framework is schizophrenic because Zope was hyped so heavily as a completely-TTW-driven development environment. No attention was paid to creating sane APIs for Python programmers, no attention was paid to developer docs (and still for the most part isn't), and so forth. So from a Python programmer's perspective, Zope 2 forces you write code which fulfills contracts that you really probably don't (and cant easily) understand, because the API is a mess. If it were instead hyped as a "Python-developer-friendly" system instead of a TTW development environment, things would likely be much clearer. I have great hopes for Z3 in that respect. Although calling it "Zope" is a bit of a stretch. ;-) I don't have great hopes for any kind of backwards compatibility, despite efforts being made towards that goal.
Actually I and my group are some of those non-existing through-the-web programmers - and we make money of several other of those non-existing ttw-programmers. ;-)
TTW in Zope2 ist fantastic if you build systems together with the customer, and if the customer isn't highly skilled programmers, but more of the "webmaster" type. They can learn quite fast how to do customizations and programming. And you can build solutions that they can take over and fiddle around with.
Sure, the code that results from working like this usually isn't very clean and nice - it's more like a garbage can where some garbage got intelligent while rotting away. Evolution taking over ;-) - but then, business is about making money. If you can make money by helping customers to build solutions they need and like and can maintain by themselves, it's ok to build intelligent garbage cans.
It's not as bad as people might think, because skill-limited people restrict themselves to skill-limited solutions and so debugging those systems usually is quite easy, as not much complicated code exists. So, yes, I like TTW, as it helps to pay my food.
Of course, complicated stuff is factored out of the TTW world and into Zope products, so it's more a TTW+Products world we live in. The only thing in TTW world we actually never use are ZClasses. They are too complicated to be understood by the customer and to restricted to be of use to the real programmers.
I don't have much faith in backwards compatibility either. But I would also be satisfied if I could just have a smooth migration path.
Keeping my Zope2 based apps running, and start migrating slowly to Zope3 would be good enough.
Some kind of magic transformation af a complex Zope 2 application into Zope 3 is too much to hope for.
What is the big deal of supporting python script in zope3?
Right now, Zope3 seems to be forcing ordinary zope application developer to become expert python programmer, which I don't like. It is vital to keep the flexibility. A framework will become popular only if it suits the majority of developers, not simply because it is supposed to have the best design so it may handle huge project.
Having the ability to compete against other well-known frameworks/servers(like weblogic+java) is good but do not lose the small/medium sized web application market--it does exist in a significant manner.