Na rynku istnieje mnóstwo rozwiązań Open Source, rozwiązujące różne klasy zagadnień. Mowa tu o produktach e-commerce (Magento, Presta Shop), CMS (Drupal, Joomla, WordPress), systemach klasy CRM, ERP, czy DMS, a także „community builders”, czyli np. fora internetowe (PHP BB). W zdecydowanej większości powyższych przypadków nie potrzeba wiedzy programistycznej aby wdrożyć i rozwijać serwisy. Mają one obszerne zbiory rozszerzeń i wtyczek (plugins), które pozwalają dostosowywać systemy do potrzeb. Takie podejście pozwala na znaczne zmniejszenie kosztów wdrożenia aplikacji.

Pomimo tych zalet, często jest tak, że systemy te pasują do prostych modeli biznesowych, które w życiu codziennym występują nad wyraz rzadko. W starciu z rzeczywistością, wdrażanie takich systemów, a przede wszystkim utrzymanie i reakcje na rozwój rynku mają przełożenie na zasadę Pareto, która mówi o tym, że 80% funkcjonalności jesteśmy w stanie osiągnąć w 20% czasu, a 20% krytycznych funkcji systemu konsumuje 80% budżetu.

Głównymi problemami z jakimi spotykają się wdrożenia oparte o gotowe rozwiązania to przede wszystkim komplikacja logiki biznesowej systemu, której nie da się odwzorować na możliwości produktu. Często dochodzi do paradoksalnych sytuacji, w których model biznesowy trzeba dopasowywać do systemu, co nigdy nie powinno mieć miejsca. Inną kwestia jest rozwój aplikacji i zwiększenie ruchu, które powoduje, że dobrze działające oprogramowanie dla małej liczby użytkowników staje się bezużyteczne przy wielkim obciążeniu. Poza tym istnieje potencjalne ryzyko związane z atakami hakerskimi, gdyż kod jest otwarty i dostępny dla potencjalnych włamywaczy. Aby dostrzec skalę problemu, wystarczy przejrzeć serwisy z dostępnymi exploitami. Ostatnią kwestią, która przychodzi w tym momencie na myśl, jest to, że czasem społeczność rozwijająca dany produkt, w pewnym etapie może zaprzestać dalszych prac. Powodów może być kilka, raz jest to skłócenie zespołu, innym razem przejście na nową technologię, lub do innego projektu, pozostawiając dotychczasowych użytkowników samych sobie.

Zalety tworzenia oprogramowania dedykowanego

Wszystkie problemy opisane powyżej rozwiązuje oprogramowanie dedykowane, a nawet można się pokusić o stwierdzenie, że wnosi tutaj wiele wartości dodanych. Przede wszystkim klient dostaje dokładnie to czego potrzebuje i za co płaci. Oczywiście trzeba mieć na względzie, że nie każdy klient jest osobą techniczną i nie koniecznie musi mieć doświadczenie z systemami informatycznymi, więc doradztwo technologiczne jest tutaj nieocenioną wartością. Firma programistyczna na etapie przygotowania oferty doradza klientowi najlepsze rozwiązania, proponuje pewne opcje, tworząc przy tym najlepszą możliwą ofertę, budując relację i zaufanie z zamawiającym. Dzięki temu klient odzwierciedla swój model biznesowy w tworzonym systemie, nastawiając się na zysk z inwestycji w przyszłości. Poza tym oprogramowanie jest gotowe na rozwój, co jest bardzo ważnym czynnikiem, gwarantującym skuteczność przedsięwzięcia i reakcję na sygnały spływające od użytkowników lub na trendy rynkowe. Ważnym czynnikiem jest tutaj również samopoczucie programistów, którzy nie klikają w panelach administracyjnych Drupala czy Magento, ale programują i rozwiązują problemy, realizując się przy tym zawodowo.

Nie wynajdujemy koła od nowa, czyli o frameworkach słów kilka

