Zope questions and comments (&Tkinter???)

[Paul Winkler]

Ron Stephens wrote:
> 1. Will Zope be too complex for me??? Specifically, if my primary
> interest, in the short run, is to be able to run server side scripts
> written in Python (or at least in a  Python-like language) , will Zope
> allow me to do this? Or will writing scripts in Zope be so complex that
> it renders void my attraction for writing in Python because it is simple
> and intuitive, i. e. , rather easy and enjoyable?

Zope is very big and complex. I find myself looking things up in
the docs all the time. I often end up grepping through the zope
source as it's faster than finding the right doc. Zope is not
nearly as intuitive and nice as just hacking away in Python. For
me, the main reasons to use Zope are:

1) The large number of freely available extensions - Zope Products
- written by other people.

2) Persistence. I was going to do my sites using CGI until I
realized what a nightmare it would be to keep track of the current
state of things for every concurrent user. Yuck. Having a
long-running robust app server that's designed to keep track of
everything is very nice.

3) Built-in user management and access restrictions.


4) Versions: you can start working in a new version, make as many
changes as you like, and no-one else will see any changes to the
site until you want them to.

5) Undo.

The first thing to learn about zope is that *everything* in Zope
goes in the Zope database, or at least hooks into it; you can
browse the system's management interface through the web, and it
*looks* like you're looking at a filesystem, but that's a
metaphor. To write Python scripts in Zope, you either:

1) add a PythonScript object - this is code that lives in the zope
database, has security restrictions on which modules can be
imported, and is editable through the web.

2) add an External Method - this is python code that lives on the
filesystem, is not editable through the web, and has no
restrictions on what it can do.

3) Write a Product. This is suitable for bigger, more complex
things, and it's more work; the best way to learn how to do it is
to look up the Boring product on zope.org, download that, and
customize it.

The biggest problems with Zope for me:

1) Documentation is disorganized, and I haven't found a good
overview from a python programmer's POV. It took me a couple
months of playing with it before it "clicked" for me. The Zope
Book (search for it on zope.org) helps a lot, it's a good intro.

2) DTML, the most common zope page template language, sucks. It's
basically html with a few extra tags to let you access variables,
loop over lists, etc. It's fine and easy for very simple things,
but inevitably you need a bit of python logic in there and things
quickly get ugly and very confusing: the interfaces between dtml,
python, and the zope namespaces are a real snake farm. There is a
project to improve this, based on XML, called Page Templates or
something like that (search for TAL on python.org). I think it's
included with the latest versions of zope. I haven't had time to
learn it yet, docs and examples are still pretty sparse.

> 2. I have already discovered that the gui type input/output functions of
> my scripts are the hardest part for me. I am only interested in simple
> input and output by end users, but I want it to look good and be user
> friendly. I do not need fancy graphics nor multimedia, just well
> designed attractive forms and user input followed by outputed results in
> verbal and numerical form. Will this kind of input/output be a big
> problem using Zope? I almost don't dare ask, but I assume Tkinter will
> not be supported by Zope?

Supported how? You want to run tkinter on the client side? They'd
have to have tkinter installed - not likely.

 Will I really need to resort to other means,
> such as JavaScript, to do such things ??? How straight forward is input
> and output, in event driven programs, in server side scripting using
> Zope???

Zope basically works in the CGI paradigm - you make forms using
DTML, you click submit, it does something with the result. If you
can't in principle do what you want with CGI, then it won't work
with zope either. If you really want event-driven stuff, I suspect
java (maybe with JPython) or javascript are the only options that
will have any chance of working for most web browsers.

> 3. Would I be better served by using CGI, once I find a host that allows
> me to do so? If CGI scripts written in Python are just as easy and
> flexible as using Zope, maybe that's the way for me to go in the
> beginning. I will still need to find a Python CGI friendly host company.
> 
> 4. Any suggestions on host companies for Python and/or Zope?

I like hurrah. You can mix-and-match zope with any flavor of cgi
and php and mysql and so forth. Very responsive to email, unlike
the previous place I hosted, codeit.com. Cheaper too.
 
> 5. I do have an always-on cable modem connection in my home. Should I
> consider setting up a very simple web server on my own machine (rather
> than finding a Zope Host?). If I could set up such a simple server,
> allowing me to run server side Python scripts, or even CGI, I could link
> to those pages from my other web site, on my non-Python non-CGI friendly
> web host site.

You could. But how reliable is your cable modem? How secure is
your box? Does it matter to you?
 
> 6. Is Zope simply so complex that I will soon forget about why I enjoy
> Python, i. e., intuitive, easy to use fun coding?

I often feel that way. It's all due to DTML. Yuck. 
But I have been able to do a lot with zope.

--PW