For the best user experience, it's useful to post sometimes a html <form> with an asynchronous request. The javascript acquires the data, sends it to the server and waits for a response. But when the form contains errors, you need to return the messages in order to be displayed for the user.
This article provides a strategy to fetch the response, looks if the form contained errors and display the errors just like the errors would be displayed when you used the errors decorator of Zend_Form.
The Zend_Form has support for hidden elements, Zend_Form_Element_Hidden. In default setup they are rendered in a <dt><dd> wrapper and this can raise some problems when applying styles to the form.
This blog article suggests a new idea to solve this problem. On the Internet many proposals are posted with all some drawbacks, which are solved in this idea.
Nowadays a lot of effort is made to have support for Doctrine in the Zend Framework. Doctrine is a great tool and having the support for all Doctrine specialities (code generations, migrations and behaviours like i18n and versionable) is a must for all real developers. Searching the Internet about a variety of topics, I think I found now the perfect method to have Doctrine loaded all your models.
Yesterday I received the book "Zend Framework 1.8: Web Application Development" for reviewing. It's written by Keith Pope and the publisher, Packt Publishing contacted my with the question if I'd like to review the book and place a summary at my blog. Well, of course I'd like to do that.
In the upcoming weeks I have my exams, so there won't be much time for reviewing. After this week I'm able to read the book thoroughly and write my review. Others are already done with the review, but nethertheless I'm happy to do it. Want a copy of the book yourself, you can order it online at Packt.
We developers like to make it our users as easy as possible to use the Soflomo system. The content management system is meant to serve any kind of user, so also those who don't understand the principles of resizing image for better and faster displaying.
Therefore an automated resize script is a necessary tool to have inside the system. A user can point to an image to display it on its website by using a common image dialog, but different pages requires different image sizes for e.g. a blog or portfolio item. It's too difficult for them to upload multiple resized images for all the use cases, so uploading the original, largest image must be enough.
At Soflomo we have constructed such a tool inside the Sofzo, the Soflomo framework. It's useful for our clients, but also front end webdevelopers might have some benefits from using the image processor. Yes, I'm talking now of an image processor and not a simple resize tool anymore. Sometimes you need a square crop of your image. Sometimes you need a bit more sharpening because the image is getting blurry. And that's not the work of an image resizer, it has become a real processor.