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?
Quinn Dunkan wrote:
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?
There are a couple ways. If you are using DTML from Python, you can specify a defaults in the DocumentTemplate constructor as keyword arguments. t=DocumentTemplate.HTML("""<!--#var foo-->""",foo="bar") I believe that this is in the DTML User's Guide. If it isn't, it should be. Using the Zope framework, probably the easiest thing to do is to set default values as properties on Folders or Documents.
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.
__changed__ is part of the BoboPOS persistence machinery.
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...
I'm not up on the latest details, but Jim tells me that if ZOPE_DEBUG_MODE is set, then Documents should re-read their source files... But I don't think this answers your question.
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?
Yes, but its not currently documented. Andrew K. made a stab at documentation on his starship Zope Hacks page.
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?
Yes, DTML can generate any kind of text you want. In fact, there is no need to hack DTML to allow you to do this. -Amos
Quinn Dunkan wrote:
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, b ut 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?
There are a couple ways. If you are using DTML from Python, you can specify a defaults in the DocumentTemplate constructor as keyword arguments.
t=DocumentTemplate.HTML("""<!--#var foo-->""",foo="bar")
I believe that this is in the DTML User's Guide. If it isn't, it should be.
Using the Zope framework, probably the easiest thing to do is to set default values as properties on Folders or Documents.
Oops, either my question wasn't clear, or I'm not understanding your answer. I do know about setting #var tags via keyword arguments, that's the Main DTML Thing. What I meant was default tag _attributes_. So where I currently would have to type: <!--#var entry1 null="(not given)" --> <!--#var entry2 null="(not given)" --> <!--#var entry3 null="(dead parrot)" --> ... I could type: <!--#defaults --> <!--#var null="(not given)" --> <!--#/defaults --> <!--#var entry1 --> <!--#var entry2 --> <!--#var entry3 null="(dead parrot)" --> ... And have it come out the same. Actually, current null behaviour is hard for me to use, since the %s format will print anything successfully, and most of my entries are strings (I don't suppose there's a version of %s which doesn't automatically try to str() or repr() its argument?). Unless there is a workaround, it seems it would be usefull to have a none= attribute so that: <!--#var entry none="(not given)" --> is shorthand for: <!--#if "entry is None" --> <!--#var entry --> <!--#/if --> At least for me, this would be a more intuitive tag than null. I'll take a look at Zope Hacks to see if it includes adding tag attributes...
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 o wn 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 wa y 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_M ODE 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...
Another thing for which there isn't much documentation in Trinkets or Technical Intro is authentication (Bobo-style). Sticking a __allow_groups__ = { 'group' : {'user' : 'password' }, } __roles__ = ['group'] in the module top level and doing the usual RewriteRule apache chicanery seems to work. However, what I can't find is some way to specify the 'permission denied' page. Once again, "You are not authorized..." seems to be hard-coded in ZPublisher. Is there any way to customize this per-object? No one has written in support or contradiction of these ideas, so I don't know if I'm just missing the Right Way to do these things, or everyone is just busy. Should I submit them to the Collector? Would patches be accepted? I hesitate to go and hack DC's code when I'm not fully Zenful, but then I'd like to put some code where my mouth is, and these things would be useful to me too. And then, I'm using ZP/ZT without the Zope Framework, which perhaps brings up different issues than a "pure Zope" site.
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 unimplemente d attempt to not reread the file if its mtime is the same as before.
__changed__ is part of the BoboPOS persistence machinery.
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...
I'm not up on the latest details, but Jim tells me that if ZOPE_DEBUG_MODE is set, then Documents should re-read their source files... But I don't think this answers your question.
Hmm, not in my version (1.9.0): % grep ZOPE_DEBUG_MODE ~zope/lib/python/DocumentTemplate/*.py 1% I assume it's in 1.10. But why not have DTs reload all the time, if their mtimes have changed? The only overhead I can see would be one extra stat() syscall per request, which is not so bad. Actually, there's a good reason to not have them reload: you can edit a bunch of dtmls restart the script to have them all update at once. So maybe a flag to File/HTMLFile? Or a __dtml_reload__ setting? Once again, should I submit these things to Collector? Should I submit some sort of patch?
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?
Yes, but its not currently documented. Andrew K. made a stab at documentation on his starship Zope Hacks page.
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?
Yes, DTML can generate any kind of text you want. In fact, there is no need to hack DTML to allow you to do this.
Oops... I was referring to DTML's _input_ text. I know I can generate anything with <!--#.*? --> or %(.*?). tags, but I was wondering about whole new html tags. So I could say: <film> <title> Planet of the Evil Monster Marsh Mutant </title> <synopsis> The evil monster marsh mutant kills everyone. </synopsis> </film> Like I can say: \film{Planet of the Evil Monster Marsh Mutant}{ The evil monster marsh mutant kills everyone. } in LaTeX. I know some people have done work with plugging python's xml parsers into zope, maybe I'll take a look at that. Thanks for the pointer to Zope Hacks, though. DateTime + Y2K: DateTime chokes on dates with a year < 32. Python's decision here is: 00-68 = 2000-2068, 68-99 = 1968-1999, which is the posix recommendation. But in any case, perhaps it could raise an AmbiguousYear exception or something, or allow the user to configure where the "split" occures. Ideally we just require four-digit years, of course, but sometimes we're parsing files whose format we have no control over :) this is long enough, I'll save the rest for later :) thanks!
participants (2)
-
amos -
Quinn Dunkan