ZF-8130: Rendering filters

Description

Hi,

Along with missing post-validation filters, which i understand that is postponed for 2.0 there are other kind of filters which are actually missing.

I am mentioning "rendering filters". What i mean by this ? Let's give you a sample:

Let's suppose we have a form with works with mixed kind of numeric values: a) id's or phone numbers or other kind of numbers which doesn't have a localized version, just a normalized version b) amounts (money, quantities, whatever) which have both a localized version and a normalized version.

The mode is going to store of course, the normalized version of the data.

But, the form should rather render the values into localized version, as: 13,454 and not 13456 Of course, before the validation (or after validation with post validation filters which are to come) we can actually filter the input given from the form so we validate and get back the normalized version, instead of localized version.

So, what we are missing now there are filters so we convert the data before rendering into an appropriate format. In my sample, to convert from a normalized version to a localized version.

I don't think there is a "standard" way of doing this now, for values, and we gonna use for now just workarounds, ad make new view helpers, overwrite setDefaults aso.

So please if possible consider if we don't actually need those kind of filters...

Comments

Actually, "post rendering" would be considered something for the view layer, and should either be done via view helpers operating on the values directly, or decorators. At this point, there is plenty of infrastructure already for this.

A ton of localization view helpers have been added in the last few releases that address this request already.

Actually, "post rendering" would be considered something for the view layer, and should either be done via view helpers operating on the values directly, or decorators. At this point, there is plenty of infrastructure already for this.

I am a bit confused, in my simple sample what view helper should be used from the "ton of localization view helpers" ?

Actually, sorry, I misspoke: there's a ton of localization filters that have been added. Since filters may be invoked trivially from within a view script, there's little reason to add helpers for them:


<?php echo Zend_Filter::filterStatic($this->someValue, 'NormalizedToLocalized') ?>

The point is that the filters contained in Zend_Form are considered normalization filters -- filters that transform a value to a common format for purpose of data storage and/or validation (the classic example is filtering a phone number for only digits prior to doing a validation on it). Typically you store normalized -- not localized -- data in your data store. Normalization is an activity of the model.

Post-filtering, as requested, has to do with output, and I'd argue that tasks specific to output of a value -- unless they are necessary to form display -- should be relegated to the output layer. Localization is certainly one of these areas, as the localized version of a value will vary between users and requests.

Thanks Matthew for clarification.

However, i may not explained very good the idea.

I was not talking about post-filtering. I am talking about form rendering filters - necessary to display the form... Not to display the data from the storage layer...

Let's suppose we have this scenario: - I want to creare one form with one select element, the multioptions been possible dates into a localized format - Now, without rendering filters, the dates are rendered on the form with a normalized format now, unless i do some pre-processing after getting the data on the model

Other scenario: - I want to create a form with a input text, with a certain amount, displayed localized (123,456.67) - Since model of course that contains a normalized format, now my only way to display a localized formal (as above) would be to do some pre-processing, or maybe use MySQL localization facilities (which is think is bad idea, because is basically moving the computing for output layer into model!!!)

So, i would argue that: - filtering the data provided to the form is also needed, not just the filtering the data at validation, or after validation (this been proposed for 2.0). - This filtering could be logically done on form, not on controller or model...

One more case, this approach looks logical i think: - a field into the model has the one date stored as timestamp - i get the record from the model - i populate the form with the record data - at rendering the RENDERING FILTER is transforming the date to a localized format: mm/dd//yyyy or so and it displays into the text field the date into this format - user is making the adjustements to the data (including date) and it saves the form - before validation, we are filtering using some NORMAL (current filters of Zend_Form) filters, let's say for StripTags, Trim, aso - validation is checking that the data is into mm/dd//yyyy format - after validation, the NEW FILTERS PROPOSED FOR 2.0 are changing the data back to timestamp, from mm/dd//yyyy format - the data is saved to the model

So i think is logical that we need 3 types of filters: - rendering filter - pre-validation filter (existing filters) - post-validation filters (proposed for 2.0)

Filters are filters... for the filter itself there should be no change if it's being used pre-validation or post-validation. It's still the same filter. How it works just depends on the used parameters.

What we need is a way to define when the filter has to be processed.

Yes, correct.

Just would be nice to have added some ways to run filters at different points into all the Form processing.