Framework to z definicji zestaw uniwersalnych narzędzi na bazie których tworzy się aplikacje. Nie wyobrażalne jest, aby w tych czasach tworzyć systemy informatyczne bez wykorzystania takiego narzędzia. Aby lepiej zobrazować temat, możemy porównać do płyty podwoziowej samochodu. Daje nam ona wszelkie potrzebne mechanizmy, czyli ramę całego auta, łożyska, układ wydechowy, wiązki elektryczne. Na takiej ramie możemy stworzyć wiele rodzajów samochodów, np. pickup, miejski hatchback, średniej klasy sedan, lub ekskluzywny, drogi wóz. Podobnie jest z frameworkiem – zapewnia mechanizmy potrzebne w większości systemów. Mowa przede wszystkim o kontrolerze aplikacji, reagującym na żądania użytkownika, warstwie widoku, prezentującą dane w formie graficzne, warstwie dostępu do bazy danych, mechanizmie bezpieczeństwa, pozwalającą na autoryzowanie użytkowników i ograniczanie dostępu do poszczególnych części serwisu. To tylko niektóre z rozwiązań, nowoczesne frameworki dostarczają wiele więcej. Inną kwestią jest standaryzacja kodu tworzonego przy ich użyciu. Jest o wiele łatwiej nowej osobie wejść w projekt, jeśli framework narzuca standardy kodowania i rozwiązania umieszczane są w odpowiedniej strukturze kodu. Pozwala to na szybsze wdrażanie się nowych członków zespołu, a co za tym idzie na przyspieszenie całego rozwoju.

Jest jeszcze jedna ważna kwestia, która decyduje o sukcesie danego frameworka – liczba gotowych rozwiązań w postaci wtyczek lub komponentów. Jest to sytuacja analogiczna do gotowych rozwiązań Open Source, z tym, że tutaj łatwo rozszerzyć dany komponent oraz dostosować go do wymagań systemu. Mamy też zapewnione wsparcie społeczności w kwestii rozwiązywania problemów, tworzenia nowych funkcjonalności czy aktualizacji i wydawania poprawek.

Dlaczego Symfony2 pasuje tutaj jak ulał?

Symfony2 kontynuuje dobrą passę swojego poprzednika, który istnieje już 6 lat. Programiści wyciągnęli naukę z poprzedniej wersji, podpatrzyli rozwiązania z innych platform (Java, Ruby On Rails, Python i Django, czy Zend Framework) i przepisali całość od podstaw. Dzięki temu powstał najlepszy aktualnie framework PHP, który wygrywa przede wszystkim bardzo dobrą strukturą niezależnych modułów, które można rozwijać oddzielnie, a nawet wykorzystywać w innych projektach. Autorzy przewidzieli strukturę projektu tworząc tzw. Bundle, które są modułami, gotowymi do użycia w innych projektach (nawet wnętrze frameworka się z nich składa). W tym momencie warto wspomnieć o Bundlach dostarczanych przez programistów i firmy zewnętrzne (jest ich już prawie 600). Całość systemu jest oparta o nowoczesny kontener wstrzykiwania zależności (Dependency Injection Container), przez co podmiana kluczowych części systemu może być zrobiona w mgnieniu oka (to rozwiązanie bardzo szeroko stosuje się w Java EE oraz innych dojrzałych rozwiązaniach). Warto też zauważyć, że autorzy duży nacisk kładą na wydajność i szybkość działania, co jest zauważalne na pierwszy rzut oka, bez wnikliwych badań obciążeniowych.

O powadze sytuacji świadczy też fakt, że Symfony2 zostało w całości przeniesione do gita i jego kod jest utrzymywany w serwisie Github.com. Dzięki temu każdy może go sklonować kod źródłowy, pracować na nim lokalnie wprowadzając poprawki czy tworząc nowe funkcjonalności, a później jednym kliknięciem wysłać prośbę o włączenie swoich zmian do głównego repozytorium. To powoduje, że na dzień dzisiejszy Symfony2 jest najczęściej rozgałęzianym i najchętniej oglądanym repozytorium PHP na Githubie, a liczba osób, które miały swój wkład w rozwój przekracza 250. Poza tym za frameworkiem stoi francuska firma Sensio Labs, wraz z założycielem i głównym programistą Fabienem Potencierem. Ten fakt zapewnia stabilność rozwoju, wysoką jakość dokumentacji oraz dostępność szkoleń i materiałów. Firma ta zorganizowała nawet zbiórkę pieniędzy wśród społeczności i zleciła audyt bezpieczeństwa organizacji zajmującej się tego typu działaniami .

Reasumując, trzeba przyznać, że Symfony2 zrewolucjonizowało świat frameworków PHP, a można się nawet pokusić o stwierdzenie, że programiści innych języków (Python, Ruby, Groovy) też z szacunkiem patrzą na to rozwiązanie. Symfony2 idealnie nadaje się do rozwoju aplikacji dedykowanych i na pewno można go polecić do większości projektów.

