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?getti... 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.