I know that Stephan Richter has responded to many of these points. I'll add in some of my views as someone from the borderlands - I'm not a core developer, but I am someone who has used Zope since before it was Zope. Since before it was "before it was Zope". I worked on core Principia and Zope a long time ago, but have not been involved much with the core of Zope 3 besides following the conversations and chiming in (sometimes too much, sometimes asking unanswerable questions) on the mailing lists.
After tinkering with Zope 3 for a while, late last summer I had to build a Zope 3 application for real, and do it real fast. On 1/14/06, David Johnson <[EMAIL PROTECTED]> wrote: > > The documentation is not well defined, which makes deployment dangerous > because one may produce an application that does not conform to future > releases of Zope. Documentation is better defined than any previous release of Zope. Most of the documentation, as Stephen mentions, is at the API level and is used as doctests. I installed Zope 3.2 final on our development boxes the other day. Over 8000 tests ran succesfully, many of those coming from documentation. It's not only documentation, but documentation that works. Interfaces are generally well defined and in apidoc. There are some that don't make it into apidoc, and that can be frustrating. I need to make a better list of the ones I look for that I can't find so I can submit it as a collector issue. But generally, it is all very well defined. ZCML is well documented, which was a huge concern I had during Zope 3's development process. There are two published books. They are old, covering Zope 3.0, but I know www.worldcookery.com has updates for its book. Even though the books are a couple of releases old, many of the core concepts still apply. I'm trying to get back in the habit of consulting Stephan's book before asking a question of the mailing list. On the downside, there isn't much documentation showing how to pull a lot of this together. But how you pull it together is up to you. A twenty minute wiki how-to isn't going to provide you with good tips about how to write an e-commerce solution. An e-commerce how-to isn't going to help you write a knowledge base. There could be more documentation in this area, but writing it is hard when you've got full time jobs doing other things. Keeping it updated is even harder. This is affecting TurboGears, Django, and more - they have some good "get started quick!" tutorials. They've had issues keeping them up to date recently. The Wiki is terrible. But I hate wikis and if I believed in God I believe my god would consider Wikis an abomination unto him. It's good that there's a place for information to go that's reasonably central. But which of the various "related objects" proposals is current? So I never go in there. I get frustrated very quickly, and this is with a lot of work done by others to try to keep it organized. I like Trac, or even the Plone (I assume) based tools Schoolbell is using to publish information. "This is the 3.2 milestone. Here are the proposals and issues that are tied to that milestone" You can do this with Wikis, but it's all manual and the organization is seldom as nice and natural. Compare these (and yes, I'm aware that trac has a wiki - but it seems nice and secondary to some of the core information): http://trac.turbogears.org/turbogears/roadmap http://dev.zope.org/Zope3/RoadMap But while that would be nice, I don't have the time or experience to contribute to setting something like that up even if it were wanted by others, and I'm not volunteering anyone else to do it. Just wishful thinking. It's hard for me to find a decision tree of what went into Zope 3.2 and why, or to try to lobby support for something to go in Zope 3.3 and see proof somehow that it does by being able to follow an issue, a roadmap, a plan, etc. (The bug tracker product Stephan wrote in Zope 3 was really cool with grouping. I miss it). Regarding configuration, Stephan provided nice responses. > I can only find one semi real-world Zope 3 example (the SIP application), > and it does not even run under Zope 3.2; while I've been able to wade > through and fix many errors, I continue to get more as the interfaces and > standards keep changing. Even the current i18n facility does not seem to > work properly, editing messages frequently gives errors and does not update > properly. Errors in general seem to give unexplainable results. I struggle with i18n, but I admit to being a stupid American that wishes he didn't have to deal with it at all. This has nothing to do with Zope 3's implementation - it's just not a habit that I have. Getting used to unicode, encodings, messages, etc, was hard. But again - a admit complete and utter ignorance here. On the other hand - the question that I saw listed most on the "submit a question" list for the Snakes and Rubies meeting in Chicago had to deal with "when are you going to internationalize Rails?" It made me smile, knowing that Zope 3 dealt with that early and deep. It is annoying to see the MessageIDFactory deprecation warnings. I only have those and use those because I copied and pasted from something else and ran with it. For people like me, someone needs to write a "Basic Zope 3 Internationalization For Ignorant Americans". My customers don't need it, but if I don't provide it in some places, Zope 3 yells at me and then I feel sad... So knowing when you need them, when you need the i18n_domain in ZCML, would be nice. But this has never stopped me from charging ahead with Zope 3. > I do see many advantages to Zope 3 and I am willing to tolerate a lot > because of those advantages, but it seems like it not quite polished yet, > and there may be some architectural issues that are problematic for > real-world use. It's not an architecture that's suited to everything under the sun. But it's certainly in real world use. > Has anyone produced a significant application in Zope 3? Has it been > relatively bug-free? Has it integrated with an RDBMS? Yes. As I may have mentioned before, we converted our biggest customer over to Zope 3 this summer. We did it in a matter of weeks. It was a complete rewrite - their prior site was written using many different Zope 2 styles and techniques that we've used over the years to try to solve different problems. Big sites, big traffic. Custom FTP uploading and file management, a decent web based admin interface that eclipses anything we've done as a company prior to this. Integrated with an RDBMS for some data, but most of the content coming out of the ZODB. More than relatively bug free, and most bugs were easy to patch. This customer cannot have downtime, especially at this time of year. We then used some of what we did for them and applied it to three of that customer's sister companies. The last site we turned around in a week, including graphic design and all custom development. After that, we've made some major refactorings and restructurings to the underlying stack (our own set of packages that build on Zope 3). Zope 3.2 fixed a bug in Zope 3.1. The 3.1 bug didn't affect us, but the fix did. But this was our problem, not Zope's. It exposes some design flaws in our code that came from the rushed learning and devlopment of the core. Fixing those, testing them across four sites, and making sure the fixes worked in both Zope 3.1 and 3.2 took about a week - and a lot of that week was spent writing our own policies. "If you want a container, use this class. If it's like a folder and you want the folder responsibilities, use this interface..." (those classes and interfaces being our own core ones, and ones that were confusing before - again due to our own rushed development and not having anything to do with Zope per se). That week also involved just really digging out some common code that had been copied across customers and moved into the core. And then the branch was merged back in to the trunk and all four customers were updated. I think there was only one minor hiccup, and it was fixed in three lines. I cannot convey to you the magnitude of this project - it was a major refactoring, paying back technical debt accrued during rapid development and earlier deadlines. Most projects have to do this in their lifetime. But applying the updates to the public servers? Painless. I call that bug free. _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