Konfiguracja

Podstawowa konfiguracja polega na ustawieniu odpowiedniej klasy sterownika oraz strategii keszowania. Doctrine dostarcza klasy sterowników dla większości powszechnie używanych mechanizmów keszujących (APC, XCache, memcache) oraz dwie strategie keszowania (keszowanie wyników procesu parsowania zapytań DQL oraz keszowanie wyników zapytań SQL). W zależności od potrzeb konfigurację możemy przeprowadzić globalnie (do wyboru mamy konfigurację managera lub połączeń) lub lokalnie z poziomu konkretnego zapytania.

Pracując z symfony ustawienia globalne najlepiej zdefiniować poprzez dodanie metody configureDoctrine() klasy ProjectConfiguration. W zależności od wybranej strategii rejestrujemy sterownik poprzez ustawienie odpowiedniego atrybutu (Doctrine_Core::ATTR_QUERY_CACHE lub Doctrine_Core::ATTR_RESULT_CACHE). Dodatkowo poprzez ustawienie atrybutu Doctrine_Core::ATTR_*_CACHE_LIFESPAN możemy ustawić czas ważności rekordów.

Powyższa konfiguracja obejmuje wszystkie połączenia nawiązywane przez Doctrine. Czasem może zaistnieć potrzeba ograniczenia konfiguracji do konkretnego połączenia (na przykład jedno z dwóch połączeń jest nawiązywane do bazy danych modyfikowanej przez inną aplikacje). W takiej sytuacji możemy użyć metody configureDoctrineConnectionName() zastępując człon Name nazwą naszego połączenia.

W razie potrzeby konfigurację możemy przeprowadzić z poziomu konkretnego zapytania. Służą do tego metody useQueryCache() oraz useResultCache() (w dalszej części artykułu poznamy szersze zastosowanie tych metod). Konfiguracja lokalna nadpisuje konfigurację globalną.

Keszowanie w praktyce

Mając poprawnie skonfigurowany sterownik jesteśmy gotowi, aby zastosować mechanizm keszujący do naszych zapytań. Kolejne kroki zależą od poziomu konfiguracji oraz wybranej strategii keszownia. Dla przykładu, jeśli wybraliśmy konfigurację globalną oraz keszowanie wyników zapytań, należy powiadomić Doctrine, które zapytania mają być keszowane (keszowanie wyników procesu parsowania DQL jest automatycznie zastosowane do wszystkich zapytań). Służy do tego wczesniej poznana metoda useResultCache(). Metoda ta jako pierwszy parametr przyjmuje instancję sterownika lub wartość logiczną, który informuje czy dane zapytanie ma być objęte mechanizmem keszowania. Drugi parametr określa czas ważności rekordu dla naszego zapytania, natomiast trzeci jest identyfikatorem tego rekordu.

W ten sposób wynik zapytania po pierwszym wykonaniu zostanie umieszczony w mechanizmie keszującym pod nazwą sample_query na okres jednej godziny. W ciągu tej godziny każde kolejne wykonanie zapytania będzie oddelegowane do mechanizmu keszującego.

Przekazując do zapytania dodatkowe parametry, musimy zadbać, aby każdemu ich zestawowi odpowiadał inny ciąg identyfikujacy wynik zapytania. Doctrine automatycznie wygeneruje odpowiedni identyfikator jeśli nie podamy go jawnie. Takie rozwiązanie jest niewygodne jeśli mamy w perspektywie zarządzanie zawartością mechanizmu keszującego (musimy znać idnentyfikator). Więcej o zarządzaniu wynikami operacji keszowania można przeczytać w poniższym paragrafie.

Metoda useQueryCache() poza tym, że nie przyjmuje trzeciego parametru (identyfikatora) działa analogicznie do useResultCache(). Szczegółowe informacje można znaleźć w dokumentacji API.

Co dalej?

Keszowanie wyników zapytań niesie ze sobą pewne niebezpieczeństwo – dane mogą szybko stać się nieaktualne. Wraz ze sterownikami otrzymujemy zestaw metod umożliwiających zarządzanie zawartością mechanizmu keszującego. W połączeniu z mechanizmem zdarzeń możemy automatycznie usuwać skeszowane wyniki, zapewniając sobie w ten sposób aktualność danych.

Wolne od takich problemów jest keszowanie wyników parsowania DQL, które zarządzane jest przez Doctrine automatycznie.

