-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]On Behalf Of Phillip J. Eby Sent: 3. juli 1999 14:34 To: zope-dev@zope.org Subject: [Zope-dev] DocumentTemplate packaging suggestion
Now that all of Zope is Open Source, might it make sense to move the tree tag and sql* tags to the DocumentTemplate package, since they don't really require the rest of Zope, and make useful additions to DocumentTemplate in its own right? It seems to me that adding them as dynamically loaded tags would enhance the value of the DocumentTemplate package. The sendmail tag of course wouldn't make sense because it requires a MailHost object, but the other tags do not require any ZInfrastructure besides DocumentTemplate. Right now, I have to surgically excise the .py files from the Zope distribution and find some reasonable place in my ZPublished code to import them, and then repeat the process whenever either Zope or DocumentTemplates are updated.
Although it could be argued that the sql* tags shouldn't be in the "core" package, if they're dynamically loaded it doesn't affect much. In fact, they're quite useful there, as I've occasionally found the need to call regular DTML from SQL methods in order to break up big queries into smaller chunks or to share common code between multiple queries.
While I'm on the subject of DocumentTemplates, a seperate and entirely unrelated suggestion that would be a lot more difficult than the one above, but might perhaps be more relevant for Zope's core audience of content developers... A Zope newbie I was helping the other day found the message "KeyError" to be hopelessly confusing, when what they'd done was misspelled a variable name. Perhaps certain exceptions should be re-formatted by the DTMLDoc/DTMLMethod classes so that Zope displays more meaningful messages like "Unrecognized name: foo", instead of the weird public-traceback + hidden error data combo.
No implications of imbecility intended, but you can do this by customizing standard_error_message. The DTML of the default message method actually gives a nice example of how it can be tweaked: <P>Troubleshooting Suggestions</P> <UL> <!--#if "error_type in ('KeyError','NameError')"--> <LI>This resource may be trying to reference a nonexistent object or variable <STRONG><!--#var error_value--></STRONG>.</LI> <!--#/if--> <LI>The URL may be incorrect.</LI> <LI>The parameters passed to this resource may be incorrect.</LI> <LI>A resource that this resource relies on may be encountering an error.</LI> </UL> What annoys me more about error messages is that the whole error reporting thing is quite lacking: - Sometimes it just goes "(See above)", and sometimes the "Error Value" just says "Sorry, an error occurred". It would have been a lot neater if it could point out the exact part of the DTML that caused problems, which I realize is difficult due to the compiled nature of DTML, but that's not my concern. ;-) - Furthermore the traceback "lies" when dealing with External Methods: The correct Python error is never revealed, perhaps for security reasons. - And I wish, very dearly, that I could insert the traceback _as part of the HTML_. Right now Zope just adds the traceback to the end of the HTML, out of sight. For an excellent example of how dynamic error reporting should be done, check out MySQL. Or was that mSQL? Damn! Anyway, it -- whichever it is -- gives a very lucid, even aesthetically pleasing, error report, worthy of imitation. -- Alexander Staubo http://www.mop.no/~alex/ "What the hell, he thought, you're only young once, and threw himself out of the window. That would at least keep the element of surprise on his side." --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_