sinisa.habek.net

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

Instalirati PDT na Ubuntu je oduvijek bila gnjavaža - verzije Ubuntu-a prije 9.10 su imale poprilično staru verziju Eclipse (3.2) tako da je u tom slučaju bilo najjednostavnije pokupiti odgovarajući All-In-One paket, otpakirati ga u /opt direktorij i koristiti ga odande. To isto možete napraviti i u verziji 9.10, ali trebate biti spremni na probleme koje Eclipsa ima sa novijom verzijom Gtk-a.

Verzija 9.10 ima noviju verziju Eclipse (3.5), ali još uvijek nedostaje PDT plugin. Osim (poprilično trapavog rješenja) instaliranja PDT plugina iz same aplikacije, možete dodati PPA repozitorij sa pluginovima. Ukratko, trebate napraviti slijedeće:

sudo add-apt-repository ppa:yogarine/eclipse/ubuntu && sudo apt-get update
sudo apt-get install eclipse-pdt

Isto tako, postoji i repozitorij za verziju 9.04.