[Pangloss] [RFC] OpenFrame AppKit ideas

[Steve Purkis]

On Tuesday, April 8, 2003, at 08:57  pm, Jean-Michel Hiver wrote:

>> I was thinking of using try/catch blocks from the Error module.  But 
>> both would achieve the same ends.
>
> The exception mechanism does not work when you're validating a form 
> because you do not want a validation error to be fatal since you might 
> want to report multiple errors.

True, but in that case I wouldn't use exceptions - I'd bung the errors 
into the ErrorCatcher manually.


>> I like your idea of passing the error object to the template, but I'd 
>> change the name from 'self' to 'error'.  So I guess I got it wrong in 
>> saying the TemplateLoader should copy across all the error vars using 
>> the 'error.' prefix..
>> Also, instead of things like 'as_xhtml()', I prefer limiting the 
>> errors to simple flags that the template writer uses to decide what 
>> text to write:
>>     'error.name_required'    => $flag
>
> I find it really nice to have an as_xhtml() method coupled with 
> templates for your error because then you don't need to do a bunch of 
> ifs in your template. I thought that was what polymorphism was all 
> about - avoid pesky ifs and switch-like statements.

I'm not sure if a bunch of conditionals in the template are a bad thing 
- its presentation logic, so that's the right place for it.  Still, if 
you want to display all the errors at the beginning of a page then yes, 
it gets annoying.  Which is why I would choose not to do it that way.

Another point, the major difference between:

     <li petal:content="structure some_error/as_xhtml">
       An Evil Error has occurred!
     </li>

and:

     <li petal:if="some_error">
       An Evil Error has occurred!
     </li>

isn't the if statement, it's where the error string comes from: the 
error object, or the template.  I'd prefer to keep the string in the 
template where it's easily localized (in context too).


> But I also like the idea of your error having an ID for each error so 
> that you can override the way the error is presented if you want to...
>
> I suppose as a rule of thumb you could have ID = template name. Then 
> your errors would be templatable, potentially easily multi-lingual, 
> but also overridable. Although I doubt very much that you'll have to 
> change them very often. After all 'Not enough disk space' remains 'not 
> enough disk space'... If not, it's probably another kind of error. Am 
> I making any sense?

I'm not sure I understand the advantage of this...  Yes, you can have 
application-wide errors, but you probably don't want to tie them to an 
individual error template.  Unless you include that template when the 
error pops up, but that should be done at the template level anyways.

-Steve