Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: matipl, dodany: 08.02.2011 09:01, tagi: php

Zend Framework Wstępnie chciałem napisać o lokalizacji, aby zaprezentować Wam jak można wykorzystać application.ini zamiast tworzyć własne zasoby (resource). Ale z drugiej strony może nie każdy wie jakie to proste w dzisiejszych czasach zrobić serwis wielojęzyczny z tłumaczeniem nie tylko statycznych napisów, ale również nawigacji czy lokalizacją kwot.

Do tłumaczeń korzystam z gettext (pliki .mo i .po). Moje pliki językowe znajdują się w project/languages i wygląda to tak:

matipl@host:~/project/languages$ ls
en_GB.mo  en_GB.po  pl_PL.mo  pl_PL.po

Gdy mamy stworzone własne tłumaczenia pora na skonfigurowanie zasobu translate w application.ini:

resources.translate.registry_key   = "Zend_Translate"
resources.translate.adapter        = "gettext"
resources.translate.content        = APPLICATION_PATH "/../languages/"
resources.translate.options.scan    = "filename"
resources.translate.disableNotices = false
resources.translate.options.logUntranslated = false
resources.translate.locale        = "pl_PL"

W ten oto sposób możemy już korzystać z plików lokalizacyjnych opartych o Zend_Translate (skonfigurowany zasób znajduje się w Zend_Registry::get(‘Zend_Translate’)). Niestety nie wie on z jakiej wersji językowej (pl czy en) chcemy skorzystać.

W tym celu stworzyłem plugin Zextend_Controller_Plugin_Locale, który pobiera wybrany (lub domyślny) język użytkownika i konfiguruje Zend_Translate. Dodatkowo mówimy widokowi i nawigacji, że ma się wspierać przez Zend_Translate z tym konkretnym językiem, który skonfigurowaliśmy.

class Zextend_Controller_Plugin_Locale extends Zend_Controller_Plugin_Abstract
{

    public function routeShutdown(Zend_Controller_Request_Abstract $request)
    {
        $view = Zend_Controller_Front::getInstance()->getParam('bootstrap')->getResource('view');
        $locale = new Zend_Locale(Zextend_Lang::getActiveLang());
        Zend_Registry::set('Zend_Locale', $locale);

        $translate = Zend_Registry::get('Zend_Translate');
        $translate->setLocale($locale);

        $view->getHelper('translate')->setTranslator($translate);
        $view->navigation()->setTranslator($translate);

        Zend_Form::setDefaultTranslator($translate);

        Zend_Registry::set('Zend_Translate', $translate);

    }

}

Na koniec wystarczy włączyć nasz plugin w application.ini:

resources.frontController.plugins.locale = "Zextend_Controller_Plugin_Locale"

Teraz możemy już swobodnie korzystać z tłumaczeń na naszej stronie, np. w widoku wywołując:

<h2><?php echo $this->translate('Contact') ?></h2>

Dla słowa „Contact” musimy mieć oczywiście odpowiedni wpis w plikach *.po. Dla wersji PL:

msgid "Contact"
msgstr "Kontakt"

Po stworzeniu tłumaczenia pamiętajmy o wygenerowaniu pliku .mo komendą: msgfmt -o pl_PL.mo pl_PL.po.

Na koniec dodam, że w danych czasach sporo rzeczy robiłem poza application.ini. Chociażby przeciążałem zasób Db, aby wprowadzić SET NAMES UTF8, czy też w index.php wpisywało się dyrektywy PHP. A obecnie?

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Śpiechu, dodany: 07.02.2011 21:41, tagi: mysql, php, zend_framework

Kontynuujemy temat zapytań z poprzedniej części. Punktem wyjścia będzie dla nas tablica wyników zapytania dorzuconego przeze mnie LEFT JOINA (w ramach aktualizacji wpisu na samym dole poprzedniej części). Aby nieco utrudnić dorzuciłem kolejnych dwóch powszechnie znanych idoli młodzieży: Antoniego Macierewicza i Stefana Niesiołowskiego, którzy dla odmiany nie będą mieli swoich ksywek. Ponadto dodałem drugą ksywkę towarzyszowi Tuskowi znanemu często na forach Onetu jako Rudy Oszust.

Reasumując: mamy polityka z dwoma ksywkami, jednego z jedną i dwóch bez ksywek. Dążymy do tego aby wyświetlić na liście rozwijanej formularza ich wszystkich. Zarówno oryginalne imię i nazwisko jak i ksywkę. Co jednak zrobić, skoro ksywka i oryginalne imię i nazwisko posiadają to samo id w bazie? Zamienimy je na unikatowe poprzez dodanie jakiegoś dodatku po oryginalnym id, np. 5–1, 5–2 itd.

