[Zope-dev] DocumentTemplate packaging suggestion

[Alexander Staubo]

>-----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_