[Zope] newbie question (repost)

[Amos Latteier]

At 12:58 AM 2/1/99 -0800, Quinn Dunkan  wrote:
>I posted this a while ago, but recieved no response, so I assume it either
>didn't make it, or everyone hates me.

I hope you don't seriously think this. As you are no doubt aware, this list
gets a lot of traffic. If you are looking to get your questions answered
quickly I would suggest trying to ask them as clearly and precisely as
possible. Of course, feel free to ignore this advice ;-)

>Well, I'm actually using Bobo right now, but this should be applicable to
>ZPublisher (here's a question: I understand that bobo users are encouraged to
>switch to ZPublisher... are there any "issues" to be aware of?  Is there a
>document that describes how one might make such a switch as painless as
>possible?

Well, there aren't many issues outside the obvious one: The code has been
reorganized. ZPublisher is packagized, while cgi_module_publisher and
CGIResponse weren't. Also, ZPublisher breaks more of the publishing
functionality apart into different modules, and brings the debugger, and
the rpc client into the package.

The organization of the ZPublisher package is described at:

http://www.zope.org/Documentation/Reference/ZPublisher

The rules that ZPublisher follows to publish a module are the same as
always. In the change log you can find out about the small changes--like
the addition of BOBO_DEBUG_MODE.

The main interface to ZPublisher is still the publish_module function, so
where your code used to read

from cgi_module_publisher import publish_module

just change that to

from ZPublisher import publish_module

And if you want your code to work with both old and new libraries you might
wrap the import in a try except clause so that you can fall back on
cgi_module_publisher if ZPublisher is not available.

So to summarize: There are few changes from the point of view of the
publisher module. From the point of view of the publisher (ie your fast cgi
publisher) you need to grab the publish_module function from a new place.

>I'd like to use ZTemplate for cDocumentTemplate, but I'd probably
>have to use ExtensionClass with that.  I suppose that's as easy as sticking
>the .so in my $PYTHONPATH and putting an import ExtensionClass in ZTemplate's
>__init__.py?). 

Actually it's easier. Just download the binary distribution of Zope and
copy the lib/python/DocumentTemplate package to somewhere in your Python
path. If there's no binary distribution for your platform, get the Zope
source distribution, run the install script, which will compile the
necessary c extensions for you. Then copy lib/python/DocumentTemplate as
before. Feel free to throw out the rest of the Zope ;-) 

>Anyway, I've been messing around with Bobo for a while now,
>and have a few questions:
>
>I have a few email forms that I want a method to pretty up and send to the
>appropriate person.  Here's how I'm doing it now, but I know there's a Right
>Way that involves dtml and all that.  I await enlightenment, RTFM, etc.
>How I did it (after finding out about REQUEST), was to write a
>mail(form_name, REQUEST) function that looks for a function named form_name
>and passes it REQUEST.form, then mails the string returned.  form_name is
>communicated via a hidden <input> in each form.  Ok, so this all seems
>fairly zope-zenful, but my prettification functions seem to be asking for
>dtml or something.
>
>My current approach is to say:
>def mr_form(a):
>    msg = untab("""\
>        %(name)s
>        %(email)s
>        %(comments)s
>    """)
>    
>    return msg % MsgDict(a)
>
>Where MsgDict wraps a dictionary except returns "fieldname: value" when it
>finds the value and "fieldname: (not given)" when it doesn't.  Now this
>doesn't work when things get marginally more complicated, so if I want
>an address printed out right, and not like
>
>address: 123 road
>city: centerville (a great place to raise your kids up)
>state: etc.
>
>I did this:
>def mr_form(a):
>    msg = untab("""\
>        %(name)s
>        Address:
>            %(adress)s
>            %(city)s, %(state)s %(zip code)s
>    """)
>
>    dict = {}
>    for i in "address", "city", "state", "zip code", "country":
>        if dict.has_key(i):
>            dict[i] = dict[i]
>        else:
>            dict[i] = "(no %s given)" % i
>
>    return format(msg % UnionDict(dict, MsgDict(a)))
>
>which is worse yet, but works.  UnionDict overlays dictionaries by looking in
>each one successively, and format() breaks lines over 70 columns.
>
>Ok, so what's the right way to do this?