Najpierw jednak stworzymy super prosty formularz zawierający pole wyboru typu select i przycisk zatwierdzający zmiany. Potrzebujemy klasy dziedziczącej po Zend_Form. Ja pracując w Zendzie zazwyczaj formularze wrzucam do katalogu forms równoległego do controllers, models itd.

class PolitycyForm extends Zend_Form {
 
   public function init() {
      $this->setMethod('post');
      // gdzie ma zostac wyslany formularz
      $this->setAction('/index/index');
 
      // tutaj wstawić zapytanie
      // z aktualizacji wpisu poprzedniej czesci
 
      $stmt = $select1->query();
      $rowset = $stmt->fetchAll();
 
      $wyniki = array();
      $counter = 1;
 
      foreach ($rowset as $row) {
         // tymczasowo kluczami staja sie wyniki zapytania,
         // a wartosciami id i kolejny numer
         $wyniki[$row['imie_nazwisko']] = $row['id'] . '-' . $counter++;
         // sprawdzamy czy ten ktos ma ksywke,
         // jezeli tak to dorzucamy do wynikow
         if ($row['ksywka'] != null) {
            $wyniki[$row['ksywka'] . ' (' . $row['imie_nazwisko'] . ')'] = $row['id']. '-' . $counter++;
         }
      }
      // nastepnie wszystko to sortujemy po kluczach
      // do poprawnego posortowania polskich znakow
      // uzywamy funkcji setlocale
      setlocale(LC_COLLATE, 'pl_PL.utf8');
      ksort($wyniki, SORT_LOCALE_STRING);
      // i zamieniamy miejscami klucze z wartosciami
      $wyniki = array_flip($wyniki);
 
      $formElement = new Zend_Form_Element_Select('politycy');
      $formElement->setRequired(true)
         // blokujemy tworzenie domyslnego walidatora
         // sprawdzajacego czy wynik jest w formie tablicy
         ->setRegisterInArrayValidator(false)
         ->setLabel('Wybierz swojego ulubionego polityka')
         ->setMultiOptions($wyniki)
         // sprawdzamy czy ktos nie robi psikusa
         ->addValidator(new Zend_Validate_Regex('/^[0-9]+\-[0-9]+$/'));   
      $this->addElement($formElement);
      // dodajemy pole typu submit
      $this->addElement('submit','wybierz');
   }   
}

Po wszystkich zabiegach tablica $wyniki przekazywana do obiektu Zend_Form_Element_Select posiada następującą strukturę:

array(7) {
  ["3-7"] => string(18) "Antoni Macierewicz"
  ["1-3"] => string(11) "Donald Tusk"
  ["2-6"] => string(31) "Jareczek (Jarosław Kaczyński)"
  ["2-5"] => string(20) "Jarosław Kaczyński"
  ["1-4"] => string(25) "Rudy Oszust (Donald Tusk)"
  ["1-2"] => string(27) "Słońce Peru (Donald Tusk)"
  ["4-8"] => string(20) "Stefan Niesiołowski"
}

Teraz pozostaje nam odebrać formularz. Żeby zbytnio nie komplikować dane odbierzemy w kontrolerze IndexController w akcji indexAction(). Na przykład tak:

$politycyForm = new PolitycyForm();
if ($this->_request->isPost()) {
   $dane = $this->getRequest()->getPost();
   if ($politycyForm->isValid($dane)) {
      // wyrzucamy szmelc po wlasciwym identyfikatorze
      $filtr = new Zend_Filter_PregReplace(
         array('match' => '/\-[0-9]+/',
               'replace' => ''));
      $przefiltrowane = $filtr->filter($dane['politycy']);
 
      // wykonujemy dzialania na bazie danych
      // co wykracza poza ramy tego wpisu
 
      // zakladamy, ze istenieje akcja panel-uzytkownika
      return $this->_redirect('/index/panel-uzytkownika');
   }
   else {
      // jezeli formularz nie przechodzi walidacji
      // to zostaje uzupelniony o wprowadzone poprzednio dane
      $politycyForm->populate($dane);
   }
}
// wyswietlamy formularz
$this->view->politycy = $politycyForm;

Możecie zapytać po co nam ten _redirect. Otóż zabezpiecza nas przed ponownym wyświetleniem użytkownikowi formularza i przed ewentualnym ponownym wysłaniem danych.

