Page 1 of 1
Handling decimal separators - Wiki article
#1
Posted 23 January 2012 - 01:12 AM
Yii i18n does not cover decimal format. Some languages like Spanish (I live in Argentina) uses comma ',' instead of dot '.' as decimal separator.
A localized web app should:
1- Display decimal values with the local decimal separator.
2- Allow entering decimal values with the local decimal separator.
I posted a wiki article explaining a procedure to get it done. Wiki article
Please add your comments, suggestions, etc, here.
A localized web app should:
1- Display decimal values with the local decimal separator.
2- Allow entering decimal values with the local decimal separator.
I posted a wiki article explaining a procedure to get it done. Wiki article
Please add your comments, suggestions, etc, here.
#2
Posted 23 January 2012 - 03:07 AM
Why not just using a custom formatter class? It would format values for display changing the separator and if you define static methods you can filter input. I've done that and it works like a charm. I'm storing decimal values (currency) with a fixed precision as integers (multiplied by 100) but one can store them in any float format.
Storing proper values in models also helps when doing any calculations.
Filtering this way helps validation anyway, since you can remove common typos before validation (or not).
BTW I'm doing the same with dates, filtering with date('Y-m-d',strtotime($date)) to allow almost any input format, not just Y-m-d that the DB requires.
Storing proper values in models also helps when doing any calculations.
Filtering this way helps validation anyway, since you can remove common typos before validation (or not).
BTW I'm doing the same with dates, filtering with date('Y-m-d',strtotime($date)) to allow almost any input format, not just Y-m-d that the DB requires.
Don't be a dick.
#3
Posted 23 January 2012 - 09:18 AM
Yes, a custom formatter class will work, but you need to declare the class in each grid, each form, etc. The CHtml override take care of the conversion system wide. Your application code will not change at all.
I'm curious, why are you storing decimal values as integer instead of DECIMAL?
I'm curious, why are you storing decimal values as integer instead of DECIMAL?
#4
Posted 23 January 2012 - 09:45 AM
jpablo, on 23 January 2012 - 09:18 AM, said:
Yes, a custom formatter class will work, but you need to declare the class in each grid, each form, etc.
Nope. You can just register your custom formatter in your config in the components-stanza. Gridviews, detailviews etc. will pick it up automatically
programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
#5
Posted 23 January 2012 - 04:01 PM
jpablo, on 23 January 2012 - 09:18 AM, said:
I'm curious, why are you storing decimal values as integer instead of DECIMAL?
I always considered such formats as an unnecessary hassle. AFAIR I've never needed it for anything other than monetary values with a fixed scale of 2. Easy to remember, no need to write it down in a schema definition.
Following the PostgreSQL manual (sorry for no link, it looks I'm too new here):
Quote
The type numeric can store numbers with up to 1000 digits of precision and perform calculations exactly. It is especially recommended for storing monetary amounts and other quantities where exactness is required. However, arithmetic on numeric values is very slow compared to the integer types, or to the floating-point types described in the next section.
I'm not saying it's wrong in any way, just my preference. Using decimals would hint any generators using db schema how to build validation rules, but it's not much effort to correct that by hand, especially if I do it once in a project lifetime. And I like to know where/when/how rounding happens when doing some calculations on user input.
A little digression - recently I learned that ROUND function in a popular spreadsheet software works different in cell expressions than in it's macro language. And I learned it the hard way - by debugging.
Don't be a dick.
#6
Posted 23 January 2012 - 04:15 PM
I understand your point of view on storing decimals in integer fields. I don't share it, but I understand it =)
Round and decimal precision is a hassle many times in many languages. Javascript, for example, just SUCKS handling decimal precision. Just try this:
Javascript will show 16229.499999999998 instead of 16229.5 !!! So, be warned, handling decimal values in javascript is not safe at all. In fact, it's dangerous.
nineinchnick, on 23 January 2012 - 04:01 PM, said:
A little digression - recently I learned that ROUND function in a popular spreadsheet software works different in cell expressions than in it's macro language. And I learned it the hard way - by debugging.
Round and decimal precision is a hassle many times in many languages. Javascript, for example, just SUCKS handling decimal precision. Just try this:
Quote
num = 162.295;
num *= 100;
alert(num);
num *= 100;
alert(num);
Javascript will show 16229.499999999998 instead of 16229.5 !!! So, be warned, handling decimal values in javascript is not safe at all. In fact, it's dangerous.
#8
Posted 20 November 2012 - 03:32 AM
Hi
I have problem with :
foreach($this->owner->getTableSchema()->columns as $name => $column)
owner not exist, and after, the gii fail with :
Missing argument 1 for ModelCode::getTableSchema(), called in D:\Proyectos\tuDulceTarta\web\commonend\helpers\CHtml.php on line 2168 and defined
I have problem with :
foreach($this->owner->getTableSchema()->columns as $name => $column)
owner not exist, and after, the gii fail with :
Missing argument 1 for ModelCode::getTableSchema(), called in D:\Proyectos\tuDulceTarta\web\commonend\helpers\CHtml.php on line 2168 and defined
Miguel
Recursos Formacion
Recursos Formacion
Share this topic:
Page 1 of 1

Help