Podsumowanie

Pomimo oczywistych zalet, stosowanie mechanizmu keszującego powinno być dobrze przemyślane. O ile keszowanie sparsowanych zapytań DQL jest bezpieczne (jeśli stosujemy prepared statements) i zaleca się jego użycie w większości projektów, to wykorzystanie skeszowanych wyników zapytań powinno dotyczyć tylko wybranych przypadków, w których ma sens i faktycznie przyniesie nam korzyści. Nie należy zapominać tutaj o zasadzie, że nie wszystko co zostało opisane jako dobra metoda na polepszenie wydajności aplikacji, będzie dawało taki rezultat we wszystkich sytuacjach.

]]> http://xlab.pl/doctrine-cache/feed/ 0 http://xlab.pl/konfiguracja-projektu-w-symfony-pod-test-driven-development/ http://xlab.pl/konfiguracja-projektu-w-symfony-pod-test-driven-development/#comments Fri, 22 Oct 2010 14:53:20 +0000 Wojtek Sznapka http://xlab.pl/?p=1578 W projektach symfony, korzystając z wbudowanego mechanizmu do testów jednostkowych (lime), można łatwo programować w oparciu o nurt Test Driven Development (TDD).

Aby przygotować środowisko do TDD wystarczą trzy kroki:

1. Konfigurujemy połączenie do testowej bazy, którą będzie sqlite przechowywane w pamięci. W pliku config/databases.yml dopisujemy:
2. Tworzymy dane testowe, tzw. fixtures, które umieszczamy w folderze test/fixtures (należy go stworzyć ręcznie). Celowo nie umieszczamy danych w data/fixtures, gdyż tam powinny znaleźć się testowe dane, które mogą być użyte np. podczas prezentacji systemu. Jeśli chcemy zachować kolejność danych, możemy ponumerować pliki yml, np.
3. Tworzymy plik bootstrap dla testów opartych o bazę danych (test/bootstrap/model.php). Plik ten stworzy strukturę tabel na podstawie modelu i załaduje je do bazy oraz wprowadzi dane testowe (fixtures). „Dziedziczy” on pewne ustawienia z bootstrapu unit.php. Trzeba z niego korzystać zawsze, gdy przychodzi potrzeba odwoływania się w testach do bazy danych.

Następnie uruchamiamy ./symfony test:unit i podziwiamy, jak nasze testy przechodzą w stu procentach :-)
Powyższa konfiguracja była testowana dla symfony 1.4 z doctrine 1.2

Aby nasze maile były uniwersalne i dostępne w każdej aplikacji tworzymy dla każdej wiadomości  osobną klasę dziedziczącą z Swift_Message i umieszczamy ją w głównym folderze lib

class MyTextMessage extends Swift_Message
{
  public function __construct($name, $address)
  {
    parent::__construct();
    $this->setFrom('foo@bar.com');
    $this->setTo($address);
    $this->setSubject('My text message');
    $body  = sprintf("Hi %s!\nHow are you?", $name);
    $this->setBody($body);
  }
}

Taką wiadomość możemy łatwo wysłać w ten sposób (z akcji lub z taska):

$this->getMailer()->send(new MyTextMessage('Barack', 'barack@obama.com'));

Jak widać metoda ta jest prosta i przyjemna. Trochę trudniej jest w przypadku e-maili, których zawartość jest w formacie HTML. Musimy wtedy użyć klasy sfPHPView, udostępnianej przez symfony

$templatesDir = sfConfig::get('sf_root_dir') . '/data/mailTemplates/';
$view = new sfPHPView(sfContext::getInstance(), null, null, null);
$view->setTemplate($templatesDir . 'MyMessageTemplate.php');
$view->getAttributeHolder()->add(array('name' => 'Barack'));
$view->setDecorator(false);
$body = $view->render();

Szablon e-maila z pliku /data/mailTemplates/MyMessageTemplate.php może wyglądać następująco

<h1>Hi <?php echo $name ?></h1>
<p>How are you?</p>

Klasa do wysyłania e-maili w formie HTML będzie wyglądała następująco

class MyHtmlMessage extends Swift_Message
{
  public function __construct($name, $address)
  {
    parent::__construct();
    $this->setFrom('foo@bar.com');
    $this->setTo($address);
    $this->setSubject('My text message');
    $body = $this->_buildBody('Barack');
    $this->setBody($body);
  }