Jeżeli za szybko z czymś pojechałem, składać zażalenia w komentarzach :-)

Autor wpisu: matipl, dodany: 06.02.2011 13:26, tagi: php

Zend FrameworkW październiku 2010 roku wspominałem Wam, że wraz z pojawieniem się Zend Frameworka w wersji 1.11.0 ułatwiono nam dostosowanie aplikacji opartej o ZF dla moblinych przeglądarek.

Dzięki pomocy Raphaela w frameworku pojawiły się m.in. Zend_Http_UserAgent oraz Zend_View_Helper_UserAgent. Dzisiaj chciałbym szybko Wam pokazać jak w łatwy sposób wykryć czy mamy doczynienia z mobilną przeglądarką (zbliża się wersja bilancio dla mobilnych).

WURFL, czyli powtarzamy kroki z manuala

Zasób UserAgent korzysta z zewn. biblioteki – WURFL (Wireless Universal Resource File). Ściągamy wersję 1.1 i rozpakowujemy w dowolnym miejscu. W naszej aplikacji tworzymy /library/wurfl-php-1.1 i kopiujemy tam katalog WURFL (reszty ze ściągniętej paczki tutaj nie potrzebujemy).

Aby zakończyć ten krok musimy jeszcze skopiować plik z informacjami o urządzeniach mobilnych. Plik wurfl-latest.zip znajduje się w paczce, w ścieżce tests/resources/. Tworzymy katalog w naszej aplikacji /data/wurfl oraz /data/wurfl/cache (w tym miejscu będzie przechowywał zawartość pliku zip). Do /data/wurfl kopiujemy plik wurfl-latest.zip (kopiujemy również web_browsers_patch.xml). W skrócie (project to nazwa naszego projektu ZF):


wget "http://downloads.sourceforge.net/project/wurfl/WURFL%20PHP/1.1/wurfl-php-1.1.tar.gz?r=&amp;ts=1296984042&amp;use_mirror=sunet" -O wurfl-php-1.1.tar.gz

tar -xvf wurfl-php-1.1.tar.gz

mkdir project/library/wurfl-php-1.1

mkdir project/data

mkdir project/data/wurfl

mkdir project/data/wurfl/cache

chmod a+w project/data/wurfl

cp -R wurfl-php-1.1/WURFL project/library/wurfl-php-1.1/

cp wurfl-php-1.1/tests/resources/wurfl-latest.zip project/data/wurfl

cp wurfl-php-1.1/tests/resources/web_browsers_patch.xml project/data/wurfl

Konfiguracja WURFL

Pliki mamy skopiowane, skonfigurujmy teraz samego WURFL. Zróbmy to wg tutorialu:

<?php
$resourcesDir            = dirname(__FILE__) . '/../../data/wurfl/';

$wurfl['main-file']      = $resourcesDir  . 'wurfl-latest.zip';
$wurfl['patches']        = array($resourcesDir . 'web_browsers_patch.xml');

$persistence['provider'] = 'file';
$persistence['dir']      = $resourcesDir . '/cache/';

$cache['provider']       = null;

$configuration['wurfl']       = $wurfl;
$configuration['persistence'] = $persistence;
$configuration['cache']       = $cache;

Konfiguracja chyba jest jasna? Wskazujemy głównie miejsca plików, które wcześniej kopiowaliśmy.

Na koniec konfiguracja projektu Zend Framework. Jak ostatnio wspominałem we wpisie Zend Framework i Symfony – subiektywnie, obecnie jesteśmy w stanie zrobić większość w application.ini. W takim razie dodajmy do niego informację, że chcemy skorzystać z UserAgent i powiedzmy, gdzie umieściliśmy WURFL, który jest odpowiedzialny za „rozszyfrowanie” danych o urządzeniu mobilnym:

resources.useragent.wurflapi.wurfl_api_version = "1.1"
resources.useragent.wurflapi.wurfl_lib_dir = APPLICATION_PATH "/../library/wurfl-php-1.1/WURFL/"
resources.useragent.wurflapi.wurfl_config_file = APPLICATION_PATH "/configs/wurfl-config.php"

W tym momencie zasób UserAgent już działa i możemy z niego korzystać.

Plugin

Nasza cała aplikacja ma uwzględniać urządzenia mobilne dlatego stworzymy plugin, który w przypadku wersji mobilnej zmieni nam layout na mobilny:

class Zextend_Controller_Plugin_Mobile extends Zend_Controller_Plugin_Abstract
{

