cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@apache.org>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Mon, 15 Nov 2004 21:09:43 GMT
Daniel Fagerstrom wrote:
>> Wouldn't it be easier to just throw an exception if the correct type of
>> convertor couldn't be found. The fallback convertor probably wouldn't be
>> what the page author had in mind anyway. Regarding locale fallback,
>> shouldn't this be up to the convertors themselves as only they know if
>> they are locale sensitive. In the example above the DefaultDateConvertor
>> can handle any locale whereas the CustomDateConvertor should throw an
>> exception if there is no pattern for the locale or alternatively use a
>> default pattern.
> 
> 
> Locale fallback is IMHO a necesity. For type I don't know, from the CSS 
> class analogy we should have it, but that is just an analogy and can be 
> missleading. Use cases are needed to decide. Leszek and Ralph you had 
> lots of opinions earlier in this thread, what do you say?

I am not familiar with CForms' convertors implementation details. So 
just abstract thoughts:

1. Locale fallback is a must - with the behaviour similar to i18n - are 
we able to reuse that mechanism?
2. I do not really see a usecase for type fallback. There could be two 
various problems that could cause fallback:
   * an exception in best matched convertor - would default convertor be 
any better?
   * no such type: I see it rather as configuration's problem. 
${date#shrot} - is that something that counts for a default convertor?
If type fallback is to be implemented I think it has to be supported by 
some kind of leniency setting (you may want you view to throw exceptions 
in case of spelling errors and not perform fallback).

-- 
Leszek Gawron                                                 MobileBox
lgawron@apache.org                              http://www.mobilebox.pl

Mime
View raw message