[Zope] default dtml attrs, exception handling

Fri, 19 Feb 1999 18:50:39 -0800

Zope vs. Python 1.5.2b1:  apparently something has changed in what 1.5.2b1
does with threads.  Upon upgrading, I got "C API version mismatch" warnings,
so I went to lib/python to recompile everything, at which point ThreadLock.c
revolted when it couldn't figure out what a type_lock was.  type_lock is
defined in <python1.5/thread.h>, but not in <python1.5/pythread.h>, and
ThreadLock.c was including pythread.h (given that PyList_SET_ITEM was
defined).  I have no idea what the distinction is between the two, and what
PyList_SET_ITEM means, but I had it include thread.h instead and everything
worked fine...

Is there a way to specify default dtml tag arguments?  I have a bit of dtml
that renders a database entry.  Currently I fill null values from python, but
I'd like to be able to specify them from dtml.  Unfortunately that seems to
mean putting a null= tag on every single #var, and changing them all when I
change one.  Is there a way you could put something like:

<!--#defaults -->
    <!--#var null="(not given)" -->
<!--#/defaults -->

at the top of your document to accomplish that?  Or is there some other way
I'm missing?

A suggestion for exception handling:
Currently, it appears that exceptions are caught and handled by a Response
object.  It has hard-coded responses to exceptions, but you can make your own
error pages by making your own exception with a __str__ method that returns
text that contains "<html>".  As far as I can tell, though, there is no way to
replace the generic exception handler (so that if os.stat throws os.error (or
OSError, they changed it in 1.5.2b1 (stop it, guys!)) you get something of
your choosing rather than "Sorry, an error occurred."  Also, there is no way
to decide per-exception how to handle tracebacks.  Even if you just want to
raise a "invalid search string" FormError exception, you still spew a
meaningless traceback at the user.  It can be hidden if you unset Z_DEBUG_MODE
or __bobo_hide_tracebacks__ = 1, but then what if you want "real" errors to
spew a traceback?

Currently, I do stuff like:

error_doc = HTMLFile('error.dtml')

class BoboError(Exception):
    title = "Generic Error"
    def __init__(self, msg):
        self.msg = msg
    def __str__(self):
        return error_doc(self)

and then subclass BoboError.  Unfortunately, I can't figure out how to hide
tracebacks...

I also have two questions re dtml: From my reading of
DT_String.FileMixin.read_raw, the source file is reread every time the dtml is
cook()ed, which is only the first time it is __called__.  There is some
mucking around with a __changed__ method, which I assume is an unimplemented
attempt to not reread the file if its mtime is the same as before.  Is
__changed__ supposed to del self.cooked?  What's going on here?
Rereading dtmls is desirable so I don't have to restart pcgis just because the
dtml changed...

Speaking of which, of course the suggested shutdown() method works fine, I was
thinking fuzzily when I said it didn't apply.  Now I just write a little
script that tickles shutdown methods with proper authentication, etc.
Perhaps, if the script exits with 0, pcgi-wrapper should just silently restart
it in the background instead of complaining and restarting it on the next
request?  You'd just get a "Program exited with code 0, restarting..." instead
of a panicked SERIOUS APPLICATION ERROR from bobo (but then I guess we'd lose
messages from scripts that died with 0 on accident... but does that ever
happen?).

The second question:
I've seen references to the ability to create your own dtml tags, but no
mention in the DTML docs on how to do that.  Is this possible?  If so, where
can I read about it?  I'd actually like to create my own html tags, so I can
use DT as a generic html/whatever generator, at least until I can do it in
XML.  Does this seem reasonable?