    public function routeShutdown(Zend_Controller_Request_Abstract $request)
    {
        $bootstrap = Zend_Controller_Front::getInstance()->getParam('bootstrap');
        $userAgent = $bootstrap->getResource('useragent');
        $device = $userAgent->getDevice();
        if($device->getType() == 'mobile') {
            Zend_Layout::getMvcInstance()->setLayout('mobile');
        }
    }
}

$device udostępnia nam nie tylko typ urządzenia (getType()), ale również jego szerokość ekranu (getPhysicalScreenWidth()); W bilancio będzie to po prostu przekierowanie na osobą domenę (pobierana z application.ini z app.mobileUrl), ponieważ udostępniona funkcjonalność będzie różnić się od standardowej wersji:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: sokzzuka, dodany: 05.02.2011 12:56, tagi: php, zend_framework

W dyskusji pod wpisem na blogu Matiego poruszyłem temat „walidatorów” w kontekście komponentu Zend Form w Zend Frameworku i tego, że mam zastrzeżenia co do ich koncepcji. Żeby być precyzyjnym nt. przedmiotu o którym będę się rozwodził pozwolę sobie po pierwsze odpowiedzieć na pytanie – czym jest walidacja ? Otóż słowo walidacja, jest spolszczeniem angielskiego czasownika „to validate”, który pochodzi od rzeczownika „valid”. „Valid” oznacza po prostu „poprawny”, a więc intuicyjnie „walidacja” to sprawdzanie poprawności. W przypadku oprogramowania walidacja, oznacza sprawdzenie poprawności danych w kontekście aplikacji, w której są one wykorzystane.

Najpowszechniejsze zastosowanie walidacji w aplikacjach opartych na ZF ma miejsce przy wszelkiego rodzaju formularzach. Zwykle w akcji kontrolera tworzony jest obiekt formularza potrzebnej klasy, w którym do kolejnych jego elementów „przypięte” są walidatory. Gdy wystąpi interesujące nas zdarzenie, zwykle jest nim wysłanie formularza metodą „POST”, następuje przekazanie danych do formularza, który sprawdza ich poprawność. Następnie dane są z niego wyciągane i przekazywane do jakiegoś modelu, który już zajmuje się nimi dalej.

Taki typowy flow prezentuje poniższy kod:

class Article_Form extends Zend_Form {

	public function init(){

		$oTitle = new Zend_Form_Element_Text('title');
		$oTitle->addValidator(new Zend_Validator_NotEmpty);

		$this->addElement($oTitle);
//...inne elementy
	}

}

class ArticleController extends Zend_Controller_Action {

	public function createAction(){

		$oForm = new Article_Form();
		if($this->_request->isPost()){
				$aPost = $this->_request->getPost();
				if($oForm->isValid($aPost)){
					$oArticleTable = new Article_Table;
					$oArticleTable->insert($oForm->getValues());

					$this->_redirect('/somepage');
				}

		}
		$this->view->form = $oForm;
	}

//... inne metody

}

Rozwiązanie to świetnie się sprawdza, gdy całe działanie naszej strony sprowadza się do operacji typu CRUD (Create Retrieve Update Delete). Typowym przykładem takiej aplikacji jest dowolny blog, czy prosty firmowy CMS.

Problem z tego typu walidacją pojawia się wtedy, kiedy nasza aplikacja zaczyna robić się skomplikowana. Klient potrzebuje zaimplementować złożona logikę biznesową i działanie naszego softu nie sprowadza się już do przeprowadzania podstawowych operacji na bazie danych. Zadania jakie są przed nim postawione wymagają dogłębnej znajomości procesów biznesowych klienta.

Uczestniczyłem w takim projekcie (ecommerce) dla dużego hurtowego dostawcy artykułów papierniczych. Możecie mi wierzyć albo i nie, ale zamówienie długopisu albo żółtych samoprzylepnych karteczek może być bardzo skomplikowanym procesem, w którym zaangażowane jest kilka osób/użytkowników systemu.

Wróćmy jednak do meritum, czyli naszych walidatorów. Co jest nie tak z kodem, który został zaprezentowany wcześniej ? Otóż wraz ze wzrostem złożoności warunków, które spełniać ma flow naszego kodu, rośnie jego zależność od kontekstu w jakim zostaje wykonywany. Niestety okazuje się, że walidatory, którymi możemy sprawdzać poprawność pojedynczego pola przestają wystarczyć. Oczywiście można napisać taki walidator, który sprawdza poprawność pola w kontekście innych pól naszego formularza. Można też napisać walidator, który sięgnie do bazy danych by sprawdzić jakieś dodatkowe informacje. Zawsze jednak koniec końców, kończymy z wielką zagmatwaną siecią if-ów.

