Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Filter_Localize / Zend_Filter_Normalize Component Proposal

Proposed Component Name Zend_Filter_Localize / Zend_Filter_Normalize
Developer Notes / Zend_Filter_Normalize
Proposers Thomas Weidner
Zend Liaison Matthew Weier O'Phinney
Revision 1.0 - 24 January 2009: Initial Draft. (wiki revision: 7)

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


Normalize given input to english notation
Autodetect the given valuetype
Uses the application wide locale as locale to use (de in this case)


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


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. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 25, 2009

    <p>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.</p>

  2. Jan 25, 2009

    <p>Zend_View_Helper_Localize would be also useful, so everyone won't need to write it themselves.</p>

    1. Jan 26, 2009

      <p>Without the related filter the view helper does not make any sense.<br />
      Therefor I have not proposed it for now.</p>

      <p>First the filters have to be done/accepted and then we can do further simplifications like a view helper. <ac:emoticon ac:name="wink" /></p>

  3. Jan 26, 2009

    <p>Nice. Thanks Thomas.<br />
    I also agree with Martin that View_Helper would be useful. </p>

  4. Jan 26, 2009

    <p>Great idea! I hate dealing with localization/normalization every time, especially with currencies...</p>

  5. Jan 27, 2009

    <p>Yep, something like that is definitely missing in Zend Framework at the moment...</p>

    <p>As as side node:<br />
    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).</p>

    <p>The idea behind input and output filters is to make everything looking nice to the user, while not having to deal with localization + "beautification".</p>

    <p>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.</p>

    <p>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.</p>

    <p>I hope I'm finding some time to write a proposal, if someone's interested...</p>

    1. Jan 27, 2009

      <p>The advantage of this proposal is that filter are not only used with Form.<br />
      Filters are a generic way which can/could also be used with other components.</p>

      <p>The question you have to answer yourself is</p>
      <li>if your feature can be solved within this proposal, then it's useless</li>
      <li>if your feature can partitially be solved by this proposal, then you should look that things are not duplicated</li>
      <li>if your feature is something completly different... then write a proposal</li>

      1. Jan 27, 2009

        <p>> The advantage of this proposal is that filter are not only used with Form.<br />
        > Filters are a generic way which can/could also be used with other components.</p>

        <p>I completely understand that and the way how filters are working... <ac:emoticon ac:name="smile" /></p>

        <p>The point is that there's unfortunately no <strong>automatic</strong> 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.</p>

        <p>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?<br />
        Actually, all is needed therefore are input/output filters in Zend_Form_Element (or pre/post or whatever you call them).</p>

  6. Mar 27, 2009

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Acceptance</ac:parameter><ac:rich-text-body>
    <p>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:</p>
    <li>Zend_Filter_Normalize should become Zend_Filter_LocalizedToNormalized</li>
    <li>Zend_Filter_Localize should become Zend_Filter_NormalizedToLocalized</li>