Zend Framework: Zend_Filter_Localize / Zend_Filter_Normalize Component Proposal
| Proposed Component Name | Zend_Filter_Localize / Zend_Filter_Normalize |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Filter_Localize / Zend_Filter_Normalize |
| Proposers | Thomas Weidner |
| Zend Liaison | Matthew Weier O'Phinney |
| Revision | 1.0 - 24 January 2009: Initial Draft. (wiki revision: 6) |
Table of Contents
1. Overview
Zend_Filter_Localize and it's cousine Zend_Filter_Normalize are filters for localizing / normalizing input.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- Zend_Filter_Localize will localize given normalized input to a user locale
- Zend_Filter_Normalize will normalize given localized user input to a normalized notation
- Both components will ONLY handle numbers, integer, float and dates
- This components will not automatically translate any content as f.e. cities, daynames and so on
4. Dependencies on Other Framework Components
- Zend_Exception
- Zend_Locale
5. Theory of Operation
Zend_Filter_Localize and Zend_Filter_Normalize are nearly related but will act reverse from each other.
Zend_Filter_Normalize acts as normalization filter and converts any given localized input from a user
into a normalized representation. So a user can for example give '1.234,50' and the filter will return
the normalized representation '1234.50' with which the application can do further processing, like storing
into a database. This allows multilingual applications to work internally with a fixed representation and
still allows users to provide localized inputs.
Zend_Filter_Localize works the same way as Zend_Filter_Normalize but reversed. It converts a normalized value
into a localized representation. So, for example, a normalized '1234.50' input from a database can be
displayed to the user in a localized representation and he would get '1.234,50'.
Both components make use of Zend_Locale_Format and are able to work with:
- Numbers
- Integers
- Real Point Values (Floats without scientific notation)
- Dates
- Times
- Currencies
Both components WILL NOT do any translations like daynames, monthnames, cities and so on.
6. Milestones / Tasks
- Milestone 1: [DONE] Proposal finished
- Milestone 2: [DONE] Proposal accepted
- Milestone 3: [DONE] Working implementation
- Milestone 4: [DONE] Unit tests
- Milestone 5: [DONE] Documentation
- Milestone 6: [DONE] Moved to core
7. Class Index
- Zend_Filter_Localize
- Zend_Filter_Normalize
8. Use Cases
| UC-01 |
|---|
Normalize given input to english notation
Autodetect the given valuetype
Uses the application wide locale as locale to use (de in this case)
| UC-02 |
|---|
Normalize the given input to english notation
Input is fixed to date, which does not autodetect
Uses the locale 'de' as defined
of course also array notation is supported
| UC-03 |
|---|
Localizes a normal input to a localized notation
Autodetect the given valuetype
Uses the application wide locale as locale to use (de in this case)
9 Comments
comments.show.hideJan 25, 2009
Jan Pieper
Nice idea. I've already searched for such a functionality. This will help us to allow all valid notations we get from user input without defining a specific notation.
Jan 25, 2009
Martin Hujer
Zend_View_Helper_Localize would be also useful, so everyone won't need to write it themselves.
Jan 26, 2009
Thomas Weidner
Without the related filter the view helper does not make any sense.
Therefor I have not proposed it for now.
First the filters have to be done/accepted and then we can do further simplifications like a view helper.
Jan 26, 2009
Micha? Zieli?ski
Nice. Thanks Thomas.
I also agree with Martin that View_Helper would be useful.
Jan 26, 2009
M.Ozan Hazer
Great idea! I hate dealing with localization/normalization every time, especially with currencies...
Jan 27, 2009
Moritz Mertinkat
Yep, something like that is definitely missing in Zend Framework at the moment...
As as side node:
I've made a patch for Zend_Form_Element (against 1.7.3-PL1) which heads towards this direction, allowing to specify input (something like your proposed Zend_Filter_Localize) and output filters (Zend_Filter_Normalize).
The idea behind input and output filters is to make everything looking nice to the user, while not having to deal with localization + "beautification".
Example: Your database (or whatever storage) stores dates in ISO format, but you'd like to display a well-formatted localized date format in your date text box (and validate against this format). When the user presses the submit button, you need the ISO formatted date again.
Now, with the patch (which does not break any of the ZF unit tests) you could simply populate the form with your raw/normalized database content and on successful validation you get back values which are formatted according to this raw/normalized database content.
I hope I'm finding some time to write a proposal, if someone's interested...
Jan 27, 2009
Thomas Weidner
The advantage of this proposal is that filter are not only used with Form.
Filters are a generic way which can/could also be used with other components.
The question you have to answer yourself is
Jan 27, 2009
Moritz Mertinkat
> The advantage of this proposal is that filter are not only used with Form.
> Filters are a generic way which can/could also be used with other components.
I completely understand that and the way how filters are working...
The point is that there's unfortunately no automatic way in using your proposed filters with Zend_Form. That means, you have to apply Zend_Filter_Localize first, then Zend_Form::populate/setDefaults. After the form has been successfully validated, you would use Zend_Form::getValues and Zend_Filter_Normalize.
Wouldn't it be great, just to add a "date" element which automatically applies your Zend_Filter_Localize before rendering and validating and Zend_Filter_Normalize after successful validation?
Actually, all is needed therefore are input/output filters in Zend_Form_Element (or pre/post or whatever you call them).
Mar 27, 2009
Matthew Weier O'Phinney
This proposal is accepted for immediate development in the standard incubator. We would like to see the filter names changed, however, to better describe their purpose, and require the following: