Dziś pora na trzeci artykuł z serii "wzorce w praktyce". Tym razem postanowiłem omówić praktyczne zastosowanie mniej znanego i stosowanego (w programowaniu w php) wzorca.

Każdy z Was zapewne wie co to jest transakcja bazodanowa. Jeśli jednak nie, to przypomnę, że transakcja w systemach baz danych polega na tym, że określony zbiór zapytań wykona się poprawnie w całości lub wogóle żadne zapytanie nie zostanie wykonane (de facto "nie wykona się" jest błędnym określeniem, raczej "nie zostanie zatwierdzone"). Więcej na ten temat znajdziecie na wikipedii. Transakcja jest implementacją wzorca projektowego koordynator, a raczej rozbudowanej specjalizacji tego wzorca o nazwie "Zatwierdzanie trójfazowe" (Three-Phase Commit) - właśnie tą odmianę Koordynatora będe omawiał.

Wyjątkowo w skrócie opiszę ideę tego wzorca, gdyż jest on mniej powszechny niż dwa poprzednie wzorce opisywane przeze mnie. Uczestnikami są Koordynator, Użytkownik, Zadanie oraz Klient. Klient zleca Koordynatorowi do wykonania Zadanie, które jest podzielone na kilka części, jedna część Zadania może być wykonana tylko przez jednego Użytkownika. Rola Koordynatora polega na zapewnieniu spójności systemu, czyli podzielne Zadanie musi się wykonać w całości lub żadna z części tego Zadania przydzielona do jednego Użytkownika nie może się w ogóle wykonać.

Przedstawienie problemu

W naszym przykładzie Zadaniem będzie zaktualizowanie jakiegoś rekordu w kilku zdalnych i niezależnych usługach sieciowych będących na różnych serwerach, komunikacja odbywać się może przykładowo przez SOAP. Dla nas ważne jest, aby w każdej usłudze sieciowej był rekord o tym samym stanie, nie możemy dopuścić do sytuacji w której rekord w jednej z usług ma inny stan niż ten rekord w pozostałych usługach.

Rozwiązanie nie stosując Koordynatora

[PHP]
//tablica obiektów reprezentujących różne usługi sieciowe
//dla ułatwienia przyjmuję, że mają taki sam interfejs - jeśli
//tak nie jest, można zastosować wzorzec Adapter opisywany w pierwszym
//artykule z cyklu
$services = ...;
 
//aktualny rekord, który ma być zapisany w zdalnych usługach
$record = ...;
foreach($services as $service)
{
  //zapisanie rekordu w jednej ze zdalnych usług
  $service->save($record);
}

Kod ten będzie działał, ale jeśli pewnego razu wystąpi problem z połączeniem z jedną ze zdalnych usług lub z innych nieistotnych powodów rekord nie zostanie zapisany, to stracimy spójność - ten sam rekord będzie miał inne wartości w różnych usługach.

Rozwiązanie problemu

Wydzielamy dwie klasy: Koordynatora (Coordinator) oraz Użytkownika (Coordination).

Najpierw zajmiemy się szkieletem klasy Użytkownika (Coordination). Obiekt, który może być koordynowany powinien umieć określić (nie wykonując swojej części zadania) czy wykonanie zadania się powiedzie (metoda prepare()), anulować wykonywanie zadania jeśli metoda prepare() zwróciła false - obiekt ten nie jest gotowy na jego wykonanie (metoda abort()). Powinien również umieć zatwierdzić (wykonać) zadanie (metoda commit()) oraz opcjonalnie wycofać zmiany, które nastąpiły po pomyślnym zatwierdzeniu (metoda rollback()).

[PHP]
class Coordination
{
  //obiekt jednej usługi zdalnej
  private $service = null;
  private $state = null;
  private $isAborted = false;
 
  public function __construct($service)
  {
    $this->service = $service;
  }
 
