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 [EMAIL PROTECTED] http://www.mobilebox.pl
