[Zope3-dev] Interesting parallels between Zope approach and N aked Objects

[R. David Murray]

On Tue, 12 Nov 2002, Chris Withers wrote:
> Stephan Richter wrote:
> > No I don't think so. I think the new way just saves you a lot of overhead and
> > nasty monkey patching. People still have to think (they even have to think
> > harder)
>
> Guys, that really needs not to be the case in the long run if you want Zope 3 to
> succeed.

Although Stephan seems to accept your interpretation as valid, I
dissagree.  I think what we are talking about here is the difference
between taking a non-zope python module someone else has developed,
fidling with it, and sticking some dtml pages on top of it, versus
thinking carefully about how to best wrap that module up in Z3
framework support wrappers (ie: write adapters, etc) so that you
can use it in Z3 *without touching the base code*.  The huge win
there is that when the author updates the module, you just sync up
your copy, and only change your framework-integration code if some
API feature of the module changed or you want access to new features.

You can still copy somebody's code, fiddle with it, tack some page
templates on top, and use it in Z3.  I don't think that will be
much harder in Z3 that it was in Z2, and I actually think it will
be a lot easier.  Of course, it will require *different* knowledge
than it required in Z2, and you've had years to acquire the latter,
so it's going to feel like a lot at first.  Since the Interfaces are
cleaner, I think the learning curve will be a lot shorter.  But
if you do it this way, it'll be just as hard as it was in Z2 to
keep your zopified version of the non-zope module synced with that
of the module's maintainer.

In a similar fashion I think writing zope modules from scratch
will be easier to do wrong(*) (ie: without much thought), and a
*lot* easier to do right (ie: with careful thought as to integration
with the framework) than it was in z2.

IMO it'll be easier for programmers new to Zope to learn how to do
both 3rd party module integration and new module creation than it
was for programmers new to Z2.  It *will* require more thought in
that it is a matter of selecting and assembling a greater number
more tightly focused pieces, as opposed to using a one-size-fits-all
monolith (SimpleItem, Folder).  But this extra thought will most
likely be *welcomed* because it represents greater flexability.
Thus Z3 will hopefully encourage *careful* thought as to how best
to do these tings.  I also expect that some best practices boilerplate
may develop fairly quickly that will make this stuff a *lot* easier
than it was in Z2.

How us old-timers cope with the changes will depend on our individual
personalities <grin>.

--RDM

(*) I can't quite figure out the English to say that succinctly.  I
*don't* mean you'll be led by z3 into doing it wrong more easily;
the reverse will likely be true:  the "natural" way to hook up the
framework should tend to also be the *right* way.  But if you insist
on coding thoughtlessly, you'll still probably be able to get your
code working faster in Z3 than you could have in z2.

PS: after re-reading my note, I think the source of the dissonence
I found between Stephan's statement and Chris' reaction is that the
fact that Z3 requires more thought does *not* mean that it is harder
to use or that your code takes longer to get working.  The reverse
is almost certainly true!!