Polska Społeczność Symfony

Do napisania poniższego tekstu zainspirował mnie znaleziony niedawno przeze mnie bardzo prosty ale jednocześnie przydatny plugin sfDoctrineGuardLoginHistoryPlugin autorstwa Christiana Schaefera. Plugin odpowiedzialny jest za odnotowywanie w bazie danych każdego zalogowania i wylogowania dowolnego użytkownika (trzeba najpierw zainstalować najpopularniejszą spośród wszystkich wtyczek: sfDoctrineGuardPlugin). W tym krótkim artykule chciałbym zaprezentować jak wygodnym i jak potężnym narzędziem są zdarzenia w symfony.

zdarzenia (symfony events)

W dużym skrócie, zdarzenia to mechanizm polegający na podpinaniu implementowanych funkcjonalności pod pewną „etykietę” (jakąś wybraną nazwę), np. „xyz„. W trakcie działania skryptu pada komenda „uwaga wszyscy! xyz!” – i zaraz po tym wykonywane są wszystkie czynności podwiązane pod tą etykietę. Dzieje się to automatycznie, przy czym trzeba określić w plikach konfiguracyjnych (pluginu lub całego projektu) które czynności są podpięte pod które zdarzenia.

Przykładowo, złożenie przez klienta zamówienia w koszyku sklepu internetowego, mogłoby oznaczać:

• zapisanie danych dotyczących zamówienia,
• wysłanie klientowi maila ze szczegółowymi informacjami dotyczącymi zamówienia, płatności itp.,
• dodanie tego klienta do odpowiedniej grupy na podstawie asortymentu jaki nabył (potencjalne kampanie marketingowe),
• zapisanie przypomnienia dla pracowników sklepu w celu namówienia klienta do ponownych zakupów – przypomnienie wyświetli się pracownikom np. miesiąc po złożeniu zamówienia itd.

Na tym przykładzie widać, jak wiele różnych czynności zostanie wymuszonych przez wykonanie innej czynności. Pojawia się pytanie – jak to zapisać?

1. można oczywiście obudować to elegancko w metody OOP i wywoływać je za każdym razem kiedy mamy do czynienia ze „złożeniem rzez klienta zamówienia„,
2. ale można też użyć w tym celu własnych zdarzeń: określamy jakie są zdarzenia, podpinamy pod nie odpowiednie metody odpowiednich klas – i w każdym miejscu w kodzie gdzie „klient składa zamówienie” rejestrujemy to zdarzenie

Najważniejszą zaletą drugiego rozwiązania wg mnie jest wygoda/elastyczność. Kiedy już mamy zdefiniowane zdarzenia i metody, wywołanie ich w innym miejscu to tylko jedna linijka – zarejestrowanie zdarzenia („uwaga wszyscy! xyz!„). Dalej: przejrzystość kodu, widziana z poziomu całego projektu (zwłaszcza kiedy wykonanie jednej czynności wymusza wykonywanie wielu innych – a to się często zdarza w dużych projekach). Pierwsze rozwiązanie, czyli bezpośredni ciąg wywołań metod „jedna po drugiej”, może zaciemnić obraz całości i z pewnością utrudni przyszłe modyfikacje. Wreszcie po trzecie, każde zdarzenie to swoista bramka pod którą można podpiąć cokolwiek innego w projekcie. To tak jakby zamiast zamurowywać ściany, wstawiać drzwi – aby się dostać do środka, nie trzeba kuć ścian – wystarczy otworzyć te drzwi.

zdarzenie w sfDoctrineGuardLoginHistoryPlugin

Symfony ma kilkadziesiąt wbudowanych zdarzeń (dokumentacja symfony 1.4). Jedno z nich – user.change_authentication – zostało wykorzystane właśnie w sfDoctrineGuardLoginHistoryPlugin. W pliku konfiguracyjnym config/sfDoctrineGuardLoginHistoryPluginConfiguration następuje podwiązanie zdarzenia z określoną metodą:

  public function initialize()
  {
    $this->dispatcher->connect('user.change_authentication', array('UserLoginHistoryTable', 'writeLoginHistory'));
  }

Zgodnie z dokumentacją symfony, zdarzenie to jest rejestrowane (tzn. „dzieje się”) zawsze kiedy zmienia się stan uwiarygodnienia (login/logout) użytkownika (event is notified whenever the user authentication status changes). Pod to zdarzenie podpięta jest tylko jedna metoda, UserLoginHistoryTable::writeLoginHistory(), która polega na zapisaniu w bazie danych informacji o odpowiednio: zalogowaniu bądź wylogowaniu danego użytkownika.

  static public function writeLoginHistory(sfEvent $event)
  {
    $sessionUser = $event->getSubject();
    $params = $event->getParameters();
    if(true === $params['authenticated'])
    {
      $userId = $sessionUser->getGuardUser()->id;
      $sessionUser->setAttribute('user_id', $userId, 'sfDoctrineGuardLoginHistoryPlugin');
      self::createHistoryEntry('login', $userId);
    }
    else
    {
      $userId = $sessionUser->getAttributeHolder()->remove('user_id', null, 'sfDoctrineGuardLoginHistoryPlugin');
      self::createHistoryEntry('logout', $userId);
    }
  }

  protected static function createHistoryEntry($state, $userId)
  {
    $history = new UserLoginHistory();
    $history->state = $state;
    $history->user_id = $userId;
    $history->ip = getenv('HTTP_X_FORWARDED_FOR') ? getenv('HTTP_X_FORWARDED_FOR') : getenv('REMOTE_ADDR');
    $history->save();
  }

W efekcie, nie musimy wchodzić wgłąb kodu sfDoctrineGuardPlugin, rozdłubywać mechanizm logowania i modyfikować go, wstawiając wywołanie w/w metody. Tak naprawdę to w ogóle nie musimy wiedzieć jak skonstruowany jest ten mechanizm. Wiemy tylko że (wy)logowanie rejestruje zdarzenie user.change_authentication i się pod nie podpinamy – nic więcej nas nie interesuje a jednocześnie wszystko działa tak jak powinno. Proste, szybkie, skuteczne i efektywne.

Predefiniowane w symfony zdarzenia stanowią zatem swoisty interfejs pod który można się niesamowicie łatwo podpiąć, jak widać na przykładzie omawianego pluginu (symfony pozostawia nam wiele drzwi które możemy otwierać bez konieczności burzenia ścian). W większych projektach oczywiście warto tworzyć własne zdarzenia i podpinać pod nie swoje funkcjonalności. Wówczas włączenie/wyłączenie danego mechanizmu to tylko za(od)komentowanie jednej linijki, w której rejestruje się daną metodę dla danego zdarzenia.

PS to mój pierwszy artykuł po polsku – mam nadzieję że piszę w sposób w miarę zrozumiały