[Zope] Questions concerning development in Zope

[Michael Havard]

>* Zope is often criticised for its perceived lack of documentation. 
>Although the current Zope book seems to have improved greatly, I still miss 
>a good reference guide/book on advanded topics (the Development Guide seems 
>to have stuck at version 2.4 and is rather limited). Which book(s) can 
>fullfill this role?

There are some 'holes' in documentation but... to fill in those holes there 
are user groups, websites like ZOPELabs.com, quite a few user created 
tutorials and technical quides, and of course this list. I think ZOPE is 
under such heavy developement over the past year or so that it's been a 
little bit of a moving target to create new documentation for books and 
such.

>* Zope seems to lack a dominant development methodology/paradigm. DOT.NET 
>has got form-based ASP.NET/ADO.NET, Java has MVC with Struts/J2EE, PHP has 
>either form-based or MVC with Pear/Smarty. What shoudl I use in Zope? ZTP 
>with Scripts? Or external Methods? ZCLasses? Products?

That's a little bit of an apples/oranges comparison I think. Most of the 
development being done within ZOPE isn't ground up developement, it's adding 
on/extending existing products or objects. Again, I think because ZOPE is a 
continually growing/living/breathing framework that it's difficult at this 
point to pick ONE development methodology.

What you use INSIDE of ZOPE is really defined by what you want to do WITH 
ZOPE. Mostly you'll work with ZPT (maybe DTML) and some python scripts, you 
might end up taking it a step farther and making a simple Product just to 
keep things tidy. Then depending on your needs you might need to provide 
some external methods. Pretty much everyone I've heard from lately has said 
"Stay away from ZCLasses" and many of the Products out there have shifted 
away from ZClasses.

>* Releated to the former question: ASP.NET and PHP (through Pear) excell in 
>easy (fast!) form-based development. What functionality can Zope offer? 
>I've seen some references to a " Formulator"  product.

Fast is a relative term. I hear that Formulator is good as well as 
ArcheTypes. ArcheTypes seems to have more meat to it though and is being 
used as a base for other products as well.

Most of the development that you do in ZOPE is from the webform, either one 
provided by ZOPE/CMF/Product 'X' or one you create/customize. It might be a 
ZMI form or a CMF Content Type edit form, or a form generated from a python 
script. Some of those forms aren't anything more than a textarea but it just 
all depends on what kind of development that you need to do.

>* Plone seems to be all the rage. But is Plone usable as an application 
>framework? Can I use Plone for form-based, data-driven applications?

Plone is great. It's essentially a repackaging of products in conjunction 
with the CMF and some custom work on templates, workflows, and scripts. 
Plone is very usable and can be customized (because it's all ZOPE 
underneath) to fullfill any needs that ZOPE can fullfill. It doesn't have 
any 'magic' underneath that makes it any more extensible than the base ZOPE 
product but it does have some 'nice-to-haves'. Just like from the previous 
question you could use Formulator or Archetypes to help with content types 
and forms. If you need to get into a database you could use ZSQL and forms 
to provide a 'data driven' UI.

Right now we use ZOPE, CMF, DCOracle2, ZSQL, ZPT, Python Script, and a very 
basic custom Product to create a "Client Record". The Client Record lives in 
two parts, a metadata 'stub' housed in the ZOPE database and 72 fields of 
information housed in 5 tables in an Oracle database. Users can update the 
Oracle information directly from the ZOPE UI using a custom edit form. They 
can also view the information using a custom view form. Forms, permissions, 
field properties, zsql, et al are packaged as a Product so that we can keep 
it all organized neatly.

>* Thanks to Python's Global Interpreter Lock, Python programs don't scale 
>well on SMP systems. Which is a "must have"  in our situation. I' ve found 
>some references to using ZEO to circumvent this, effectively running 
>multiple instances of Zope on one server. Is there any documentation to be 
>found on this subject? And how proven is this solution?

Can't really comment on how Python programs scale... However many 
applications use multiple instances as a means of load balancing and 
scaling. Currently we run Silverstream for some application server stuff. We 
found that one instance of silverstream would die or seriously degrade after 
60-75 people got on. They looked for all kinds of solutions, but at the end 
of the day the solution was "startup another instance of Silverstream". We 
now have 50 or so instances running 50 or so users each, with a load 
balancer deciding where new users go. All of the instances use one 
repository for their data and it works out fairly well. Sometimes it's just 
better to run 50 small programs than it is to run ONE massive program.

People are using the same strategy for ZOPE creating multiple ZEO clients 
either on a single machine or across multiple machines to provide 
scalability, failover, and reliability. I think it's a pretty proven 
strategy.

>* And finally (which makes me come across somowhat like a Troll, sorry 
>about that :-). What is the "life expectancy" of Zope? Most of the hype 
>regarding Zope seems to have died away somewhat. Recently its coming back 
>in the slipstream of Plone. But realistically, what are the chances of Zope 
>being a *relevant* application platform in a couple of years time? WIth 
>"relevant"  I mean: a platform which is well supported and keeps up with 
>the compettition on *features*, not necessarilly market share.

We reviewed many (MANY) application servers and content management systems 
over the last few years. Out of all of those systems ZOPE really stood out 
on it's own. For example, we looked at creating/purchasing a solution based 
on Vignette. The quickest we could get a solution that met our needs was 
going to be at least 6 months - we'd have to hire a TCL developer, add some 
more licensing at a few hundred thousand dollars, purchase another 'package' 
from Vignette to meet a gap in the base product, possibly purchase more 
hardware to handle the load of new users, etc.

There were a hundred more products out there just like Vignette that did 
little to nothing right out of the box and required substantial amounts of 
customization and resources to get it to where it would just work.

Then we reviewed ZOPE. ZOPE/CMF worked right out of "the box". It was 
structured in such a way that it was easy to customize and easy to add on 
additional products where there was a gap. The learning curve for 
development was relatively low. It would run on multiple platforms and 
access multiple databases. It had mature managment interfaces in place and 
worked as expected. So from a feature perspective it beat many of the other 
products out based on our particular needs. Some would say that's because it 
fills a "niche" market. I think our needs were pretty robust though and ZOPE 
has the flexibility to meet much more than we throw at it.

That was a year ago. Before that time I'd never heard of ZOPE. Even today I 
don't see much press about it or hear my colleagues talking about it, so I'm 
not sure about the "hype" part of the ZOPE equation. What I know about hype 
is that often after it dies down it's either because the product is dying or 
because the product has "settled" (meaning become accepted as a plausible 
solution to a need). ZOPE show's no signs of having died and in fact shows 
all the signs of a good living product with growing support abroad.

There are plenty of documents out there that will help you in promoting ZOPE 
as a business solution. When we evaluated it we evaluated based on 
functionality alone (I was asked to exclude price and support cost). I think 
evaluating it on those criteria first is your best bet. Then as the clincher 
include the costs involved in licensing and support.

_________________________________________________________________
online games and music with a high-speed Internet connection!  Prices start 
at less than $1 a day average.  https://broadband.msn.com (Prices may vary 
by service area.)