  protected function _buildBody($name)
  {
    $templatesDir = sfConfig::get('sf_root_dir') . '/data/mailTemplates/';
    $view = new sfPHPView(sfContext::getInstance(), null, null, null);
    $view->setTemplate($templatesDir . 'MyMessageTemplate.php');
    $view->getAttributeHolder()->add(array('name' => $name));
    $view->setDecorator(false);
    return $view->render();
  }
}

Tak stworzony mechanizm można w łatwy sposób podpiąć pod eventy oferowane przez symfony, czyniąc go jeszcze bardziej elastycznym. Oczywiście w takim podejściu możemy wykorzystać dobrodziejstwa programowania obiektowego, tworząc klasy bazowe e-maili czy rozszerzać istniejące e-maile przy pomocy dziedziczenia.

Opis tej metody można również znaleźć w podręczniku symfony (Email Messages as Classes).

  class myWidgetFormSelect extends sfWidgetFormSelect
  {
    public function renderContentTag($tag, $content = null, $attributes = array())
    {
      if ($tag == 'option' && isset($attributes['value'])
        && $this->disableCondition($attributes['value'])
      ) {
        $attributes['disabled'] = 'disabled';
      }
      return parent::renderContentTag($tag, $content, $attributes);
    }   

    protected function disableCondition($value)
    {
      return (int)$value < 0;
    }
  }

class MobileBrowserDetector
{
  private static $mobileAgentPrefixes = array(
    'w3c ','acs-','alav','alca','amoi','audi','avan','benq','bird','blac',
    'blaz','brew','cell','cldc','cmd-','dang','doco','eric','hipt','inno',
    'ipaq','java','jigs','kddi','keji','leno','lg-c','lg-d','lg-g','lge-',
    'maui','maxo','midp','mits','mmef','mobi','mot-','moto','mwbp','nec-',
    'newt','noki','oper','palm','pana','pant','phil','play','port','prox',
    'qwap','sage','sams','sany','sch-','sec-','send','seri','sgh-','shar',
    'sie-','siem','smal','smar','sony','sph-','symb','t-mo','teli','tim-',
    'tosh','tsm-','upg1','upsi','vk-v','voda','wap-','wapa','wapi','wapp',
    'wapr','webc','winw','winw','xda','xda-'
  );

  private static $mobileAgentParts = array(
    'up.browser', 'up.link', 'mmp', 'symbian', 'mobile safari',
    'opera mobi', 'android', 'smartphone', 'midp', 'wap', 'phone'
  );

  public static function isMobile($userAgent = '')
  {
    if (!strlen($userAgent)) {
      $userAgent = $_SERVER['HTTP_USER_AGENT'];
    }
    $isMobile = false;
    $isMobile |= in_array(strtolower(substr($userAgent, 0, 4)), self::$mobileAgentPrefixes);
    $isMobile |= preg_match(sprintf('#(%s)#i', implode('|', self::$mobileAgentParts)), $userAgent);
    $isMobile |= strpos(strtolower($_SERVER['HTTP_ACCEPT']),'application/vnd.wap.xhtml+xml') !== false;
    $isMobile |= isset($_SERVER['HTTP_PROFILE']);
    $isMobile |= isset($_SERVER['HTTP_X_WAP_PROFILE']);
    $isMobile |= isset($_SERVER['ALL_HTTP']) && strpos(strtolower($_SERVER['ALL_HTTP']),'OperaMini') !== false;
    return (bool)$isMobile;
  }
}

Możemy łatwo użyć tej klasy na przykład w projekcie symfony, podmieniając główny layout na layout mobilny (apps/APLIKACJA/templates/layout_mobile.php) w filtrze, w poniższy sposób.
Zawartość apps/APLIKACJA/config/filters.yml

rendering: ~
security:
  class: sfGuardBasicSecurityFilter
mobile:
  class: MobileFilter
cache:     ~
common:    ~
execution: ~

Klasa filtra lib/MobileFilter.class.php:

class MobileFilter extends sfFilter
{
  public function execute($filterChain)
  {
    if (MobileBrowserDetector::isMobile()) {
      $this->getContext()->getActionStack()->getFirstEntry()->getActionInstance()->setLayout('layout_mobile');
    }
    $filterChain->execute();
  }
}

Natchnęło mnie dziś do pomyślenia jak uchronić się przed niebezpieczeństwami związanymi z stosowaniem die() w kodzie…tak wiem że była o tym parę razy mowa, że to zło w najczystszej postaci,  że najlepiej korzystać z xdebug, a najlepiej nigdy nie korzystać z die() w kodzie.