  /**
   * @return bool Czy zadanie ma szansę się powieść?
   */
  public function prepare()
  {
    try
    {
      //wykonanie jakiegoś testowego żądania, można np. pobrać w tym
      //żądaniu obecny obiekt rekordu który ma być zaktualizowany,
      //aby przy ewentualnym wywołaniu metody rollback() obiekt ten dysponował
      //stabilnym (przed wykonaniem zadania) stanem rekordu.
      $this->state = $this->service->test();
    }
    catch(Exception $e)
    {
      //załóżmy, że jeśli zostanie wyrzucony wyjątek, to żądanie testowe nie powiodło się
      //poprawność testu można stwierdzić również np. po wartości zwracanej
      return false;
    }
 
    return true;
  }
 
  /**
   * Anulowanie wykonania zadania
   */
  public function abort()
  {
    $this->isAborted = true;
    $this->state = null;
  }
 
  /**
   * Zatwierdzenie zadania
   * @throws Exception Zadanie nie powiodło się
   */
  public function commit()
  {
    if($this->isAborted)
    {
      throw new LogicException('Zadanie zostało anulowane');
    }
 
    $this->service->doTask(...);
  }
 
  /**
   * Przywrócenie starego stabilnego stanu
   */
  public function rollback()
  {
    $this->service->doTask($this->state);
  }
}

W zamyśle metoda abort() wykona się jeśli metoda prepare() zwróci false, jeśli jednak zwróci true to powinna zostać wykonana metoda commit(). Jeśli metoda commit() wyrzuci jakiś wyjątek (zadanie nie powiodło się), to powinna zostać wykonana metoda rollback(). Pamiętajmy jednak, że jeśli metoda prepare() i-tego obiektu Użytkownika zwróci false, to mają zostać wywołane metody abort() obiektów od 0 do i-1, gdyż dany obiekt który uważa że nie jest w stanie wykonać zadania, nie musi anulować swojej gotowości do jego wykonania, gdyż sam powiedział że się nie przygotował ;) To samo tyczy się metody commit(), jeśli i-ty obiekt wyrzuci w niej wyjątek, to powinna zostać wywołana metoda rollback() obiektów od 0 do i-1, gdyż i-ty obiekt tego zadania nie wykonał.

Klasa Koordynatora powinna umieć zarejestrować Użytkowników (metoda register()) oraz w skoordynowany sposób wykonać zadanie (metoda commit()).

[PHP]
class Coordinator
{
  private $coordinations = array();
  private $index;
 
  public function register(Coordination $coordination)
  {
    $this->cordinations[] = $coordination;
  }
 
  public function commit()
  {
    $count = count($this->coordinations);
    $abort = false;
    //sprawdzenie, czy wszyscy uczestnicy są gotowi na wykonanie swojej części zadania
    for($this->index=0; $this->index < $count; $this->index++)
    {
      if(!$this->coordinations[$this->index]->prepare())
      {
        $abort = true;
        break;
      }
    }
 
    //jeden z Użytkowników nie jest gotowy na wykonanie zadania, anuluj zadanie
    if($abort)
    {
      for($i=($this->index-1); $i >= 0; $i--)
      {
        $this->coordinations[$i]->abort();
      }
 
      return false;
    }
 
    try
    {
      //zatwierdź zadanie
      for($this->index=0; $this->index < $count; $this->index++)
      {
        $this->coordinations[$this->index]->commit();
      }
    }
    catch(Exception $e)
    {
      //jeden z Użytkowników nie zdołał zatwierdzić zadania, wycofaj zmiany
      for($i=($this->index-1); $i >= 0; $i--)
      {
        $this->coordinations[$i]->rollback();
      }
 
      return false;
    }
 
    return true;
  }
}

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

Zwiń
Czytaj na blogu autora...

Zend Framework oferuje wiele różnych sposobów na przechowywanie wersji językowych. Spośród wszystkich wymienionych, najbardziej zachwalany jest Zend_Translate_Adapter_Gettext. Adapter ten, w przeciwieństwie do większości pozostałych, wymaga narzędzi do stworzenia odpowiedniego pliku (o rozszerzeniu mo), który nie jest możliwy do odczytania przez człowieka. Dokumentacja poleca skorzystanie w tym

