There's thing that bothers me is when using Zend_Dojo_Form_Element_CurrencyTextBox with currency set to, let's say 'PLN': it's displaying value with all advantages of dijit.form.currencytextbox, but this dojo element actually returns not-localized, plain float to form field.

What makes the problem is Zend_Validate_Float, which is using Zend_Locale. When it receives float string, not number, it does not recognize it as dotted float is not compliant with Polish locale.

Reproduction: 1. Set CurrencyTextBox 'value' to 12.34 and 'currency' to 'PLN' (locale: 'pl' or 'pl_PL'). 2. While displaying dijit.form.currencytextbox it displays locale-aware value ('pl_PL' - 12,34), but input holds '12.34' and that value is POSTed 3. Zend_Validate_Float gets string '12.34' and does not recognizes it as float, then tries to use Zend_Locale_Format::isFloat($value, array('locale' => $this->_locale)) - but fails to recognize, because value returned from dijit has dot instead of comma.

I had to create my custom float validator that is exact copy of Zend_Validate_Float but has one more check between is_float() and try{} section - if (is_string($value) && is_numeric($value)) - but that is not elegant way, isn't it?

Solution suggested by Thomas Weidner was to set English locale just for Zend_Validate_Float, but it is good solution only when you know that client browser has javascript enabled, but what if somebody needs it working in both situations? If javascript is disabled, dijit won't convert it to English locale, and there will be message: '12,34' does not appear to be a float.

So still, possible solutions are:

1. find out how to force dijit to return localized value and make Zend_Dojo_Form_Element_CurrencyTextBox to do that (if Zend_Locale is enabled and Zend_Validate_Float is in use, otherwise it will be ok)

2. use is_numeric() in Zend_Validate_Float() after is_float() and before Zend_Locale_Format::isFloat() - not elegant way, might pass not only floats, but does not break app