Net i Ja

Na niektórych hostingach bywa tak,  że z pewnych względów poniższy kod nie zadziała, a wskutek tego np ckeditor też poprawnie nie będzie interpretowała tworzonych linków.

php_flag magic_quotes_gpc Off

Rozwiązanie problemu okazało się banalne:

SetEnv MAGIC_QUOTES 0

Pisząc dziś projekt z Bezpieczeństwa Aplikacji Internetowych zatrzymał mnie na chwilkę pewien problem…
Jak skorzystać z bazy danych już na poziomie bootstrapera?

W domyślnie wygenerowanym projekcie za pomocą narzędzia Zend_Tool, czyli wpisujemy w konsoli tak:

zf create project nazwa_projektu sciezka_projektu

Oprócz fajnej struktury katalogów otrzymujemy plik konfiguracyjny naszego projektu w prezencie. Znajduje się on w .\application\configs\application.ini i wygladajakoś tak:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

Mając taki ładny czysty projekt, każdy pewnie chce go wyposażyć w dostęp do bazy danych. I tu czeka nas miła, bo ustawienie adaptera do naszej bazy jest banalnie prosta i polega tylko na dodaniu małej wstawki w plik konfiguracyjny widoczny powyżej.
...
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.db.adapter = PDO_MYSQL
resources.db.params.host = adres_bazy
resources.db.params.username = nazwa_konta
resources.db.params.password = haslo_dostepu
resources.db.params.dbname = nazwa_tablicy_w_bazie
[staging : production]
...

Powyższa czynność gwarantuje nam, bezproblemowy dostęp do tak skonfigurowanej bazy przy pomocy wszystkich klas z rodziny Zend_Db, w całym projekcie za wyjątkiem bootstrapera (.\application\Bootstrap.php). I tu właśnie się okazało, że w niektórych przypadkach i tam ten dostęp by był przydatny. Aby go uzyskać wystarczy przed naszym kodem korzystającym z dostępu do bazy ustawić domyślny adapter bazy danych, a raczej powiedzieć Zendowi gdzie leży jego konfiguracja. Pomoże nam w tym poniższy kawałek kodu:
...
$config = new Zend_Config_Ini('../application/configs/application.ini', 'production');
$db = Zend_Db::factory($config->resources->db);
Zend_Db_Table::setDefaultAdapter($db);
...

I można już odpytywać bazę danych i tu  
						

Zend jako dość porządny framework PHPowy wypracował sobie bardzo ciekawy sposób ładowanie klas, który wywodził się z banalnego pomysłu na autoloadera. Mianowicie nazwa klasy zawierała w sobie częściową ścieżkę do pliku zawierającą kod naszego obiektu. Kolejne nazwy folderów i na końcu również samego pliku z klasą były odseparowane od siebie podkreślikiem „_” (chyba tak to się nazywa ), tak więc przykładowa nazwa klasy wyglądała tak:

Core_Db_Connector co przenosiło się bezpośrednio na lokację /Core/Db/Connector.php.

Pomysł stary i dość powszechnie stosowany choć przeciwników też ma. Programiści Zenda jednak zaadoptowali ten pomysł, lecz gdy zauważyli, że co programista to inna wizja rozłożenia standardowych elementów systemu po katalogach, to pomogli nam to również uporządkować. Dlatego właśnie powstały prefixy dla najważniejszych i często stosowanych elementów systemu.

Poniżej przedstawiam taką podręczną liste, która każdemu początkującemu programiście Zend Frameworka się przyda

Ostatnimi czasy dłubie trochę przy pomocy tego rozwiązania, więc sądzę, że będzie tu więcej artykułów o Zendzie