Tag Archives: zend framework

Force Zend Casting and Help the IDE Autocompletion

IDEs and Autocompletion

One of my favorite things in IDEs, in my case Eclipse for Mac, is that they offer you the option of autocompletion. No developer knows the entire set of functions of the language he uses, neither the set of parameters of them. That’s why IDEs come to help.

In many cases when casting is not obvious and method call chain is to large your IDE may refuse to help you with this brilliant functionality. To be more precise let me give you an example.

In Zend Framework I was trying to fetch a RSS via Gdata interface. Something like that:

$videoFeed = $gdata->getUserUploads('youtube_username');
foreach ($videoFeed as $entry) {
    // do something
}

The problem is that whenever I try to do $entry-> in the body of the foreach loop I don’t see what methods are supported by the Zend_Gdata_YouTube_VideoEntry class. So I tried to force the casting of $entry to this class definition and it worked like a charm for me. The thing I’ve done was to add a definition of $entry before the loop body:

$videoFeed = $gdata->getUserUploads('youtube_username');
$entry = new Zend_Gdata_YouTube_VideoEntry();
foreach  ($videoFeed as $entry) {
    // do something
}

Than whenever you try to type $entry-> you’d receive a list of methods from the class definition of Zend_Gdata_YouTube_VideoEntry.

Thanks to Roy Ganor there’s a more elegant way to do this, simply by adding @var comment:

/* @var $entry Zend_Gdata_YouTube_VideoEntry */

Manage JavaScript and CSS includes within Zend Framework application

How to include JavaScript and CSS files?

In Zend Framework there is a very elegant way to include CSS and JavaScript. Because in one single view of any action you cannot include a JavaScript or CSS because they wont be executed from the browser, you can simply use a helper.

You can see the original source of how that’s done here. And in breve you can include a JS file like so:

<? $this->headScript()->appendFile('/media/js/global.js') ?>

but where the problem is?

As a very good PHP point of view, there is really that way to include JS into the application. But a PHP point of view is not a JavaScript point of view so this solution is not the best one.

As almost everybody knows JavaScript blocks other content until it’s loaded and executed from the server and nowadays the most popular way to include JS is just before the closing <body> tag.

That’s why the ZF solution is not optimal. What we actually need as both PHP and JavaScript developers is a most robust solution!

Cool tutorial about Zend_Paginator

Every part of Zend Framework is indeed very profesional and useful. But as it happens often some modules are less used than others. Don’t know why but my feeling is that Zend_Paginator, a wonderful tool for pagination is really misunderstood. And in fact it does one of the most common web development tasks. It builds the abstraction for a component that everybody uses in a web project – pagination.

It make sense if there where more tutorials like the following one describing its usage! Many thanks to Joey Rivera for a great tutorial about Zend_Paginator.

Even more this tutorials goes behind the pure usage of the paginator but it helps you understand the integration with one of the most used web apps today – Twitter and another Zend Framework component – Zend_Cache.

joey rivera blog

Escaping strings in a Zend Framework view. Prevent unclosed tags!

In most of the tutorials about Zend Framework the simple theory is described how all these MVC things may work together. However beyond that the things become more and more tricky and not everything is done by the MVC pattern itself.

What I mean is that reading most of the tutorials about ZF I found describing the simple relationship between controllers and views just by setting up a view member variable in the controller and than simply call that variable in the view of that particular controller action.

Setup controller’s view variable. In this example I used the default ZF IndexController – indexAction:

public IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->greeting = ‘Hello World!’;
    }
}

where afterwards you can call this member variable in the index.phtml view in the index view scripts.

Note: In a typical Zend Framework installation all this is setup into the application folder (either web visible or not), where the IndexController.php file containing the code above is placed into the application/controllers and its indexAction stores its view in the application/views/scripts/index/index.phtml

In that situation the view file, the previously mentioned index.phtml should access this “greeting” variable in something like:

<div><?php echo $this->greeting ?></div>

Note that here you miss the ->view-> part of the chain. That’s because the view’s parsed and now this contains everything that the controller’s view member object contains.

All that is pretty cool and it works great until you start accessing and working with different type of data escaped or not, coming from various sources.

Natively comes the problem of escaping bad strings and the single question is why should I do that? To give you a simple example I’ll describe the above code in a different manner.

Imagine you should setup a browser specific title depending of the controller/action you call. To do that is simple but there comes the tricky part. In the example above we can just change the code a bit.

In the controller you can setup the browserTitle variable:

<?php
class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->browserTitle = “Welcome”;
    }
}

Than normally in the view you may have something like that:

<html>
<head>
<title><?php echo $this->browserTitle ?></title>
...

Everything until that looks normal and you don’t need to escape whatever as it appears. Even if the browserTitle contains something with quotes:

...
$this->view->browserTitle = ‘Hello ”World”’;
...

This will result in the browser’s source view as:

...
<title>Hello “World”</title>
...

see the image below:


But what if you setup a meta title tag:

<meta name=”title” content=”Hello “World”” />

for the browser that’s an error as shown on the image:

There’s why you simply should be careful when dumping variables all over the page and to use the native ZF escape function.

$this->escape()

In the example above you simply can call the escape function into the view:

<html>
<head>
<title><?php echo $this->browserTitle ?></title>
<meta name=”title” content=”<?php echo $this->escape($this->browserTitle) ?>” />

That will prevent the browser to “crash” and of course and more important will improve the site’s SEO.

Theory of caching. Zend_Cache & Zend Optimizer.

Although it may sound strange I’ll say why I’m using caching. Because it speeds up the site! Yeah there’s no other reason that may be so important as this is.

The caching is not a process invented in the last year, it’s useless to describe why do you need it, but however my intention is to describe how to make it work with Zend Framework.

The docs page of Zend_Cache is pretty clear about everything and I’ll describe the most important part of the cache setup.

First setup the cache back and frontend options. You need to decide where to save the cache files, how to cache them, and what lifetime do they need.

The most used cache configuration is, as you may guess, this one described into the doc page. Setup the front and backend options is just as simple as:

$frontendOptions = array(
     'lifetime' => 7200, // cache lifetime of 2 hours
     'automatic_serialization' => true
);

$backendOptions = array(
   'cache_dir' => './tmp/'
   // Directory where to put the cache files
);

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core',
                             'File',
                              $frontendOptions,
                              $backendOptions);

Because all this is well described into the doc page, which you can found here I won’t talk about it. But I’ll talk only about one sole thing. How much the cache must live? What should be its lifetime.

The answer is simple. If you have some basic statistic of your site traffic and you don’t change much the data you can prefer longer cache period. But imagine the site’s making 1000 visits per minute! Than even if you cache every minute and the cache expires every minute will be a success and the user perception will be really great. From those 1000 visitors only few will wait until the cache’s built and the other hundreds will receive really fast response!

Be careful when you cache only because you can overflow the directory where you cache, which will be difficult though.

In other way many people are thinking about Zend Optimizer and its work with Zend_Cache. These are really different things. Zend Optimizer has nothing to do with your code it is a PHP caching tool. As you may know PHP interpreter mingles the code into “machine like” code, which in turn can be cached into the RAM with the help of Zend Optimizer. Checkout more here.