You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, say we have a text field that is used to store float numbers and our application is in french (yes, it's my native language :). In database, it is stored as float, like 4112.156. In a french notation, this number should appear as 4 112,156.
In that case, if you want to do things the right way you expect the user to enter numbers in a french notation. So you add an input filter and a validator in your form like this:
This input filter specification verifies that the user is entering a number in the french notation. For example, if he tries to enter 4112.156, it will be rejected.
If the user enters 4 112,156, the value will be accepted, then parsed to a float and finally saved in database as a real float type 4112.156.
Good!
Now the user want to modify this value and opens the form again. When the form will be populated by the database row, the field value will be written in the native float notation.
Using the original formRow view helper, as the field is filled with a native float notation, when the user will try to submit the form again without any modification, it will be rejected because the value is 4112.156 and the form expects 4 112,156.
No way!
As suggested there, can you see my issue neilime/zf2-twb-bundle#144 where I offer a solution to this problem. I think a similar mechanism should be included in zf2 in order to avoid adding 5 lines of code for each i18n related fields as soon as an application is multi-lingual.
Wouldn't it be more convenient to let a hydrator strategy format the number according to a given locale?
Say you want to display the data as plain html before populating a form you'd also want it to show up in a localized format. Now you'd have to filter the value in two different places.
My dumb question will be, how will someone handle multiple languages? For example, sites which have multi versions. How will they handle this situation which you've proposed? Thanks!
Description of the problem:
For example, say we have a text field that is used to store float numbers and our application is in french (yes, it's my native language :). In database, it is stored as float, like
4112.156
. In a french notation, this number should appear as4 112,156
.In that case, if you want to do things the right way you expect the user to enter numbers in a french notation. So you add an input filter and a validator in your form like this:
This input filter specification verifies that the user is entering a number in the french notation. For example, if he tries to enter
4112.156
, it will be rejected.If the user enters
4 112,156
, the value will be accepted, then parsed to a float and finally saved in database as a real float type4112.156
.Good!
Now the user want to modify this value and opens the form again. When the form will be populated by the database row, the field value will be written in the native float notation.
Using the original formRow view helper, as the field is filled with a native float notation, when the user will try to submit the form again without any modification, it will be rejected because the value is
4112.156
and the form expects4 112,156
.No way!
As suggested there, can you see my issue neilime/zf2-twb-bundle#144 where I offer a solution to this problem. I think a similar mechanism should be included in zf2 in order to avoid adding 5 lines of code for each i18n related fields as soon as an application is multi-lingual.
Thank you.
Originally posted by @berturion at zendframework/zend-form#10
The text was updated successfully, but these errors were encountered: