[Zope-PTK] Stability rule-of-thumb (fwd)

[Mike Pelletier]

    Holy shmoley, people are already building apps with the PTK.  Here's
some mail I just wrote to one such brave soul, edited a touch.  I figure
it is useful to to anyone else this brave.

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434

---------- Forwarded message ----------
Date: Thu, 3 Feb 2000 12:10:10 -0500 (EST)
From: Mike Pelletier <mike@digicool.com>
Subject: Stability rule-of-thumb

    I haven't got a feature list rated for stability for you, but I do
have a pretty firm rule of thumb.  If it's in PTKBase, it's intended to be
pretty firm.  If it's in DemoApp or it's ZClasses, it's not at all
firm.  The idea is that the portal implementor is expected to build their
own version of that stuff, using DemoApp as a model.  Building directly on
DemoApp is done at your own peril.  Being partially ZClass based, I think
the risk of using it is quite high.

    You might be saying, "All the useful stuff is in DemoApp!  This
sucks!"  There are certainly features in DemoApp which should be moved to
PTKBase.  Most of the stuff that's in there which should be moved (the
Wizard system, implementation of the MemberFolder and Member, etc) is very
definatly not solid yet, which is why it's not in PTKBase.  However, there
isn't a lot of actual code in DemoApp, and when I'm done with it there
will be even less.

    This is not to say that PTKBase is written in stone, either.  Clearly
MemberFolderBase and MemberBase are going to change quite a lot to take
advantage of GUF and whatnot.  It'll be done so as to disturb as little
existing code as possible, but I'm not yet willing to guarantee that it
will not require any changes.  (Wait `till later today.)  The key point,
though, is don't use DemoApp as your actual portal object.  Use it as a
model to develop your own Portal, MemberFolder and Member classes.  (The
interface you're expected to implement is coming today.)

   I appologise for all the accumulated kruft in the ZClass Product.  I'll
be cleaning it up soon.

Mike.