Ostatnio w wolnych chwilach trochę zastanawiałem się, jak mógłby wyglądać następca PHP. Nie chodzi mi o jakieś mityczne PHP 7, ale o zwyczajne wzięcie się i zaprojektowanie tego języka od zera, na wstępie wyrzucając wszystkie irytujące niedociągnięcia. W tym wpisie chciałbym podzielić się wynikami tego eksperymentu myślowego.

Few minutes ago Brent Shaffer asked on the Twitter Which is more standard, „public static function” or „static public function”? I was curious about it, so I’ve checked which convention is used in my favourite Symfony Project. Of course, I haven’t got enough time to check it manually, class by class, so I wrote simple [...]

W dniu dzisiejszym na oficjalnym blogu Google pojawiła się informacja o wydaniu stabilnej wersji przeglądarki, oznaczonej numerem 4. Tym samym z fazy beta wyszły dwie najbardziej oczekiwane funkcjonalności – rozszerzenia i synchronizacja zakładek. Rozszerzenia (extensions) są “prostymi” skryptami napisanymi w języku Javascript, znacznie wzbogacającymi interfejs przeglądarki oraz dodają do niej

Nie raz spotkałem się z problemem implementacji wielostronicowych formularzy w projektach w których uczestniczyłem, zazwyczaj były to formularze rejestracji, które składały się z 2-4 kroków. Podstawowe problemy które należy rozwiązać przy wykonywaniu formularza tego typu:

• możliwie jak najprostszy, spójny i elastyczny sposób przetwarzania formularza, aby ewentualne dodanie nowego pola lub całego formularza kosztowało jak najmniej nakładu pracy
• napisanie kodu, który będzie można również wykorzystać w przyszłości w innym projekcie

Istnieją dwa główne mechanizmy przechowywania danych z formularzy z poprzednich stron / kroków. Na pierwszy rzut oka zaprzęgnięcie sesji w tym celu wydaje się dobrym rozwiązaniem, jednakże czy tak w rzeczywistości jest? Sesja może wygasnąć podczas wypełniania długiego formularza lub też formularz może nie zostać w pełni wypełniony, co skutkuje przechowywaniem śmieci w sesji (rzutuje to również na wydajność). Oczywiście, można napisać coś w rodzaju garbage collection aby rozwiązać ten drugi problem, ale jest też inne rozwiązanie - przekazywanie danych z poprzednich kroków w ukrytych polach formularza. To również nie jest doskonałe, ale w mojej ocenie przysparza mniej problemów niż sesja.

Jeśli wiemy w jaki sposób przekazywać dane między żądaniami, zobaczmy jak to by wyglądało w praktyce.

(pseudokod)

[PHP]
$forms = array(/* tablica obiektów formularzy dla poszczególnych stron*/);
 
if(/*wysłano formularz*/)
{
  $page = /*strona obecnego formularza, załóżmy że numerowanie zaczyna się od 0 */;
  $values = /*dane wysłane postem*/;
  $fail = null;//pierwszy formularz, który nie przeszedł walidacji
 
  //waliduj wszystkie formularze do ostatnio wysłanego
  for($i=0; $i<$page; $i++)
  {
    if(!$forms[$i]->isValid($values))
    {
      $fail = $forms[$i];
      break;
    }
  }
 
  //wystąpił błąd
  if($fail)
  {
    //wyświetl $i-ty formularz z komunikatami błędów
    //oraz poprawnie zweryfikowane formularze jako ukryte pola
  }
  else
  {
    if(/* wysłano i zweryfikowano formularze ze wszystkich stron */)
    {
      //zapisanie danych do bazy danych i przekierowanie
    }
  }
}
 
