Once I wrote about redirecting with Zend Framework, but what I missed back than was a common mistake. Although the code from my post is working, to be completely correct after redirecting I’d to add an exit() statement.
This is important because the header is changed and if something goes after the redirect there will be some problems. Finally the correct snippet is:
public function() { $this->_redirect('some_url'); exit(); } |
This is nothing useful, but let me show the beauty of jQuery. This snippet just adds more and more nodes on a simple UL based tree.
Here’s the HTML:
<ul> <li><a href="#">Node 1</a></li> <li><a href="#">Node 2</a></li> <li><a href="#">Node 3</a></li> <li><a href="#">Node 4</a></li> </ul> |
And that’s the jQuery:
var index = 5; $('li > a').live('click', function() { $(this).parent().append('<ul><li><a href="#">Node ' + index + '</a></li></ul>'); index++; return false; }); |
And here’s the demo.
As you may know in PHP you can access everything in the request uri by accessing the global $_GET array. If there is something like that in the browser’s address field: www.example.com/index.php?controller=index&action=test, you can simply get the values by that:
echo $_GET['controller']; // this will print "index" echo $_GET['action']; // this will print "test" |
If you code with Zend Framework, you should know already, and that’s perhaps the first thing you’ve learned about Zend, that $_GET params can be accessed by calling the requrest’s getParam() method. But first of all the request uri will be different. The Zend’s convetion is to place after the domain name first the module name (which is omited when there’s only one module), than the controller’s name followed by the action and the key value pairs of all parameters. In that scheme the request uri above will look like that:
http://www.example.com/index/test |
Here the keywords “controller” and “action” are omitted. This is cool – it’s more user friendly and it definitely helps the SEO.
Once the uri is setup like so – /index/test you can access it via the Zend way:
echo $this->getRequest()->getParam('controller'); // this will print "index" |
The cool thing is that in the first case you don’t have any prevention of a missing value, while in the second case there is a second parameter or the getParam() method that does this job. What if the uri is www.example.com/index.php?controller=&action=test than by printing the $_GET[‘controller’] you’ll get nothing. In other hand even this:
echo $this->getRequest()->getParam('action'); |
won’t return “test” if the uri is http://www.example.com/index/
Note: actually here the default “index” action will be referenced!
That’s where the power of the framework comes. In the first case the solution is:
echo (empty($_GET['controller']) ? 'default': $_GET['controller']); |
while in Zend there’s more elegant solution:
echo $this->getRequest()->getParam('action', 'test'); |
Thus when the action param is missing the “test” value is considered as default! Very useful!
There are some really good reasons to use Zend_Translate for your multilingual site instead of some other technique. Actually you can definitely simulate something like this Zend component with and array or ini file, but here are some good things to mention.
In fact you can do this even without Zend_Translate. Image you’ve an ini file with some pairs like:
lblMyLabel = "My Label"
Nobody says this cannot be “more” human readable – like so:
My Label = "My Label"
Than you can support several files i.e. en.ini, de.ini, etc. where you can translate this label. The problem is that once you read the ini file you’ve to deal with those white spaces into the labels, while with Zend_Translate you can simply call them with:
$translate->_("My Label"); |
Zend_Translate forces you to define a source file. Which is really great, because you always have a default value. Assuming that you don’t have a specific label translated in one of the ini files, you’ll get the default value from the source file, and defining source and other files is as easy as:
// en.ini My Label = "My Label" // de.ini ... // while the locale is de_DE you'll have // the default value returned $translate->_("My Label"); // will return My Label from the en.ini |
It’s really great that you can directly setup a locale for this module. Thus you have more flexibility when switching between languages and you can benefit from the power of the framework when reading some browser specific locales. Here’s some code:
$translate = new Zend_Translate('ini', 'en.ini', 'en'); $translate->addTranslation('de.ini', 'de'); // than when you setup the translation locale $translate->setLocale('en'); |
One of the greatest things about Zend_Translate is the native support of cache. It’s so cool! Actually the labels of a large web system are pretty static and don’t change every day. In other hand in large scale systems there are lots of labels, and the load time will be faster with cache.
$frontendOptions = array('lifetime' => 600, 'automatic_serialization' => true); $backendOptions = array('cache_dir' => 'path_to_cache_dir'); $cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions); Zend_Translate::setCache($cache); |
It’s a great advantage to use Zend_Translate after all this. Actually I have finished projects without any use of it, but I really can’t imagine how I’ll work now without it!
Let’s assume there’s a little, simple JavaScript array:
var a = [3,2,4,5,2,4,5,8]; |
If you pop() an element from it – what element will be taken? The answer is a bit frustrating, but logical – the last one:
var b = a.pop(); alert(b); // this will result in 8 |