Andrew wrote:
Waiting on tenterhooks... Yesterday I read Philip Greenspun's book on Web publishing (http://www.photo.net/wtr/thebook/), and much of what he suggests seems like a natural fit to the Portal Toolkit. I'd recommend everyone check it out; the complete book is on-line, though it's well worth buying just for entertainment value.
Perused through it earlier this week -- looks interesting.
I've never pushed strongly for using Zope on our Web site (www.mems-exchange.org) for a few reasons:
1) Another programmer had already done some work with Java servlets, so we have some servlets to do various things. However, I've found that Java is really awful and cumbersome for Web programming. (But without automatic reloading of ExternalMethods, Zope isn't much *less* cumbersome for tasks that can't be handled in DTML.)
Hmm, I'm surprised that you'd advocate automatic reloading, as it would (at a minimum) stat a file on each request. Do you think it should be an optional knob to specify whether to check for changes? If so, what should be the default?
2) A fair amount of source code reading is still required, and Zope is so full of cutting-edge Python technique that it's not easy even for a long-time Python like me; for a new Python user, it would be deadly.
Not being too much of a programmer, and having tremendous respect for your programming, I'll of course have to cede this point. Would better documentation help? For instance, we intend, once Zope2 has landed, to begin the process of doing a UML model for all of Zope. We are already doing it for all new work. This includes many of the diagrams, including use cases. How helpful would that be? Second, we intend the UML model to formalize and document a "Zope API". Would having a clear statement of such a beast, for all things Zope including database adapters etc., significantly change your above statement? Farther out, we'd like to look at moving to Jim's "interfaces" proposal that was mostly agreed to at SPAM Houston. If we did (and then lived by it :^), how much would that help? If, in the end, Zope's fundamental ideas (acquisition, the Zope class model, etc.) are just too esoteric, then the above won't help.
3) I still haven't really figured out what the idioms are for implementing complicated forms. DTML is sufficient for simple forms with 2 or 3 fields, but if you have a 22-field form with complicated interactions between fields, DTML won't cut it. At DC, do you write ExternalMethods for such purposes, or full-blown products? How do you debug them without going insane from manually reloading ExternalMethods all the time?
Nearly everyone here spends a lot of time in the Python debugger instead of sitting in Zope, I think. I agree that debugging DTML is maddingly hard. In fact, I think about this probably fifty times a day. I sure hope, after Zope2 comes out, we step back and think HARD about things like usability. I presume by the leading part of the question that you would feel more comfortable doing your processing in Python than all-DTML. If Zope had a "Python Method" object, perhaps only usable by VERY privileged users, perhaps only in the Control Panel (say, in a Product), would that help?
However, the Portal Toolkit may well prove to be the wedge for getting
Just the kind of effect we were hoping for :^)
Zope on the site. I've already done a few simple Java servlets for registering users and presenting customized pages for a user, the intention being to turn www.mems-exchange.org into a specialized portal aimed at MEMS researchers and users of our virtual fab. People would have a single page which listed all of their ongoing jobs, recent status changes ("Your etch step #4 has completed; click here for metrology data"), MEMS news of interest to them, and similar info. If the Portal Toolkit could be used for this, it would save a *tremendous* amount of effort and wheel-reinventing. if you need someone to try out an alpha, let me know...
Heh heh, if I had a dime for the number of alpha volunteers for the portal toolkit :^) In the end, the presence of Z Classes, Z Class-based portal toolkit components, and a really nice search system out to make the portal toolkit something that more people will look at. We still have our work cut out for us, but we are awfully excited about it. Just an update on status. We're a bit behind -- our UML modelling tool apparently has a number of bugs that causes us to consistently get ureadable models. The vendor is mostly responsive but it still has caused things to grind to a halt here for the last week. Sigh. Thus, it's iffy whether zope.org will get its June reinvention, which is the predecessor step to checking everything into CVS. We are planning to revise our schedule at the end of next week. --Paul Paul Everitt Digital Creations paul@digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/ -----------------------------------------