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

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.