Wszystko ma jednak swoje wady i zalety – o ile w pracy xdebuga mogę sobie skonfigurować pod netbeansa to w domu nie korzystam z tego IDE (połączenie przez OpenVPN i dość częste skanowanie projektu jest nader uciążliwe). Dlatego zaczerpnąłem nieco mocy googla i po kilku testach przedstawiam:  FirePHP.

FirePHP to całkiem zgrabny logger dla PHP wykorzystujący Firebuga – ku mojemu zdziwieniu jest to całkiem niezły plugin, do jego działania wystarczy mieć zainstalowaną wtyczkę Firebug z włączoną zakładką sieć i konsola. Instalując FirePHP trzeba jeszcze pamiętać o zaciągnięciu biblioteki FirePHPCore, którą rozpakowujemy do katalogu roota (w moim przypadku to katalog web w symfony).  FirePHP pokaże się jako niebieski robal (widoczny na poniższym zrzucie).

Mając to wszystko jesteśmy niemal gotowi by bezpiecznie debugować skrypty. Do skryptu dołączamy:

require_once('FirePHPCore/FirePHP.class.php');

Teraz już poprzez wywołanie w postaci:

$firephp = FirePHP::getInstance(true);
$firephp->log($var, 'nieobowiazkowy opis dla loga');

Zobaczymy w zakładce konsola Firebuga wartość zmiennej $var poprzedzoną opisem podanym jako drugi parametr funkcji log.
Dla własnej wygody napisałem krótką funkcję ustawiającą podstawowe parametry debugowania:

/**
* Function is used for debuging this scrypt, in prod environment change
* $firephp->setEnabled(true); to false.
*
* @param object $var
* @param string $desc[optional]
*/
public function keep($var, $desc = null)
{
  $options = array(
  'maxObjectDepth' => 10,
  'maxArrayDepth' => 20,
  'useNativeJsonEncode' => true,
  'includeLineNumbers' => true);

  $firephp = FirePHP::getInstance(true);
  $firephp->setEnabled(true);
  $firephp->setOptions($options);
  $firephp->log($var, $desc);
}

Ważne aby pamiętać iż dla własnego bezpieczeństwa należy w środowisku produkcyjnym ustawić setEnabled na false.

Posłużę się Jobeetem, zatem moja funkcja index wygląda tak:

public function executeIndex(sfWebRequest $request)
{
  $vars = 0;
  $this->categories = Doctrine::getTable('JobeetCategory')->getWithJobs();
  $this->keep($vars, "at line: ".__LINE__);
  $vars = 12;
  $this->keep($vars, "at line: ".__LINE__);
}

drugi parametr funkcji keep służy mi jako informacja pozwalająca szybko odnaleźć miejsce z wywołaniem logera. Wynik logowania prezentuje się następująco:

Ciekawsze wyniki można uzyskać deklarując przykładową tablicę z danymi – najeżdżając kursorem myszy na wynik debugowania tablicy ukaże się okienko jak na poniższym zrzucie – możemy tutaj nieco dokładniej przyjrzeć się zwróconym wartościom.

Na koniec chciałbym zauważyć, że odświeżenie strony nie zawsze powoduje odświeżenie wyników debugowania, prowadzi to wręcz do ich utraty – należy wówczas kliknąć w Firebugu opcję Off a następnie On dzięki czemu zobaczymy aktualne dane.

Zachęcam do korzystania z FirePHP i testowania jego pozostałych funkcjonalności.

http://www.firephp.org/HQ/Use.htm

Na początek stworzymy sobie możliwość wyświetlania pól z profilu użytkownika podczas listowania. Otwieramy generator.yml z modułu sfGuardUser, który w oryginale wygląda tak:

generator:
  class: sfPropelGenerator
  param:
    model_class:           sfGuardUser
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          sf_guard_user
    with_propel_route:     1

    config:
      fields:
        password_again: { label: "Password (again)" }

      list:
        title:   User list
        display: [=username, created_at, last_login]

      form:
        class: sfGuardUserAdminForm
        display:
          "NONE":                   [username, password, password_again]
          "Permissions and groups": [is_active, is_super_admin, sf_guard_user_group_list, sf_guard_user_permission_list]

      edit:
        title: Editing User "%%username%%"

      new:
        title: New User

Interesuje nas dokładnie sekcja

