[Zope] Zope Versus Enhydra Comparison article

[Michael Bernstein]

Ron Bickers wrote:
> 
> > However, for a programmer who had to come into the Zope
> > environment 'cold', the problem would likely have seemed
> > intractable. They wouldn't have even known where to look,
> 
> How does Enhydra differ?  Wouldn't the same problems be true for someone
> working with Enhydra that knows Zope/Python really well but has zero
> Enhydra/Java experience?

Please scan through their 'getting started' document:
http://www.lutris.com/documentation/lutris-enhydra/35/books/index.html?getting-started

You'll see that Enhydra, like most app-servers, is basically
a thin layer on top of a relational data model. What
infrastructure is there is basically aimed at easing the
pain of bridging the object-relational gap. To that end,
they have a lot of Wizards that automate boring tasks, and
present the the OR mapping in a pretty graphical interface.
Great.

They also provide some of the basic low-level building
blocks for web applications like session managers.
Wonderful.

They even cleanly separate the presentation- and
business-logic layers for you. Woohoo.

User mangement? Build your own. ACL security? Build your
own. Etc.

Faced with a situation like this, a programmer will
typically build *exactly what they need*, and no more. Every
site an island. And all of this is built on top of Enhydra's
core functionality.

Zope's approach, of generalizing and integrating common
design patterns into the core product, tends to poke
developers in a different way.

Consider LoginManager. LM is a product that is designed to
be a drop in replacement for Zope's existing acl_users
objects, but to be more extensible. Faced with a generalized
solution that I could extend to authenticate using SMB and
still store user info in the ZODB, but that doesn't
correctly participate in Zope's local roles machinery, my
initial reaction was to *fix it*. Which I did after a week
of whacking on it. Which was itself the culmination of a
month of, well, whacking on other aspects of the problem.

An Enhydra developer would have developed a custom solution
for managing their user objects. It would not have been as
generalized, almost certainly would have included only
simple permission flags used at the Business Object layer,
and had other deficiencies that I won't ennumerate. But it
would have done exactly what he needed to do right then.

I, on the other hand, after solving the local roles problem,
was able to install Membership, tweak the Tracker product to
use the getUserNames method, change a few permissions on a
Squishdot instance, and pretty soon I had myself a nice
little NT authenticated Intranet on the Solaris box, one
that I *knew* was extensible. Thus, it was worth the pain of
having to delve into Zope's source.

In conclusion, Enhydra, like most application servers, hides
it's internals behind lowest common denominator interfaces,
and encourages you to build on top of them. Zope, on the
other hand, tries to create 'highest common denominator'
interfaces and frameworks, and encourages you to extend or
override them.

This results in Enhydra developers needing to know Java plus
Enhydra's idioms, wheras Zope developers need to know Python
and Zope's *internals*.

HTH,

Michael Bernstein.