[Zope] FYI: Portal Toolkit Slides and Demo available

[Paul Everitt]

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/
-----------------------------------------