list:
  title:   User list
  display: [=username, created_at, last_login]

Do wyświetlania informacji z pól z profilu użytkownika, będziemy korzystać z możliwości użycia własnych partiali.
Nas interesuje np. imię, nazwisko, oraz adres e-mail użytkownika, dlatego wprowadzamy takie modyfikacje:

list:
  title:   User list
  display: [=username, created_at, last_login, _first_name, _last_name, _email]

Następnie tworzymy 3 pratiale w katalogu sfGuardUser/templates/ :
_first_name.php

<?php echo $sf_guard_user->getProfile()->getFirstName(); ?>

_last_name.php

<?php echo $sf_guard_user->getProfile()->getLastName(); ?>

_email.php

<?php echo $sf_guard_user->getProfile()->getEmail(); ?>

Po tym

symfony cc

I po odświeżeniu strony z listowaniem użytkowników będziemy mieli także informacje o imieniu, nazwisku oraz adresie email.
Wszytko pięknie tylko po takich modyfikacjach nie można sortować po dodanych polach. A to dlatego, że generator podczas tworzenia kodu naszych template’ów sprawdza czy pole które ma być wyświetlone istnieje w modelu.
Dlatego musimy obejść to sprawdzanie poprzez zmodyfikowanie informacji o polach w listowaniu (generator.yml):

list:
  title:   User list
  display: [=username, created_at, last_login, _first_name, _last_name, _email]
  fields:
    last_name:      { is_real: true }
    first_name:     { is_real: true }
    email:          { is_real: true }

Teraz po wyczyszczeniu cache i odświeżeniu strony mamy już możliwość sortowania po polach z profilu.

Jeżeli przejdziecie teraz w środowisko dev zauważycie, że nagle zwiększyła się bardzo ilość zapytań do bazy.
A to ze względu, że dla każdego użytkownika pobierany jest osobno jego profil.
Należałoby to zoptymalizować, aby nie wywoływać niepotrzebnie tylu zapytań. Tutaj natknęliśmy się na kilka problemów, ponieważ klasa sfGuardUserPeer nie posiada metody doSelectJoinsfGuardUserProfile.
Otwieramy plik sfGuardUserPeer.php i wprowadzamy pewne modfikacje:

<?php
class sfGuardUserPeer extends PluginsfGuardUserPeer
{
  public static function doSelectJoinsfGuardUserProfile(Criteria $c, $con = null, $join_behavior = Criteria::LEFT_JOIN)
  {

    foreach (sfMixer::getCallables('BasesfGuardUserPeer:doSelectJoin:doSelectJoin') as $callable)
    {
      call_user_func($callable, 'BasesfGuardUserPeer', $c, $con);
    }

    $c = clone $c;

    if ($c->getDbName() == Propel::getDefaultDB()) {
      $c->setDbName(self::DATABASE_NAME);
    }

    sfGuardUserPeer::addSelectColumns($c);
    $startcol = (sfGuardUserPeer::NUM_COLUMNS - sfGuardUserPeer::NUM_LAZY_LOAD_COLUMNS);
    sfGuardUserProfilePeer::addSelectColumns($c);

    $c->addJoin(array(sfGuardUserPeer::ID,), array(sfGuardUserProfilePeer::USER_ID,), $join_behavior);
    $stmt = BasePeer::doSelect($c, $con);
    $results = array();

    while ($row = $stmt->fetch(PDO::FETCH_NUM)) {
      $key1 = sfGuardUserPeer::getPrimaryKeyHashFromRow($row, 0);
      if (null !== ($obj1 = sfGuardUserPeer::getInstanceFromPool($key1))) {
      } else {

        $omClass = sfGuardUserPeer::getOMClass();

        $cls = substr('.'.$omClass, strrpos('.'.$omClass, '.') + 1);
        $obj1 = new $cls();
        $obj1->hydrate($row);
        sfGuardUserPeer::addInstanceToPool($obj1, $key1);
      }
      $key2 = sfGuardUserProfilePeer::getPrimaryKeyHashFromRow($row, $startcol);
      if ($key2 !== null) {
        $obj2 = sfGuardUserProfilePeer::getInstanceFromPool($key2);
        if (!$obj2) {

          $omClass = sfGuardUserProfilePeer::getOMClass();

          $cls = substr('.'.$omClass, strrpos('.'.$omClass, '.') + 1);
          $obj2 = new $cls();
          $obj2->hydrate($row, $startcol);
          sfGuardUserProfilePeer::addInstanceToPool($obj2, $key2);
        }
        $obj1->setProfile($obj2);

      }
      $results[] = $obj1;
    }
    $stmt->closeCursor();
    return $results;
  }
}