Stosując taką strategię walidacji dorobimy się całego wianuszka walidatorów albo też alternatywnie zaczniemy przenosić część walidacji do akcji kontrolera. Jeżeli jeszcze dodatkowo chcemy wykorzystać dany formularz w innym miejscu systemu, gdzie wygląd formularza jest taki sam, natomiast kontekst jest trochę inny, dołożymy kolejne „ify” i skończymy z nieczytelnym i nierozwiązywalnym węzłem gordyjskim.

Raz już spotkałem się z taką sytuacją i jako, że pośrednio sam się do niej przyczyniłem, postanowiłem poszukać jakiegoś rozwiązania, które pozwoli mi uniknąć takiej sytuacji w przyszłości. Po wielu poszukiwaniach w internecie trafiłem na metodykę DDD (Domain Driven Design).  DDD proponuje rozwiązanie opcji walidacji w bardzo elegancki sposób.

Całą idee przestawię prosto na przykładzie aplikacji do rejestrowania pacjentów w placówkach polskiej tzw. „służby zdrowia”.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: matipl, dodany: 03.02.2011 10:05, tagi: php, framework, symfony

Zend FrameworkPrzed majem 2010 roku w świecie PHP poruszałem się głównie z pomocą Zend Frameworka. Kilka lat wcześniej był to autorski framework (netEngine) oraz firmowe frameworki. Z perspektywy czasu uważam, że złe było rozwijanie własnych narzędzi, zamiast pomóc społeczności. Taki zbiorowy projekt jest świetny:

  • bardzo szybko rozwijany
  • zawsze znajdziesz osobę, która zna framework (a Twój lub firmowy?)
  • spora baza tutoriali w Sieci
  • popularny = groźny (wykryta dziura w Australii może spowodować ciężki tydzień w Twojej firmie)

Od maja pracuję głównie z wykorzystaniem Symfony (1.4). Z mojego punktu widzenia przedstawia on odmienne podejście do sprawy. W Symfony da się sporo rzeczy ustawić z góry, dobry cmd line, a mnóstwo mamy out of box. Ale rozwijanie Symfony o własne dodatki czy helpery nie jest przyjemnością. Symfony odbieram jak takiego WordPressa – sprawdza się, ale jego kod pozostawia wiele do życzenia (przeplatanie języka proceduralnego z obiektowym).

Najgorszy minus Symfony 1.4 ? Mimo, że jest długo na rynku i jest najnowszą stabilną wersją Sieć prawie o nim milczy poza oficjalną dokumentacją. Jeśli przyjdzie zmierzyć się Tobie z nietrywalnym problemem lepiej od razu przejrzeć kod źródłowy frameworka niż szukać w Google.

Od grudnia znów pracuję z Zend Framework, przy okazji projektu bilancio. Wrażenia ogólne – bosko, w końcu czuję się jak w domu. Mam tyle obiektów ile dusza zapragnie. A Google bardzo jest pomocne. Najgorszy był początek przy powrocie z Symfony.

Nadal nie widzę dobrze opisanego application.ini w Sieci, a można obecnie przez niego pozbyć się nadpisywania większości zasobów (ach czasy ZF < 1.0). Dodatkowo wydaje mi się, że formularze w Symfony „szybciej mi szły”. Chociaż irytujące jest, że w większości wypadków wypluwał inputy, zamiast pełnego tagu form (łatwiej obudować w ZF jak się potrafi). No i te magiczne url_for() w Symfony (w zależności od parametru wywołuje rózne inne funkcje).

Po pierwszym tygodniu pracy z Zend Framework nie chcę się z nim znów rozstawać, Symfony to naprawdę nieprzyjemne środowisko. A przy okazji projektów ZF może w końcu zacznę dzielić się jakimiś drobnostkami z Wami. Zobaczymy czy czas pozwoli (jak widać po blogu tutejszym ostatnio mi go brak).

PS: Przed wczoraj został opublikowany Zend Framework w wersji 1.11.3 (30 załatanych dziur).

Autor wpisu: cojack, dodany: 02.02.2011 15:15, tagi: php

