Namespaces for Filters and Validators

Hy all,

I added a new feature for Zend_Filter and Zend_Validate.

As you may know you can use Zend_Filter, and also Zend_Validate, in a statical way.
When using them static, you have to give the namespaces where your own filters can be found. Otherwise it recognises only the delivered filters from Zend.

Zend_Filter::get('123abd', 'Tokenize', array(), array('My/Path', 'My/Module/Path'));

As you may imagine this can get complicated when you are using multiple self designed filters or multiple namespaces.

Now you can set default namespaces which will be used within the whole application.

Zend_Filter::setDefaultNamespaces(array('My/Path', 'My/Module/Path'));
Zend_Filter::get('123abd', 'Tokenize');
Zend_Filter::get('other123'), 'Digits');

The usage is now much simpler as you can set the namespaces once within your bootstrap or application.
Available methods are:

* setDefaultNamespaces
* addDefaultNamespaces
* getDefaultNamespaces
* hasDefaultNamespaces

The same methods are available for Zend_Validate.

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top

Zend_Validate and their returned messages

Actually I am working on several improvements to Zend_Validate.
Not only the new proposals I’ve added but also features to existing classes.
Since today one of the new features is approved and added to core.

What it is about?

When working with validators you will get messages when a validation has failed.
The content of these messages can be very large as some of them also output given values in the returned message. This can lead to a problem when the returned message has a length which you have not expected.

You will for example expect that any given failure message you want to render has a maximum length of 256 chars. So when the returned message length is 400 chars your view will look broken.

Zend_Validate allows now to limit the returned size of a message.


Now any validation message which exceeds 256 chars will be reduced to exactly 256 chars and rendered like this:

This is a long message but it is truncated here...

Of course there is also a getMessageLength() method to get the actual set size.
And as you already noted that this a static method. You can call it from your bootstrap and it will be used by all validation classes.

I hope you find this new feature usefull :-)

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top

New ideas for the next ZF releases

I added some new proposals for which I had the ideas as I worked at the CLDR integration.
Some other new features and ideas will be added as feature enhancement and don’t need a proposal as they cover existing components.

* Zend_Validate_PostCode

A proposal for a new validator I added today. It is able to validate postal codes for all countries. Of course you could say that someone can also use the regex validator to provide this feature. But this would be hard as most people don’t know the correct regex strings and when you need to validate multiple countries (a webshop for several countries for example) such a validator would be much easier to use.

* Zend_Validate_Phone

A proposal for a new validator which will be able to validate if the given input is a phone number or not. Note that phone numbers are differently for each country, and in their notation. A number in an international format (+43 1 234567) does not match with a national number (01 234567). This validator will be able to check all of these different formats

* Zend_View_Helper_Date

A proposal for a new view helper which will simplify the rendering and usage of Zend_Date objects within a view.

* Translateable exceptions

The idea behind this proposal is that sometimes you need to translate exceptions. For example when you want to have your log in a language which your customer understands (many customers don’t understand english). But this proposal can also be used to change the message which an exception throws. This can be used to change the exception for example from “No database connection to MYDB” to “Db Problems… please ask your DBAdmin” which would also be a better way than retrowing the exception.

* Zend_Filter_Boolean

This filter will make it possible to change user input into a boolean value. Now you may say that you could simply cast to a boolean, but this filter does more than that. It will/can detect “yes”, “no” written in any language and change it to boolean. Maybe even the textual strings “true” and “false”.

* Zend_Filter_StringLength

This proposal describes a filter which will be able to do all work which changes the length of a string. This is not only stripping but also padding within the same filter. having both into the same filter has some advantage as you can define a minimum and a maximum string length.

* Zend_Validate_Callback

This will be a very neat validator. It is simply a callback which allows to use any self defined function or method to be usedas validator. It works nearly the same way as Zend_Filter_Callback.

* Zend_View_Helper_Currency

This proposal describes a view helper which will simplify the usage of currencies within a view. It makes use of Zend_Currency.

* Zend_Filter_Compress

This is the only proposal of all above mentioned which is already accepted. It will add compression and decompression support to ZF. Originally only intended for files it will at last also support string compression.

There are also some issues which are not big enough to be written as proposal but which implement features which will be very nice for most users.

* Zend_Currency improvements

I plan some improvements for Zend_Currency. These are a interface for exchange services. Note that Zend_Currency itself is not able to change between currencies… for example when you want ot know how much USD a EUR value is. Another improvement will be that Zend_Currency will then be able to calculate currencies. These two features are related to each other.

* Zend_Locale improvements

CLDR 1.7 added locale upgrading. Zend_Locale will implement this feature. This allows to get “en” from your user and then have “en_US” at the end without interaction. This works for all languages but is, of course, limited to the territories with the most speakers of this language. Zend_Locale itself already supports 3-letter locales which have not been supported in past. Additionally Zend_Locale accepts now also locales with additional informations. For example a locale like “en-Latn-Transnat-US” would be accepted and internally changed to “en_US”.

I have much more ideas than time to work on them :-)
Many of them can also be found within our wiki.

If you want me to work on some of these ideas faster then on others feel free to give your comments on the proposals and to vote for issues.

Thomas Weidner
I18N Team Leader, Zend Framework

Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework

Back to top