I'm not sure. What specifically is wrong with your current method? If you
are doing a lot of testing and text munging, I would guess that it would be
easier to do in Python (as you are doing it) than in DTML.

>I may seem stupid for recreating all
>sorts of functionality that may already exist in dtml, but I read and read
and
>read the docs and source-code (even the howto on zope.org for "Creating a
Mail
>Form", but it assumed I was using full-fledged zope, which I'm not (I'm just
>the cgi programmer, I can't switch the whole site to zope even if I'd like
>to)).  I imagine there are a lot of people in my situation who aren't
>designing a brand new site from scratch but would still like to use
>ZPublisher/ZTemplate without all the other stuff.  I think it would be useful
>to have a clearly marked portion of the docs that say "These pertain to
>ZP/ZT-only sites."  The stuff in "Zope Developer Information" (basically the
>old bobo docs) would be good there, perhaps with less scary names.  I think
>it's great that zope components can be used seperately.

There are many items in the Developer information area which are relevant
to people who are using the components separately. For example, there is a
section labeled 'Component and Package Documentation' on the main developer
reference page:

http://www.zope.org/Documentation/Reference

which includes documentation of many topics including Acquisition, the
ZPublisher package, Structured Text, ZopeHTTPServer, etc.

Also, the trinkets tutorial, and the 'Technical Introduction to Object
Publishing' tutorial are both relevant for people who want to use Zope
components separately.

So I think that material is available, but I guess we need to do a better
job organizing, labeling, and explaining it.

>Here's another question:  I know dtml supports both html-comment-like and
python
>string-like syntax, but everyone seems to use the html-comment.  I prefer
python
>syntax since it looks less cluttered to me (and I think it's a good thing
that
>my dtmls don't resemble ssi)...  is there any particular reason to use one
>over the other, or is it purely personal preference?  (And why does everyone
>seem to prefer the (ugly, IMHO) html-comment syntax?)

I would guess that most people use it because they use DTML to write HTML,
and it seems more natural in this context.

>Also, my thought regarding the "dtml tags look like html comments so it's
hard
>to write them in html editors" discussion is why not use python-string
syntax?
>It has no relation to xml, but dtml is really sort of a meta-language anyway,
>isn't it?  And at least no editor is going to mistake a python-string for
>html or xml.

Good point.

>One of the things Bobo/ZPublisher touts is the ease of using things like
pcgi,
>fcgi, etc.  I've been using fcgi, but I wasn't able to find a cgi-template
>style script for it, so I wrote my own.  Granted, it was trivial (provided I
>did it right), but it would still be nice if it was included, or the
>documentation said where I could download it.

How about contributing your fcgi publisher or some documentation of it and
a link?

>Actually, it's not being that trivial.  The problem I'm having with fcgi is
>that scripts are persistant, like pcgi.  That means when you fix a bug you
have
>to restart the script before it shows up.  Which is a problem when the script
>is run by the httpd server and you have no permission to send signals to it.
>Perhaps I'm once again missing the obvious solution that must be there, but I
>had my fcgi-module-publisher look for a file with the same name as the script
>in a "semaphores" directory, and exit when it sees that.  Ugly, but it works.

One more general purpose way of handling shutting down is to include a
published method which shuts down python, for example:

def shutdown():
  "should require authorization to call this"
  raise SystemExit

>I'm investigating zope proper, but I have trouble finding where the content
>actually _is_! 

As you may have heard, Zope uses an object database, and so the content is
all stored in a database file in the var directory.

>I guess it's all pickled in the var directory and in various
>dtml / python source lying around, but I'm much more comfortable editing
>python and dtml with vim than filling out web forms / downloading stuff
>developed off-line.  I guess ZServer's ftp server ought to make this a bit
>nicer, but I thought a nifty solution would be to write zope as a filesystem
>server

Well, writing the Zope FTP server is kind of like doing this, but only in a
cross platform way ;-)

-Amos