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