[Pangloss] [RFC] OpenFrame AppKit ideas

[Steve Purkis]

On Wednesday, April 9, 2003, at 11:22  am, Jean-Michel Hiver wrote:

>> 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.
>
> Which we usually do for accessibility reasons. Screen readers are
> apparently much easier when all the errors are read out first, which
> means that they should all be at the beginning.

Fair enough, then as a worst-case scenario you have to do something 
like:

	if errors
		if some_error ...
		if some_other_error ...
		...
	end


>> 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 surely if your errors are using templates then they can be 
> localized
> too.
>
> The motive for embedding error presentation into error objects is that
> 'some_error' might happen in 5 different templates, in which case 
> you'll
> end up having the error string 'An Evil Error has occurred!' 5 times.

Which is a bit much, I agree.  But there's nothing to stop the template 
writer from defining an error template for recurring errors, and 
including it.



>>> 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.
>
> I think it's best to have a reasonable, localized default (hence error
> objects using templates) that you can override if you need anyway.

I disagree - how can you have a default for errors as varied as 
'database down' and 'name not present'.


> That being said I understand that you have a problem with tying errors
> to HTML. Maybe you could use a bridge pattern to dissociate the 'error'
> bit from the 'html' bit?

What, like:

	sub Some::Error::as_xhtml {
		my $self = shift;
		Locale::Error::HTML->as_xhtml($self);
	}

Or something else?

-Steve