Tag Archives: PHP

Quick Look at JavaScript Objects

JavaScript Objects

As you may know there are different notations of objects in JavaScript, and there are slight differences. However here I’m gonna achieve the same thing with different notations. The first one is the object notation in JavaScript known mostly from JSON. There you’ve to construct a key/value pairs, divided by a colon:

var class1 = {
    a : 0,
    func1 : function() {
        console.log(class1.a);
    },
    func2 : function(a) {
        this.a = a;
    }
}
class1.func2(3);

Here we have two functions – func1 and func2 and one member variable. Func2 is setting up the member variable, it’s something like a setter in some languages like Java and PHP, and the func1 is printing the value of that variable via console.log(). Note that in the body of func1() the variable “a” is accessed with the class name: class1.a. Here the notation can be changed to this.a, which will result in the same thing.

...
console.log(this.a);
...

Notation #2

While in the notation I’ve just used is not possible to have two different instances from the same class, in the next example this is possible. In JavaScript the objects are even the functions, and you can access the function’s private variables with the dot notation.

var class2 = function() {
    this.a = 0;
    this.func1 = function() {
        console.log(this.a);
    }
 
    this.func2 = function(a) {
        this.a = a;
    }
}

To use this object you’ve to use the “new” operator.

var c = new class2();
c.func2(4);

This helps you create more than one instance of the same class.

var c = new class2();
var d = new class2();
c.func2(3);
d.func2(4);

Setting Up Zend Framework with Modules

Typical Zend App

Typically you’ve one module in your Zend App – the default one. In the basic installation of the framework, you put all the controllers, models and views directly in the application folder, as described below.

/application
	- /controllers
		- /IndexController.php
	- /models
		- /MyModel.php
	- /views
		- /scripts
			- /index/index.phtml
/library
	- /Zend
/public_html
	- /images
	- /scripts

Bigger Apps – More Code

When the application becomes bigger and bigger the controller, models and views/scripts directories contain more and more files. That’s a bit odd, because it becomes difficult to maintain, and than the modules come in hand.

Modules in a Zend App

When it comes to setting up modular Zend App there are tons of articles in the web, but let me show you a simple directory layout and … sample code that sets up the framework.

/application
	- /modules
		+ /admin
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
		+ /default
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
	- /models
/library
	- /Zend
/public_html
	- /images
	- /scripts

Source

Simply add this into the bootstrap:

$frontController->addModuleDirectory(APPLICATION_PATH . '/modules');

Fetching Rows With Zend_Db fetch()

Fetching the Entire Row Set

Rows

What is really handy in Zend Framework is that you can fetch the entire row set with the fetchAll() method. It comes with some parameters that you can use for limiting the result or ordering, but in general you can use it without specifying parameters. Let say this is the model:

<?php
class User extends Zend_Db_Table
{
 
	public function listAll()
	{
		$query = "SELECT * FROM user";
 
		// exec query
		$rs = $this->getAdapter()->query($query);
 
		return $rs->fetchAll();
 
	}
 
}

You can simply return the row set with the fetchAll() method as described in the example, but what if you have to loop through the rows and to modify somehow the values?

Fetching a Row

By simply change the code like so:

class User extends Zend_Db_Table
{
 
	public function listAll()
	{
		$query = "SELECT * FROM user";
 
		// exec query
		$rs = $this->getAdapter()->query($query);
 
		// fetch
		$list = array();
		while ($row = $rs->fetch()) {
			// removing the password column value
			$row['password'] = '';
 
		    $list[] = $row;
		}
 
		return $list;
	}
}

you can modify the rows and you’ll have the same result.

Setting Up Global Cache in Zend Framework

In a large scale web application, especially based on Zend Framework, there are lot’s of components that support built in cache support. Such are Zend_Db, Zend_Translate, Zend_Date, etc. Also you may need cache support wherever in the app, so my advice is to setup a cache instance in the “beginning”, into the bootstrap.php or even better – into a front controller plugin, and to store it into the Zend_Registry. Thus you’ve to change only the lifetime for specific needs:

<?php
 
class CacheInit extends Zend_Controller_Plugin_Abstract
{
    public function __construct()
    {
        $frontendOptions = array(
            'automatic_serialization' => true,
            'lifetime' => 60
        );
 
        $backendOptions  = array(
            'cache_dir' => realpath(APPLICATION_PATH . '/../cache')
        );
 
        $cache = Zend_Cache::factory('Core',
                                     'File',
                                     $frontendOptions,
                                     $backendOptions);
 
        Zend_Registry::set('cache', $cache);
    }
}

Than add it as a front controller plugin:

// cache plugin
$frontController->registerPlugin(new CacheInit());

Zend Framework: Cache Database Table Schemes

If you’re familiar with Zend Framework, you should know how to turn your database tables into models. Simply extend the Zend_Db_Table class. This is the very general example. There are lots of variations how to name the model classes and what member variables they can have.

<?
class User extends Zend_Db_Table
{}

The question is …

The question is how the framework knows what columns there are in a given table. That’s done by PHP on every call of the class, and the question is: isn’t that too slow? Yes it is and there’s a solution – to cache the table’s schema:

Zend_Db_Table_Abstract::setDefaultMetadataCache($cache);

Is there any problem?

Why it isn’t a default behavior when it’s so good? Because you’ve first to setup the cache, which is not always permitted – at least you’ve to have writing permissions. And on the second place if you’re rapidly developing the system and you change the database schema too frequently, you’ve to clear the cache every time. So it’s a good solution for the production server, but you can skip it while developing.