Friday, June 26, 2009
By thomasw at 19:33:21
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.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Saturday, June 20, 2009
By thomasw at 01:04:56
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.
Zend_Validate::setMessageLength(256);
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 :-)
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Sunday, June 7, 2009
By thomasw at 22:38:12
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.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Wednesday, May 20, 2009
By thomasw at 01:17:34
Today I updated the locale database to the latest release (CLDR 1.7) which is available since 2 weeks by unicode. It provides several corrections for existing locale informations.
Corrected currency signs, additional locales, additional timezone data and much more. This update changes about 5MB of data and is only provided within trunk. It will be available to ZF with the next minor release 1.9.
Additional new informations are provided by CLDR like
* postalcodes
* phonecodes
* locale upgrading
and several more.
This new informations will be integrated within ZF soon.
See http://framework.zend.com/issues/browse/ZF-6681 for informations about new features to be integrated.
Please note, that like in past Zend (and me) is not allowed to provide changed CLDR files. When you find a error you have to possibilities.
* Anyone who finds an error can keep it private
* Or feel free to write a issue to unicode (unicode.org/cldr) about incorrect informations
I hope you find it usefull
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Friday, April 17, 2009
By thomasw at 23:40:12
Sometimes you have to work with user-provided numbers or dates.
The problem with this data is, that when your users are using different locales, then you will have to normalize and localize the provided data to be able to work with them.
In past you had to convert the data manually or by using Zend_Locale.
$values = $form->getValues();
$values['firstnumber'] = Zend_Locale::getInteger($values['number']);
$values['secondnumber'] = Zend_Locale::getInteger($values['number']);
With Zend Framework 1.8 I added a filter which does this for you. Simply add the filter to your form
$element = new Zend_Form_Element_Text('firstnumber');
$element->addFilter('LocalizedToNormalized');
This filter can handle
* Numbers like Integer, Float, Real
* Dates
* Times
Numbers will be returned as string in the english/computer notation.
Dates and Times will be returned as array where every date part is seperated to a own key.
The german number 12.345,67
would become 12345.67
This comes handy, for example, when you want to store the provided data within a database because you should always use a normalized representation when you work with multiple locales.
Of course I added also a filter which does the reverse task… to localize a normalized value.
Let’s expect we have a normalized value from a internal source. To display it in a localized manner simply use Zend_Filter_NormalizedToLocalized.
$filter = new Zend_Filter_NormalizedToLocalized();
$date = array(
'day' => 3,
'month' => 10,
'year' => 2009
);
print $filter->filter($date);
The benefits of this components are, that they can be used within every other component which allows the usage of filters. And both detect the type of the given value automatically. Of course this filter provides als several parameters which enables you to tweak what the components return. For details about the parameters take a look into the manual.
I hope you find them usefull.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
By thomasw at 01:44:02
How to receive a file from Zend_Form_Element_File is often a difficult question.
When you have problems you should read below to get an idea of the handling and to prevent possible problems:
Let’s expect our form has a file element like this one:
$element = new Zend_Form_Element_File('file');
$element->setDestination('/MyDir');
In past, before ZF 1.8, when you wanted to get the uploaded file you had to call receive() afterwards like this…
if ($form->isValid($this->getPost())) {
if (!$element->file->receive()) {
print_r($element->file->getMessages());
}
}
Now many people said, and I think they were right, that it would be a great idea to get the file when calling getValues(). So we added this new feature for ZF 1.8.
This means that that with ZF 1.8 this call is enough:
$values = $form->getValues();
Your file is already transferred… no need to call received afterwards.
But sometime it is wished to call received manually. You could, for example, wish to add a own filter based on a value which you get from your form. So calling getValues() now would mean that you can not add a filter afterwards… as the file is already transferred.
But also for this usecase a solution has been added. You can set a flag to the file element which prevents that the file itself will be received when you call getValues().
Take a look at the following file element:
$element = new Zend_Form_Element_File('file');
$element->setDestination('/MyDir')
->setValueDisabled(true);
Note the added call of setValueDiabled(). It tells the file element that it should not receive the file when you call getValues().
Now you can call getValues() and the file will not be received in the background. But this means, of course, that you have to call receive() manually. Otherwise your file will not be available after the script has been finished.
$values = $form->getValues();
if ($form->isValid($this->getPost())) {
$element->file->addFilter('Rename', false, 'Filename_'.$values['id']);
if (!$element->file->receive()) {
print_r($element->file->getMessages());
}
}
Remember, to have this working you need to call setValueDisabled() otherwise the file is transferred when calling getValues(). When you omit the call then your file will be transferred, due to getValues(), but it will not be renamed, because the rename filter was not available at the time, the file has been received.
Note, that using a filename based on a user input is always a security issue. Use a autoincremented number from your database for example, or be sure that you validate the user input before using it as new filename.
You should also note that I did not use another instance of Zend_File_Transfer…
The file element itself has already a instance available. When you really need to have the instance itself, then use getTransferAdapter() instead of creating a new instance. This is faster, uses less ressources and prevents possible problems with files already being transferred by the other instance.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Tuesday, March 24, 2009
By thomasw at 00:30:27
In the past week I took over all issues for Zend_Validate and it’s subcomponents.
Most of them have not been touched or done since several months, so I am taking care of them in the future.
The first validator I’ve reviewed and reworked is Zend_Validate_Hostname.
New features for this newly reworked validator within trunk are:
* Supports additionally 76 IDN’s
* Supports now Multi-IDN TLDs like ORG or PL… these are TLDs which support multiple scripts
* Supports now length check for IDN’s as many IDN’s define a different limit than 64 characters.
Even if I added 76 new IDN’s to the existing 8 IDN’s there still not all actual possible TLD’s have been added.
The most common are COM and NET, but also countryIDN’s like CN or JP have to be added in future.
But, with the actual change 4 existing feature requests weere already be integrated.
I will keep you informed about new features as always, when you’ve registered to my blog. ;-)
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Tuesday, March 3, 2009
By thomasw at 23:03:22
Sometimes it is necessary to show the progress for files which a user actually uploads to a site.
With the next release 1.8 the Zend Framework supports a very easy and simple way to provide the user with all wished data.
There are some prerequisits:
You must have installed and activated eighter the APC or UploadProgress extension.
You should use Zend_Form_File_Element, otherwise the needed hidden fields will not be attached.
So let’s expect you have already created the form and the controller to handle the upload itself.
To show your user the progress of his file upload you need to have an iframe or another different process beside the upload itself which shows it’s result to the user. The server part looks like this:
$adapter = new Zend_ProgressBar_Adapter_Console();
$upload = Zend_File_Transfer_Adapter_Http::getProgress($adapter);
while (!$upload['done']) {
$upload = Zend_File_Transfer_Adapter_Http:getProgress($upload);
}
There is only one thing you have to do:
* Create the wished ProgressBar adapter and give it to Zend_File_Transfer_Adapter_Http::getProgress()
All other things are done in background by this static method. You don’t need to create the form, or a file adapter. Simply call this static method.
In return your ProgressBar adapter will be updated and will show you the new progress for this upload.
However you realize your view, there are different methods to do so, you have to give the output of Zend_File_Transfer_Adapter_Http::getProgress() as input to the next call of this method.
It was never simpler to get the upload progress and show it to a user.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Saturday, February 21, 2009
By thomasw at 12:04:30
In past the handling of untranslated messages within Zend_Translate was somewhat unhandy.
You had to check if the message can be translated or not, and then you had to notify yourself somehow. This leaded mainly to self written view helpers or an own class as middleware which did this job for you.
So I began thinking and found a really nice solution for you guys which was integrated yesterday.
Think of a site with a huge amount of pages. For simplification you have created the translation sources yourself. You choosed cvs for example. Now your site grows from day to day. Several people are working on it. Of course, depending on the size of the site and how pedantic your helpers are, you would have forgotten to add some messages to the translation files.
For the visitors of your site it seems like you’ve overlooked things and the site seems unfinished and unprofessional because languages are mixed.
There is now a solution to this problem:
Logging
You can define that Zend_Translate should write messages which can not be translated into a log. This does even work with your existing code. You just have to add 3 lines. Let’s get into practice:
First, create a log instance:
$writer = new Zend_Log_Writer_Stream('/path/mylog.log');
$log = new Zend_Log($writer);
Then attach it to Zend_Translate:
$t = new Zend_Translate('csv', $path);
$t->setOptions(
array('log' => $log,
'logUntranslated' => true));
Additionally we activated logging for messages with the option logUntranslated.
That’s it. From now on, when a message has to be translated and there is no translation found, you will have a log entry which reads Untranslated message: My requested message. Now all you have to do is to check your log regulary and look if there are any untranslated messages.
Better than before, but with this feature you can do even more.
Now you have to add this new translations manually to a translation source file. But Zend_Log could do this for you when you want to invest some lines of code.
All you have to do is to write your own extension of a Zend_Log_Writer. Your Log_Writer instance has to handle the source format you want to use. Strip the leading “Untranslated message: ” from the thrown notice and then write the new message to the file.
As short example:
My_Csv_Log_Writer extends Zend_Log_Writer_Stream
{
protected function write($event)
{
$event = substr($event, 22);
return parent::write($event . ”;\n”);
}
}
This just strips out the leading untranslated stuff and add a separator and a new line to the file.
Of course, for a real working implementation this is not enough.
You would have to create a log writer for the source format you want to use. But it should show you how simple a new log writer can be.
As always this new feature is available with the next release which is ZF 1.8 or when you use trunk.
I hope you love this new feature. ;-)
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
Friday, February 20, 2009
By thomasw at 20:43:13
Hy fellows,
when you are validating Input with Zend_Validate_Date then you can now use the Date constants as validation format. This allows you to validate against localized formats even when you don’t know how the format looks like.
As example:
In past you had to know the format or evaluate it from Zend_Locale like shown:
$locale = 'de';
$format = Zend_Locale::getTranslation('date', array('gregorian', 'medium'), $locale);
$valid = new Zend_Validate_Date($format, $locale);
Now you can simply use the constants from Zend_Date to simplify the validation:
$valid = new Zend_Validate_Date(Zend_Date::DATE_MEDIUM, 'de');
This works with all available date constants.
Also Zend_Date itself can now handle the format constants within the methods which did not support it. You can use them within isDate() which, until now, only accepted fixed ISO format. And you can use them also within the toString() method.
$date = new Zend_Date($myinput);
print $date->toString(Zend_Date::RSS);
While adding this new features I also did some rework of Zend_Date itself. It is now about 200 lines reduced without change to the functionallity. And the parsing is faster than in past.
As always, this new feature is available with the next minor release which will be 1.8.
Greetings
Thomas Weidner
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
