Edit-time Error Handling¶
Here is a proposal for dealing with TAL errors in saved templates.
A Presentation Designer is creating or editing a template, not through the Zope Management Inferface, but through client software like GoLive or Dreamweaver.
The HTML file saved to Zope may have METAL/TAL syntax errors. Such a file is no longer a valid TAL template. However, the file is most likely okay HTML (as verified by the client software). What do we do when the saved file is broken?
- Refusing to save the file (WebDAV or FTP PUT error) is very misleading. There is no consistent way to send back the intent of the rejection, so the user thinks that Zope is broken.
- Silently ignoring the error means bad pages. Bad pages mean bad sites. Bad sites mean bad press.
- The Presentation Designer has a workflow. TAL is already disruptive enough to the workflow. In addition, using ZPT is also a change in the way things are done. The potential for more errors will cause the designer to question how useful doing templates and Zope is to begin with.
- The ZPT management interface can do fancy logging and presentation of the TAL syntax errors but a Presentation Designer may not want to leave his/her neat little GoLive world to wrangle with HTML forms (and the synchronization problem that editing in two places can introduce).
- The workflow of the PresentationDesigner must be minimally impacted
- by the adoption of ZPT. In particular, TAL syntax errors will constantly remind the designer that they are working in a new paradigm. A paradigm not seamlessly supported by their HTML editing tool.
Mark the saved page as broken. When the page is rendered through a browser (from Zope), it should display detailed information (an error log) about what is wrong.
In addition, embed the error log in the original page. This way, the next time the page is loaded into the editor, the error will be evident. The designer will need to adopt a new process in which he reloads a page from Zope (through WebDAV or FTP) in order to make sure that a saved page has no errors.
A page with an error should contain a block of comments (after the DOCTYPE, XML declaration or the first place where a comment is legal) with text containing representing the error log, presented in such a manner that it is very clear that something is wrong. The log should be as verbose as necessary to point out exactly where the error occurs, the nature of the error and, perhaps, hints about how to fix it.
21march2001 - This has been reworked to address some of the concerns raised by Comments #1, #2 and #3*