sinisa.habek.net

Da bi se olakšao deploy aplikacija napisanih u Zend Framework-u dodajemo dvije postavke u apache-ovu vhost datoteku:

<VirtualHost *:80>
	ServerName test.mysite.com
	ServerAdmin webmaster@test.mysite.com
 
	SetEnv APPLICATION_ENV testing
	php_value include_path ".:/web/zf/1.10/library:/usr/share/php"
 
	DocumentRoot /web/apps/mysite.com/public
	<Directory />
		Options All
	</Directory>
	<Directory /web/apps/mysite.com/public/>
		AllowOverride All
	</Directory>
 
	ErrorLog /web/logs/012-test.mysite.com-error.log
 
	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel debug
 
	CustomLog /web/logs/012-test.mysite.com-access.log combined
</VirtualHost>

SetEnv APPLICATION_ENV testing

ovim određujemo koji dio (sekcija) konfiguracije će se koristiti, ovo obično stavljamo u .htaccess datoteku projekta (ili postavljamo u index.php prije samog bootstrapa aplikacije) - u ovom slučaju nema potrebe za naknadnim mijenjanjem deploy-anih datoteka, automatski se koristi ispravna konfiguracijska sekcija ovisno o serveru na koji je stavljena aplikacija

php_value include_path ".:/web/zf/library:/usr/share/php"

druga stvar koja se može mijenjati ovisno o serveru na kojem se izvršava aplikacija je putanja do samog Zend Frameworka, isto kao i APPLICATION_ENV, postavljanjem te putanje u index.php (ili neku drugu datoteku aplikacije) uvijek je trebamo upisivati kod deploy-a aplikacije na server, ako je upišemo u vhost uvijek ćemo imati ispravnu putanju bez obzira na kojem serveru je aplikacija

u teoriji možemo dodati putanju do ZF-a u php.ini, ali to bi se moglo pokazati kao problematično ako na istom serveru imamo više aplikacija koje koriste razne verzije ZF-a ili nekih drugih lib-ova

U prijašnjem postu sam opisao jednostavan način korištenja konfiguracije u Zend Framework aplikacijama, te sam na kraju naveo nedostatke koje ima takav pristup. U ovom postu će biti primjer konfiguracije logger-a (objekt preko kojeg se u aplikaciji logiraju događaji) kod kojeg su ti nedostaci izbjegnuti.

Ovaj put neće biti posebne konfiguracijske datoteke, a postaviti će se samo jedan konfiguracijski parametar za logiranje - log.path, tj. putanja u koju želimo da aplikacija sprema logove (stvaran primjer bi imao malo više parametara):

application/configs/application.ini:

[production]
 
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
 
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
 
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
 
log.path = APPLICATION_PATH "/../data/log"
 
[staging : production]
 
[testing : production]
 
[development : production]
 
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

U bootstrap-u ne spremamo konfiguraciju kao u primjeru iz prošlog posta nego te podatke koristimo za kreiranje loggera, instance Zend_Log klase koju koristimo za logiranje. Naravno, logger se sprema u registry iz kojeg ga možemo dohvatiti i koristiti iz bilo kojeg dijela aplikacije (naravno, stvarni bootstrap bi imao malo više toga):

application/Bootstrap.php:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
	protected function _initAutoload()
	{
		$autoloader = Zend_Loader_Autoloader::getInstance();
 
		$moduleLoader = new Zend_Application_Module_Autoloader(array(
			'namespace' => '',
			'basePath' => APPLICATION_PATH
		));
 
		return $moduleLoader;
	}
 
	protected function _initLogger()
	{
		$options = $this->getOptions();
 
		$logger = new Zend_Log(
			new Zend_Log_Writer_Stream($options['log']['path'].'/log_'.date('Y-m-d').'.log')
		);
 
		Zend_Registry::set('logger', $logger);
 
		return $logger;
	}
}

Kad trebamo nešto logirati, logger čitamo iz registry-ja i pozivamo odgovarajuću metodu na njemu:

<?php
 
Zend_Registry::get('logger')->notice('Some application notice');

U usporedbi sa primjerom iz prijašnjeg posta:

1. podaci iz konfiguracije se koriste samo u bootstrap-u, ako se promjeni struktura podataka u konfiguraciji biti će potrebno prilagoditi samo bootstrap - tipičan primjer bi bio ako npr. odlučimo umjesto logiranja u datoteku koristiti logiranje u bazu podataka
2. u registry više nemamo spremljene parametre koje tek trebamo za nešto upotrijebiti već spreman objekt koji se može koristit - ako i postoji nešto što se ponavlja na svakom mjestu gdje se koristi to je već riješeno unutar njega

Iako ovo baš nije najbolji način rada sa konfiguracijom može se upotrijebiti u jednostavnijim aplikacijama (u kojima ionako nema smisla previše komplicirati) ili kao brzi fix u nekoj većoj aplikaciji (s tim da bi u tom slučaju ipak to kasnije trebalo riješiti na neki kvalitetniji način).

Sami podaci se spreme u posebnu konfiguracijsku datoteku (u teoriji mogao bi se koristiti i application.ini), ali ako radite nešto takvoga sigurno se radi o parametrima koji se na neki način razlikuju i bolje ih je ne miješati sa ostalom konfiguracijom aplikacije. Npr. mogu se spremiti u options.ini datoteku:

application/configs/options.ini:

[production]
 
image.thumbnail.width = 80
image.thumbnail.height = 80
image.preview.width = 350
image.preview.height = 350
 
[staging : production]
 
[testing : production]
 
[development : production]

Konfiguracija se čita za vrijeme bootstrap-a aplikacije i sprema u registry:

application/Bootstrap.php:

<?php
 
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
	protected function _initOptions()
	{
		$options = new Zend_Config_Ini(APPLICATION_PATH.'/configs/options.ini', APPLICATION_ENV);
 
		Zend_Registry::set('options', $options);
	}
}

I na kraju, konfiguraciju koja je za vrijeme bootstrap-a spremljena u registry može se dobiti i koristiti kad god je to potrebno i iz bilo kojeg dijela aplikacije:

<?php
 
$thumbWidth = Zend_Registry::get('options')->image->thumbnail->width;

Loše strane ovakvog rješenja (zato i je upotrebljivo samo za jednostavnije slučajeve i fix-eve) su:

1. aplikacija postaje vezana uz strukturu konfiguracijske datoteke - ako se zbog nečega promjeni struktura konfiguracije, morati će se isto ispravljati na svim mjestima u aplikaciji na kojima se ti podaci koriste (tj. čitaju)
2. Zend_Registry i Zend_Config nisu baš previše pametne klase, još uvijek ćete morati sami odraditi provjere kod čitanja parametara i pokriti sve slučajeve koji su bitni (npr. nema traženog podatka, podatak nije ispravan i sl.), ako isti podatak opet trebate negdje drugdje morati ćete to isto ponoviti tamo