A w pliku sfGuardUser.php, dodajemy funkcję setProfile :

<?php
class sfGuardUser extends PluginsfGuardUser
{
  public function setProfile( $profile )
  {
    $this->profile = $profile;
  }
}

Na koniec musimy tylko zmienić peer_method wywoływaną przez generator do pobierania wyników.
Otwieramy plik sfGuardUser/lib/sfGuardUserGeneratorConfiguration.class.php i dodajemy funkcję getPeerMethod:

<?php

/**
 * sfGuardUser module configuration.
 *
 * @package    sfGuardPlugin
 * @subpackage sfGuardUser
 */
class sfGuardUserGeneratorConfiguration extends BaseSfGuardUserGeneratorConfiguration
{
  public function getPeerMethod()
  {
    return 'doSelectJoinsfGuardUserProfile';
  }
}

Teraz po wyczyszczeniu cache, odświeżeniu strony ilość zapytań do bazy powinna spaść.

Na dzisiaj to tyle. Zostało jeszcze opisanie jak filtrować po polach z profilu użytkownika ale to już innym razem.

Na pierwszy ogień testów poszedł phpCodeBeautifier. Szybko jednak okazało się, że klamra otwierająca zawartość klasy musi znajdować się w tej samej linii co jej deklaracja. Istnieje opcja:

--space-before-start-angle-bracket

która pozwala wymusić jeden znak spacji przed „{„. Czemu autorzy nie pomyśleli o

--newline-before-start-angle-bracket

? Cieżko powiedzieć. Kod jest zamknięty, więc się tego nie dopisze samemu.

Istnieje jednak PHP_CodeSniffer (phpcs), który połączony z odpowiednim standardem sprawdzi składnie pliku.

Zainstalujmy „to” wszystko… Na początek instalacja samego phpcs:

apt-get install php-codesniffer

Aby aplikacja mogła sprawdzać formatowanie zgodne z symfony należy jeszcze doinstalować standard symfony. Można go znaleźć w repozytorium svn pod adresem http://subversion.assembla.com/svn/phpsymfony/Symfony%20Code%20sniffer%20standards/Symfony/.

 cd /usr/share/php/PHP/CodeSniffer/Standards && sudo svn co http://subversion.assembla.com/svn/phpsymfony/Symfony%20Code%20sniffer%20standards/ .

Do przetestowania programu stwórzymy plik:

vim ~/test.php

z odpowiednią zawartością:

<?php
class TestKlasa
{
  public function testFunction()
  {
  }
}

Uf, nareszcie możemy sprawdzić czy nasz kod jest poprawny:

phpcs --standard=Symfony ~/test.php

W wyniku czego otrzymamy:

FILE: ~/test.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
2 | ERROR | Missing file doc comment
2 | ERROR | Missing class doc comment
4 | ERROR | Missing function doc comment
--------------------------------------------------------------------------------

Działa! To znaczy są błędy, ale o to właśnie nam chodziło – aby je wykrywać. Poprawmy więc zawartość pliku:

<?php
/**
* Test file for PHP_CodeSniffer
*
* PHP versions 4 and 5
*
* @category Tests
* @package  XX
* @author   Marcin Dryka <marcin.dryka@xsolve.pl>
* @license  http://www.opensource.org/licenses/lgpl-license.php LGPL
* @version  SVN: 1
* @filesource
*/

/**
* TestKlasa
*
* @package XX
* @author  Marcin Dryka <marcin.dryka@xsolve.pl>
* @version Release: 1
*/
class TestKlasa
{
  /**
  * testFunction
  *
  * @author Marcin Dryka <marcin.dryka@xsolve.pl>
  * @access public
  * @return void
  */
  public function testFunction()
  {
  }
}

Przy tak wyglądającym pliku wynik działania phpcs jest pusty, brak błędów oznacza poprawnie sformatowany plik. Teraz potrzebna jest tylko silna wola, aby używać skryptu do sprawdzania wszystkich plików. Przy starszych aplikacjach będzie to dość kłopotliwe. Zdarzają się jednak pliki pisane od tak zwanego zera. Gdzie możemy w pełni stosować konwencje ustalone przez autorów symfony (i nie tylko).