PHP Kiedyś już pisałem o Seo Url na blogu, co prawda temat stary jak świat, ale jakoś nigdy nie miałem koncepcji by to jakoś skrzętnie napisać. Otóż może tak trochę historii, ogólnie routing to wymyślili chłopacy od ruby on rails, napisali i tam im śmigało, następnie paru maniaków przepisało to do pythona, widać mieli w tym jakiś cel (dla mnie to masochizm pisać strony w pythonie ale co ich to ich). I nadszedł czas by ktoś przepisał koncept do PHP. Chwała im za to. A teraz ja ogarnięty szałem pisania swojego systemu, z nadszarpniętą przez kolegę Glossego dumą że pierdzę w stołek i nic nie robię postanowiłem wykorzystać dobrodziejstwo Open Sourcowych Licencji.

Routing wtf?

Czym jest routing? W sumie to wikipedia ma o tym swoje zdanie co prawda, ale moje jest takie: „Przepływem informacji”. O i na tym mógłbym zakończyć, ale że jakoś nie chce mi się jeszcze spać to sobie popiszę trochę. Jak dobrze wiemy, żeby nasza aplikacja napisana w jakże to niebanalnym języku którym jest PHP, wiedziała co robimy, co wywołać, co zepsuć. Musimy jej przesłać akcję, najczęściej po staremu byśmy to zrobili metodą łopatologiczną czyli: index.php?action=urwij. I w także oto cudowny sposób (prawie że magiczny), przesyłamy do naszej aplikacji GETa z danym kluczem i wartością, która po danej wartości z klucza wykona odpowiednią dla nas akcję. Ale czy to nie zubożałe? Takie prymitywne. W ten sposób to piszą strony gimnazjaliści za 50zł i zabierają nam chleb. Z tą różnicą że pewnie nawet nie wiedzą jak bardzo ich aplikacja jest crackerFriendly. Ale who care?

(… wdech … wydech… )

Czy nie ładniej by było gdyby nasza aplikacja miała jakiś bardziej zaawansowany system URL? Otóż oczywiście że ładniej, a np taki: www.domena.pl/:controller/:action ?

Horde Routes

Z pomocą przychodzi nam horde routes, horde to jest w ogóle zbiór przygotowanych do użycia regexpów którę sparsują nam naszego urla, zwrócą nam akcję i controllery. Także wszystko mamy gotowe. Nie działa to inaczej niż routing w Symfony. Też mamy statycznie routingi, nazwane, funkcje filtrujące, wildcard, grupowanie ścieżek, oraz warunkowe ścieżki (ciekawa sprawa swoją drogą).

Do dzieła!

Idziemy na stronę: http://dev.horde.org/routes/ pobieramy paczkę albo z pear’a instalujemy:

$ sudo pear channel-discover pear.horde.org
$ sudo pear install horde/routes

Wymagania co do php to 5.1 lub wyżej a najlepiej 5.2 lub wyżej. Dziwne, nie zagłębiałem się w kod, ani changeloga pomiędzy tymi ver nie sprawdzałem skąd taka rozbieżność.

No to pierwsze uruchomienie:

require_once 'Horde/Routes/Mapper.php';
require_once 'Horde/Routes/Exception.php';
require_once 'Horde/Routes/Route.php';
require_once 'Horde/Routes/Utils.php';
 
$mapper = new Horde_Routes_Mapper();
$mapper->connect(':controller/:action');

Poprzez metodę Horde_Routes_Mapper::connect() dodajemy nasze ścieżki które będziemy chcieli by mapper wyłapał który z adresów przesyłany do adresu url jest pasujący. A mało tego, przydałby się jakiś .htaccess, ja korzystam z tego z drupala, oczywiście przerobionego na moje potrzeby, ale w wcześniejszym link wpisie o routingu już podawałem jak może taki .htaccess wyglądąć.

Options +FollowSymLinks
DirectoryIndex index.php
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

Amen.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Zyx, dodany: 02.02.2011 13:20, tagi: php

Świat idzie naprzód. Już od jakiegoś czasu PHP udostępnia przestrzenie nazw, a społeczność programistów wstąpiła na nowe poziomy abstrakcji, rozpoczynając prace nad nowymi wersjami znanych frameworków. Niedawno rozpocząłem reaktywację grupy Invenzzia i dzisiaj pragnę zaprezentować pierwszy namacalny efekt prac, czyli bibliotekę Open Power Autoloader. Jest to kolekcja wydajnych ładowarek klas dla PHP 5.3+ zgodnych z konwencją nazewnictwa PSR-0, które jednocześnie otwierają nową edycję Open Power Libs.
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.