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 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: 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

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

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

9 Comments

comments.show.hide

  1. Jan 25, 2009

    Jan Pieper

    <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

    Martin Hujer

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

    1. Jan 26, 2009

      Thomas Weidner

      <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

    Micha? Zieli?ski

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

  4. Jan 26, 2009

    M.Ozan Hazer

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

  5. Jan 27, 2009

    Moritz Mertinkat

    <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

      Thomas Weidner

      <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>
      <ul>
      <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>
      </ul>

      1. Jan 27, 2009

        Moritz Mertinkat

        <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

    Matthew Weier O'Phinney

    <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>
    <ul>
    <li>Zend_Filter_Normalize should become Zend_Filter_LocalizedToNormalized</li>
    <li>Zend_Filter_Localize should become Zend_Filter_NormalizedToLocalized</li>
    </ul>
    </ac:rich-text-body></ac:macro>