Zope and Enhydra Comparison by Paul Gresham, CEO/CTO, MediaVisual This is now available via the on-line Lutris Enhydra Journal (for access register via http://www.lutris.com/products/newsletter_registration.html ). Excerpt (which struck a particular chord with me): "The learning curve of Enhydra is initially steeper but shallows out quite quickly. The Zope learning curve is very shallow and then increases exponentially to x to power infinity at which point your head valorizes. Of course to give Zope its karma back, Zope is more easily accessible to non-programmers whereas Enhydra is much less-so. The main reason behind using Enhydra on our most critical product to date, was that we knew we could do it with servlets, and that worst case, and given the structure of enhydra, we knew we could code our way out of any problems. Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems. The upshot is that our Zope projects were rather painful and Enhydra ones wore out our keyboards with so much code." The second sentence is perhaps a candidate for http://dna.yi.org/Zope/Quotes. Maybe a North American reader could confirm that "valorizes" means what I think it means ;-) Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
Paul Browning wrote:
Zope and Enhydra Comparison by Paul Gresham, CEO/CTO, MediaVisual
...
The main reason behind using Enhydra on our most critical product to date, was that we knew we could do it with servlets, and that worst case, and given the structure of enhydra, we knew we could code our way out of any problems. Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems. The upshot is that our Zope projects were rather painful and Enhydra ones wore out our keyboards with so much code."
So, in summary. They didn't know Python, but did know that if they wrote enough Java they could solve a problem? <s>
The second sentence is perhaps a candidate for http://dna.yi.org/Zope/Quotes. Maybe a North American reader could confirm that "valorizes" means what I think it means ;-)
I suspect it is a mis-typed word for "vaporizes". Otherwise you get to choose: 1.To establish and maintain the price of (a commodity) by governmental action. 2.To give or assign a value to: "The prophets valorized history" (Mircea Eliade). -- Tim Cook, President -- Free Practice Management,Inc. | http://www.FreePM.com Office: (901) 884-4126 "When the government fears the People, that is Liberty. When the People fear the Government, that is tyranny." ~~ Thomas Jefferson
Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems.
What in the world does that mean?!? Maybe it should read "We don't know how to use Zope or code in Python."
The second sentence is perhaps a candidate for http://dna.yi.org/Zope/Quotes. Maybe a North American reader could confirm that "valorizes" means what I think it means ;-)
Perhaps a typo? "vaporizes" fits pretty well there. My head has done that before while working with Zope. :-) _______________________ Ron Bickers Logic Etc, Inc. rbickers@logicetc.com
Perhaps a typo? "vaporizes" fits pretty well there. My head has done that before while working with Zope. :-)
Have you ever tried Java? If you love a vaporized head, switch to Java and be sure to pick Oracle's Internet Application Server to be your trustworthy companion on a steep learning curve. Can't go wrong with Oracle ;) I see a market for each product; Zope for content heavy, Java based stuff for transaction heavy stuff with legacy integration etc. As long as I don't have to go Java, I'd rather have .NET ;) Cya Jonathan
Ron Bickers wrote:
Using Zope we knew that we would reach situations which may be unresolvable in the short term, and could not make significant business decisions with so many unknown factors and lack of any way to circumvent problems.
What in the world does that mean?!? Maybe it should read "We don't know how to use Zope or code in Python."
I can give you a personal example. When I was trying to get LoginManager to display it's stored users in the local roles security form, I couldn't fix it using what I knew, which was DTML and ZClasses. I had asked for help on the lists, and got some pointers in the general direction, but that was all. After a week of crawling around in Zope's source (and a lot of whining), I found the parts I needed to duplicate for PersistentUserSource.py, and I added them. It should not have taken me a week, except that I don't really consider myself a coder. The only thing that made it possible at all was my extensive experience *using* zope, and my familiarity with Tracebacks and a basic understanding of most of Zope's underlying mechanisms. If I had been a real Zope/Python coder, I probably would have figured it out in a day. 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, and the fact that LoginManager is not an 'official' core Zope product could have been a show-stopper. (Why did I have to use LoginManager, you ask? Membership requires it, and I needed to store user data in the ZODB about NT authenticated users on a Solaris box. Gah). So the problem, as I see it, is multiple dependencies that may not be obvious. While over the long term, factoring common functionality into separate products that other products depend on makes more sense, and creates a *much* more powerful framework, in the interim (waiting for things to jell) it can frustrating as all get-out, and pretty easy to get stuck. Conversely, that things about Zope that are relatively mature are a dream to use and leverage, so this is an acceptable trade-off for me. Cheers, Michael Bernstein.
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? _______________________ Ron Bickers Logic Etc, Inc. rbickers@logicetc.com
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.
hi, Well. You can purchas support can you not? I mean that is how the company makes it's money right? Some companies charge for the product and give you some service, other give you the product and you purchas support. If you don't want to pay for a product or support they you get what is avail. I use Enhydra also because I do Java at Uni. If somone came to me and said I need a web app to do X I would do it in Zope. j. ...................... ..... Jason C. Leach ... University College of the Cariboo. .. On Wed, 17 Jan 2001, Michael Bernstein wrote:
Ron Bickers wrote:
I can give you a personal example. When I was trying to get LoginManager to display it's stored users in the local roles
After a week of crawling around in Zope's source (and a lot
hi, To comment on this part. I suspect it's that way with any product. I can name plenty of producs Windows or Linux based that I have had to sit down at as a novice, then that pases and I get better at it. Zope, Linux, Windows 2000 (ADO) all have done that to me. j. ...................... ..... Jason C. Leach ... University College of the Cariboo. .. On Wed, 17 Jan 2001, Michael Bernstein 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,
participants (6)
-
Jason C. Leach -
Jonathan (Listserv Account) -
Michael Bernstein -
Paul Browning -
Ron Bickers -
Tim Cook