Lennart Regebro wrote:

From: "Raymond Norton" <ray@lctn.k12.mn.us>

...

The answer came back to use Zope. Before I spend a bunch of time on this I would like to know if this is the right tool , and how in-depth of an understanding I will need to produce such a thing.

It' probably the right tool. It almost always is. :-) Zope does have a rather steep lurning cuve, but it's worth it. Don't give up yet. :-)

From: "flynt" <flynt@gmx.ch>

...

For experimenting with databases you even have the possibilty to play with *Gadfly*, a relational test-database which comes with your Zope distribution. Gadfly does only exist in memory, nothing is written on disk and so it is a quick and good learning tool. Database adapters are available then for all major databases like PostgreSQL, MySQL, Oracle, Sybase, ODBC and so on.

Pleas note that you don't need to use any of these to make a database with Zope. Unless you need to store things in a relational database just store the data within the Zope objects, and index them with the ZCatalog. No need to impose the restrictions of relational data unelss you have to. :-)

Thanks Lennart, Your comment is a very important point one ! If you come from CGI or PHP or ASP you are always used to have to store your data either in a file or a relational database. But by working with Zope you already get a transactional object database at no additional costs (not even installing additional software on your server). And with it you get the ability to undo earlier actions, to get a history and even work for testing purposes in a protected *version* (not viewable by the public) until you decide to really publish or discard what you did in that *version*. Besides that and taking an administrators view point it is a lot easier to deal with that object database than with an additional relational database: physically on your server you have to deal with just one file (usually called fs.data in the $ZOPE_HOME/var directory). If you ever intend to test a new fancy Zope product for including in your site and want to test it on real data before installing on your production server, just get a separate Zope test instance, install your products which run on your production server, copy any *external methods* if you use any (read in the Zope Book about external methods) copy your production fs.data and start exploring and testing with real data. The learning curve is steeper than for PHP but by far not as steep as the learning curve for a Java application server framework. Nevertheless it is a full fledged application server framework that you get with Zope. And the learning is scalable: you can start easy and then move on to more complex web applications as you work on it. Starting with this year you not only can browse through all the How-To's, Tip's and mailing list archives for valuable information on various topics, but you have books on Zope. And not only one. At the moment I am aware of five books published (and two others in the pipeline) in English, French and German. Working with Zope will mean that you have to dive into Python sooner or later. But I never sensed that as learning "a specialized language". Because with Python you learn not only some kind of "web scripting language" (as you do with php) but an easy to learn, nevertheless fully object oriented language, which often is used in combination with applications written in languages like C/C++ and Java and running in critical environments like e.g. banks or insurance companies or scientific supercomputing facilities. Or you just want to use it as a scripting language at places where you usually use something like shell scripts or Perl. Python is really worth the effort. And so is Zope. Regards --- Flynt