cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
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                    

View raw message