if(!$fail)
{
  //wyświetl obecny formularz
  echo $forms[$page];
  for($i=0; $i<$page; $i++)
  {
    //wyświetl poprzednie formularz jako ukryte pola formularzy
  }
}

W powyższym rozwiązaniu cała logika obsługi wielostronicowego formularza jest skumulowana w jednym miejscu. To znacznie lepsze rozwiązanie niż obróbka formularzy z kolejnych kroków w innej akcji kontrolera. Dzięki powyższemu rozwiązaniu dodawanie kolejnych formularzy nie stanowi problemu, należy jedynie do tablicy $forms dodać kolejny obiekt formularza (lub tablicę reprezentującą formularz?) na odpowiednim miejscu oraz ewentualnie zmienić kod wykonywany po weryfikacji wszystkich formularzy.

Pierwszy punkt z listy przedstawionej na początku artykułu został spełniony: sposób przetwarzania jest dosyć prosty, spójny i elastyczny. Pozostaje problem przenośności kodu.

Plugin do obsługi wielostronicowych formularzy dla symfony

Swego czasu napisałem plugin do obsługi wielostronicowych formularzy dla frameworku symfony. Jego główne zadania to rozdzielanie wartości parametrów, walidacja poszczególnych formularzy oraz ukrycie przed programistą problemu przenoszenia danych między żądaniami.

Tworzenie własnego wielostronicowego formularza.

[PHP]
class Form extends psPageableForm
{
  public function setup()
  {
    $this->addForm(new Form1());
	$this->addForm(new Form2());
	$this->addForm(new Form3());
 
	$this->setNameFormat('form[%s]');
  }
}

Jednym ze sposobów stworzenia wielostronicowego formularza jest nadpisanie klasy psPageableForm i w metodzie setup (lub configure) dodanie kolejnych formularzy.

Przetwarzanie formularza tego typu będzie zbliżone do tego zaprezentowanego na pierwszym listingu - algorytm jest niemalże ten sam, z tą różnicą, że część zadań wykonują klasy pluginu.

[PHP]
//kontroler
public function executeProcessForm(sfWebRequest $request)
{
  $page = (int) $request->getParameter('step', 1);
  $form = $request->hasAttribute('form') ? $request->getAttribute('form') : new Form();
  $form->setPage($page);
 
  if($request->isMethod('post'))
  {
    //jeśli ta metoda została wywołana po błędzie walidacji poprzedniego formularza
	//nie przeprowadzaj walidacji
    if($request->getAttribute('return') != 1){
      $form->bind($request->getParameter('form'));
      if(!$form->isValid()){
        //numer strony to numer pierwszego niepoprawnego formularza
        $page = $form->getFirstInvalidForm()->getOption('page');
        $request->setParameter('step', $page);
 
        //utawić atrybuty żądania, aby przekazać zwalidowany formularz
        $request->setAttribute('return', 1);
        $request->setAttribute('form', $form);
 
        //wywołanie rekurencyjne akcji aby wyświetlić formularz
        //który nie przeszedł walidacji
        return $this->executeProcessForm($request);
 
      //zweryfikowano ostatni formularz
      }elseif($page > $form->getPages()){        
        //zapisanie danych do bazy
        $this->redirect(/*przekierowanie*/);
      }
    }
  }
  else
  {
    $form->setPage(1);
  }
 
  $this->form = $form;
}
 
//widok
echo $form->getCurrentForm();
//wyświetlenie ukrytych pól formularza
echo $form->persist();

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

Zwiń
Czytaj na blogu autora...

Od piątku mamy możliwość korzystać z odświeżonej dokumentacji Zend Framework. Oprócz zmian w wyglądzie (kolorowanie składni – nareszcie!), wprowadzono bardzo pomocną funkcjonalność – możliwość wyboru wersji frameworka. Dzięki temu wyszukiwanie informacji do wersji, która nas interesuje jest znacznie prostsze. Dokumentację można przeglądać od wersji 1.0, do najbardziej aktualnej 1.10, która jest