I would like to quickly comment on this days-old email-- Our experience with the Zope environment, as well as ZopeCorp., has been overwhelmingly positive, and compared to what was being used before, Zope was a godsend. We needed to build a system which would: enable us to set up many markets, and many stations(radio or tv) quickly and smoothly enable station personnel to quickly update their sites share content(stories, images, etc) across stations in a market enable a designer to quickly and easily modify look and feel enable us to quickly add any kind of functionality or widget and probably a few other things I can't think of at the moment. It's quite a complex system, nothing like your "braindead just talk to the SQL database" application. In fact, we found the ZODB to be more than capable of storing and serving up thousands and thousands of objects (stories, images, etc.). We never had the need nor the desire to dump them onto the filesystem (with the exception of large audio and video files). The current product is divided into Python filesystem base classes, which did the heavy work, and ZClasses,which did the look and feel work (this was back in the day when ZClasses were fashionable). We used LocalFS to access certain news, traffic and weather data which we receive from external sources, and never really had a problem with it. Granted, developer documentation is on the lean side, however it is far better now than it was several months ago, and gets better all the time. Maybe I was dreaming, but I thought there was an html reference guide listing all available methods and objects? And when all else fails, we found reading the source code to be enormously helpful and mindnumbingly easy to understand, for the most part. Perhaps we just intuitively grasped Zope concepts and architecture. After working with various web application environments, from dinky perl scripts, to full-blown java application servers, I found Zope to be close to the ideal development platform. It enabled us to grow from 6 major station sites in one market to ~30 in various markets across the country in under 5 months. And I should also mention ZopeCorp has been overall a fantastic company to work with. If you want a project done well, and you have the budget for it, I highly recommend throwing all your money towards ZC. It would be a wise choice. -- -Lance T. Carito Viacom Local Networks *Note: I should probably mention this is my own personal opinion, and may or may not reflect my company's viewpoint. On Wed, 3 Apr 2002, Derek Simkowiak wrote:

I recently did a "web application" for a client. My first thought was to use Zope, so I built my app in Zope.

But I needed access to the file system. And WebDAV. And SSL. Once you step outside of the Zope security model (i.e., to work with files or the network), things get sloppy quickly. LFS had some problem I had to fix, too--and since RPMs of the latest Zope are not routinely produced or easy to find, I'm running an outdated version that I know has serious memory corruption issues.

There is also a massive void of _Developer_ documentation (where is the HTML, completely cross-referenced, documented object hierarchy listing all methods and members?) and I doubt that this problem will be fixed anytime soon. Last time I whined about this I was basically told that developer documentation was not a priority. (I own three Zope books, they didn't help.)

So after a couple of weeks of mulling about, discontent with my Zope-based design, I redid the entire project from scratch using Apache with mod_python (and of course mod_dav and mod_ssl). It took me 4 days, and the client is very happy.

My opinion, after having done 4 production projects with Zope and 2 tech demos, is that it's great for a braindead "just talk to the SQL database" project, or if you want to use a pre-existing Product (like Squishdot, which rocks, for example). But if you need to write something from scratch that needs access to the filesystem, it makes more sense to just use mod_python or PHP. (I've fallen off the Perl wagon completely, but if that's your thing... :) Also, Apache is far more flexible than Zope as a deployment platform.

The lack of developer docs, plus the headache of understanding every little Zope quirk and having to develop your own "best practices" makes Zope a less-than-perfect development platform (DTML Method or Document? PythonScript or External Method? Untar in /ZOPE_HOME/ or in /ZOPE_HOME/lib/python/Products? ZClass or just clone a template? Distribute a .zexp or a .tar.gz? What Property Sheets should my Product have? How to map FTP uploads to particular Zope Meta Types? Write my own management U.I. or use the Zope management interface? Branded error pages? DTML or ZPT? Etc.)

Finally, I'm sure my opinion is biased. I am far more familiar with Apache's internals than I am Zope's (my old dayjob was working on a C Apache module sold commercially). This is just my opinion, send any flames to me personally and not to the list.

Thank You, Derek Simkowiak dereks at realloc dot net

On Fri, 2002-04-05 at 16:48, Derek Simkowiak wrote: ...

Of course, this small project didn't have a budget for Zope Corp. Perhaps that is the key? If you have a big project that can afford Zope Corp.'s expertise, Zope is a great solution; but if you need to build it in-house, then expect to spend lots of time surfing the Zope source code (?).

Or other Zope Consultants. -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).