Edycja zawartości bazy danych formularzami. Aplikacja: filmy

W artykule przedstawię technikę implementacji operacji INSERT/UPDATE/DELETE na przykładzie bazy danych prezentującej zestawienie filmów. Przykładowa baza danych zawiera trzy tabele, jedną relację jeden do wielu i jedną relację wiele do wielu. Przygotowany interfejs WWW pozwala na pełną edycję rekordów zapisanych w bazie danych.

Baza danych

Omawiany przykład wykorzystuje bazę danych przedstawioną na rys. 1. Baza ta zawiera trzy tabele: {stala}aktor{/stala}, {stala}kategoria{/stala}, {stala}film{/stala}. Tabela {stala}film {/stala}jest połączona z tabelą {stala}kategoria{/stala} relacją jeden do wielu (każdy film może należeć do dokładnie jednej kategorii). Tabele {stala}film{/stala} i {stala}aktor{/stala} są połączone relacją wiele do wielu (w każdym filmie występuje dowolnie wielu aktorów, każdy aktor występuje w dowolnie wielu filmach). Tabela haszująca relacji nazywa się {stala}film_has_aktor{/stala}.

Baza danych zawiera klucze unikalne. Są to:

• w tabeli aktor: imię i nazwisko,
• w tabeli kategoria: nazwa,
• w tabeli film: tytuł.

W ten sposób do tabeli {stala}aktor{/stala} można wstawić tylko jeden rekord {stala}Paul Newman{/stala}, do tabeli {stala}kategoria{/stala} – jeden rekord {stala}komedia sensacyjna{/stala}, zaś do tabeli {stala}film{/stala} – jeden rekord {stala}Żądło{/stala}.

Zadanie

Naszym zadaniem jest przygotowanie interfejsu WWW, który umożliwi pełną edycję zawartości bazy danych. Oznacza to, że w odniesieniu do każdej tabeli należy zaimplementować operacje:

• INSERT
• UPDATE
• DELETE

Dodatkowo należy umożliwić modyfikację powiązań {stala}kategoria-film{/stala} oraz {stala}film-aktor{/stala}.

Przykładowa aplikacja

Nasza przykładowa aplikacja zawiera menu główne, a w nim opcje:

• Strona domowa
• Wszyscy aktorzy
• Wszystkie filmy
• Wszystkie kategorie

Po przejściu do strony {stala}Wszyscy aktorzy{/stala} wyświetlane jest zestawienie zawierające wszystkie rekordy z tabeli {stala}aktor{/stala}. Ilustruje to rys. 2. Po przejściu do strony {stala}Wszystkie filmy{/stala} wyświetlane jest zestawienie zawierające wszystkie rekordy z tabeli {stala}film{/stala}. Natomiast strona {stala}Wszystkie kategorie{/stala} zawiera zestawienie wszystkich rekordów z tabeli {stala}kategoria{/stala}.

Na stronie zestawienia wszystkich aktorów dostępne jest hiperłącze: Dodaj aktora (patrz rys. 2). Pozwala ono na dodawanie rekordów do tabeli {stala}aktor{/stala}.

Analogicznie: na stronie {stala}Wszystkie filmy{/stala} znajdziemy hiperłącze Dodaj film, a na stronie {stala}Wszystkie kategorie{/stala} – hiperłącze Dodaj kategorię. Hiperłącze Dodaj film pozwala na dodawanie rekordów do tabeli {stala}film{/stala}, zaś odnośnik Dodaj kategorię służy do dodawania rekordów do tabeli {stala}kategoria{/stala}.

Po aktywacji hiperłącza Dodaj aktora przejdziemy do strony widocznej na rys. 3. Zawiera ona formularz, który umożliwia wprowadzenie imienia i nazwiska aktora. Po wypełnieniu formularz zatwierdzamy naciskając przycisk Dodaj.

Podobnie, po aktywacji hiperłącza Dodaj film ujrzymy formularz umożliwiający wprowadzanie danych filmu, zaś hiperłącze Dodaj kategorię przeniesie nas do formularza umożliwiającego wprowadzenie nazwy nowej kategorii.

Imię i nazwisko aktora w zestawieniu z rysunkiem 2 jest hiperłączem do strony prezentującej szczegółowe dane aktora. Rys. 4 przedstawia szczegółowe dane Tima Rotha. Widzimy tam – oprócz imienia i nazwiska – listę filmów, w których ten aktor wystąpił.

W identyczny sposób tytuł filmu w zestawieniu wszystkich filmów przenosi do strony ze szczegółowymi danymi filmu, zaś nazwa kategorii w zestawieniu wszystkich kategorii przechodzi do szczegółowych danych kategorii (czyli zestawienia wszystkich filmów wybranej kategorii).

Strona ze szczegółowymi danymi aktora (rys. 4) zawiera dwa hiperłącza: Edytuj oraz Usuń. Hiperłącza te umożliwiają edycję rekordu (czyli imienia i nazwiska Tima Rotha) oraz usunięcie rekordu (usunięcie Tima Rotha z bazy danych).

Po aktywacji hiperłącza Edytuj przejdziemy do formularza przedstawionego na rys. 5. Zawiera on identyczne pola jak formularz z rys. 3, ale jest wstępnie wypełniony. Edycję zatwierdzamy naciskając przycisk Zmień.

Po aktywacji hiperłącza Usuń, rekord zostanie usunięty. Po tej operacji przejdziemy do zestawienia wszystkich aktorów, widocznego na rys. 2. Oczywiście na liście tej nie pojawi się już usunięty rekord (np. Tim Roth).

Analogicznie, strona ze szczegółowymi danymi filmu zawiera hiperłącza Edytuj oraz Usuń, które umożliwiają edycję danych filmu oraz usunięcie go z bazy danych. Witryna ze szczegółowymi danymi kategorii zawiera hiperłącza Edytuj oraz Usuń, które umożliwiają edycję oraz usunięcie kategorii z bazy danych.

Przebieg wymienionych operacji w odniesieniu do tabeli aktor jest przedstawiony na rysunku 6. Wędrówkę rozpoczynamy od strony głównej. Następnie wchodzimy na stronę Wszyscy aktorzy (strona ta jest oznaczona w kodzie źródłowym komentarzami: LISTA WSZYSTKICH: AKTORZY) widoczną na rys. 2.

Z zestawienia wszystkich aktorów możemy przejść do:

• dodawania nowego aktora (hiperłącze: Dodaj aktora, rys. 3),
• do szczegółowych danych aktora (hiperłącze: imię i nazwisko, np. Tim Roth, rys. 4).

Dodawanie nowego aktora prowadzi do strony ze szczegółowymi danymi dodanego rekordu: po wypełnieniu i zatwierdzeniu formularza ze strony widocznej na rysunku 3 przejdziemy do strony z rysunkiem 4.

Edycja rekordu prowadzi do strony szczegółowych danych rekordu. Zatem ze strony z rysunkiem 5 trafiamy do strony z rysunkiem 4.

Wreszcie usunięcie aktora (czyli aktywacja hiperłącza Usuń z rysunku 4) prowadzi do zestawienia wszystkich aktorów (strona z rys. 2).

W identyczny sposób poruszamy się edytując rekordy z tabel {stala}kategoria{/stala} oraz {stala}filmy{/stala}.

Stany aplikacji

Kluczem do implementacji opisanego zadania jest ustalenie stanów aplikacji. Na każdą tabelę bazy danych przypada 14 stanów:

• dodawanie nowego rekordu:
  • formularz
  • operacja
  • sukces
  • błąd wykonania zapytania SQL/wyjątek Propel
  • błędne dane
• edycja rekordu:
  • formularz
  • operacja
  • sukces
  • błąd wykonania zapytania SQL/wyjątek Propel
  • błędne dane
• usuwanie rekordu:
  • operacja
  • sukces
  • błąd wykonania zapytania SQL/wyjątek Propel
  • błędne dane

Zatem w aplikacji filmy wystąpią 14 x 3 = 42 stany dotyczące edycji zawartości bazy danych.

Każdy stan aplikacji jest identyfikowany unikalną liczbą całkowitą.

DVTR: kategorie stanów aplikacji

Napis {stala}DVTR{/stala} określa charakterystykę stanu. Litery DVTR pochodzą od słów: database, validation, template, redirect. W miejsce liter mogą pojawić się kreski. Stanami, jakie występują w omawianej aplikacji są:

• {stala}-VT-{/stala} (formularz nowy rekord oraz formularz edycja rekordu),
• {stala}D—{/stala} (zatwierdzenie formularza oraz aktywacja hiperłącza usuń),
• {stala}—R{/stala} (sukces wykonania operacji przetwarzania formularza lub usuwania rekordu),
• {stala}–T-{/stala} (błąd przetwarzania formularza lub usuwania rekordu).

Stan: -VT-

Stan ten dotyczy formularzy: nowy rekord, edycja rekordu. Do stanu takiego można dostać się przy użyciu adresu URL, np.

index.php?id=xxx

gdzie {stala}xxx{/stala} (np. 10) jest identyfikatorem stanu. Przetwarzanie stanu wymaga:

• dodania jednego przypadku walidacji (sprawdzamy zmienną {stala}id=xxx{/stala}) w skrypcie {stala}index.php{/stala},
• dodania jednego przypadku (np. {stala}{elseif $akcja ==10}{/stala}) w szablonie.

Stan wymaga jednej zmiennej {stala}$_GET[\’id\’]{/stala}. Nie dopuszcza żadnych zmiennych w tablicy {stala}$_POST{/stala}.

Stan -VT- występuje zarówno w walidacji (plik {stala}index.php{/stala}), jak i w szablonie ({stala}plik index.tp{/stala}l).

Stan: —R

Gdy operacja na bazie danych powiedzie się, występuje stan określany jako sukces. W takim przypadku w aplikacji następuje automatyczne przekierowanie do innego stanu (stąd litera R: redirect). Jeśli powiedzie się wstawianie rekordu, to przechodzimy do strony: szczegółowe dane wstawionego rekordu. Po udanej edycji rekordu przechodzimy do strony: szczegółowe dane edytowanego rekordu. Poprawnie wykonane usuwanie rekordu przeniesie nas do strony wszystkich rekordów z danej tabeli.

Stan: –T

Błędy przetwarzania formularza (czyli: błąd wykonania zapytania SQL, wyjątek Propel lub błędne dane) są stanami oznaczanymi jako {stala}–T-{/stala}. Stan taki będzie powodował wyświetlenie pewnego komunikatu, który umożliwi użytkownikowi poprawienie danych. Stany {stala}–T-{/stala} nie występują w walidacji, ale występują w szablonie.

Rysunki 7, 8, 9 ilustrują proces przetwarzania każdej operacji: {stala}INSERT{/stala}, {stala}UPDATE{/stala} oraz {stala}DELETE{/stala}. Owalne prostokąty symbolizują stany aplikacji. Napis {stala}id=xxx{/stala} w prawym dolnym narożniku każdego owalnego prostokąta jest identyfikatorem stanu. Napisy: {stala}D—,{/stala} {stala}-VT-{/stala}, {stala}—R{/stala} oraz {stala}–T-{/stala} charakteryzują stan. Natomiast strzałki łączące obłe prostokąty wskazują kolejność występowania poszczególnych stanów w aplikacji.

Symbol uziemienia (następna akcja po akcjach błędnych {stala}–T-{/stala}) może powodować zakończenie przetwarzania (np. komunikat błędu) lub – o ile to możliwe – ponowne przejście do początku błędnej sytuacji. W przypadku błędu wstawiania nowego rekordu (stany 13, 14, rys. 7) symbol uziemienia może prowadzić ponownie do stanu 10 (wstępnie wypełniony formularz danych opatrzony komunikatami o błędach).

W przypadku błędu edycji rekordu (stany 18, 19, rys. 8) symbol uziemienia może prowadzić ponownie do stanu 15 (wstępnie wypełniony formularz danych opatrzony komunikatami o błędach). W przypadku usuwania rekordu (stany 22, 23, rys. 9) przetwarzanie kończymy komunikatem: błąd. Rysunek 10 zawiera pełne zestawienie stanów dotyczących edycji tabeli aktor.

Tabele 1, 2 oraz 3 zawierają sumaryczne zestawienie cech każdej z czternastu akcji dotyczących tabeli {stala}aktor{/stala}.

Stan: D—

Stan {stala}D—{/stala} występuje po:

• zatwierdzeniu formularza: {stala}nowy rekord{/stala},
• zatwierdzeniu formularza: {stala}edycja rekordu{/stala},
• aktywacji hiperłącza usuń.

Do stanu takiego dostajemy się za pomocą adresu URL. Jeśli dodajemy nowy rekord, to adres URL ma postać:

index.php?id=xxx

gdzie {stala}xxx{/stala} identyfikuje akcję przetwarzania formularza.

Dodawanie nowego rekordu wymaga:

• zmiennej {stala}$_GET[\’id\’]{/stala},
• zmiennych {stala}$_POST{/stala} z danymi wprowadzonymi w formularzu.

Do stanu edycji rekordu dostajemy się hiperłączem:

index.php?id=xxx&id2=yyy

gdzie {stala}xxx{/stala} jest identyfikatorem stanu, zaś {stala}yyy{/stala} identyfikatorem edytowanego rekordu. Wymaganymi zmiennymi edycji rekordu są:

• {stala}$_GET[\’id\’]{/stala} – identyfikator stanu,
• {stala}$_GET[\’id2\’]{/stala} – identyfikator edytowanego rekordu,
• zmienne {stala}$_POST{/stala} z danymi wprowadzonymi w formularzu.

Zatwierdzenie operacji usuń stosuje hiperłącze:

index.php?id=xxx&id2=yyy

gdzie {stala}xxx{/stala} jest identyfikatorem stanu, zaś {stala}yyy{/stala} identyfikatorem usuwanego rekordu. Wymaganymi zmiennymi usuwania rekordu są:

• {stala}$_GET[\’id\’]{/stala} – identyfikator stanu,
• {stala}$_GET[\’id2\’]{/stala} – identyfikator edytowanego rekordu.

Wynikiem stanu {stala}D—{/stala} (czyli wstawiania, edycji lub usuwania rekordu) jest:

• sukces (stan typu {stala}—R{/stala}),
• błąd: błędnie wykonane zapytanie SQL/ wyjątek Propel (stan typu {stala}–T-{/stala}),
• błąd: błędne dane (stan typu {stala}–T-{/stala}).

Innymi słowy: stan {stala}D—{/stala} wewnętrznie w aplikacji przechodzi w jeden z trzech podanych stanów. Do żadnego z tych trzech stanów nie można się dostać w inny sposób. Stany te są wyłącznie wynikiem przetwarzania stanu {stala}D—{/stala}.

{stala}Stan D—{/stala} nie występuje ani w walidacji (plik {stala}index.php{/stala}), ani w szablonie (plik {stala}index.tpl{/stala}). W pliku {stala}index.php{/stala} pojawia się (na samym początku, przed walidacją) przetworzenie wszystkich stanów {stala}D—{/stala}.

Stany: kolejność przetwarzania

Ważnym aspektem opisanej aplikacji jest kolejność przetwarzania stanów. Otóż w pliku {stala}index.php{/stala} najpierw należy przetworzyć wszystkie stany {stala}D—{/stala}. Następnie pojawi się walidacja danych, a w niej między innymi stany {stala}-VT-{/stala}. Kolejnymi etapami będą:

• ustalenie wymaganych danych (duża instrukcja {stala}switch{/stala} sterowana zmienną {stala}$akcja{/stala}),
• przetworzenie szablonu.

Taka kolejność przetwarzania umożliwia – w przypadku sukcesu (stan {stala}—R{/stala}) – wykonywanie wewnętrznych przekierowań. Przekierowanie takie jest realizowane przez manipulacje tablicą {stala}$_GET{/stala}. Nie wymaga wywołania funkcji {stala}header(){/stala}, odbywa się w obrębie bieżącego zapytania HTTP.

W szablonie wystąpią wyłącznie stany:

• formularz ({stala}-VT-{/stala}),
• błąd ({stala}–T-{/stala}).

W pliku index.tpl nie pojawią się stany {stala}D—{/stala} ani {stala}—R{/stala}.

Implementacja

Etap I: inicjalizacja

Skrypt {stala}index.php{/stala} rozpoczyna się od dołączenia wymaganych bibliotek oraz inicjalizacji obiektów. Faza ta, oznaczona symbolem ETAP I, kończy się utworzeniem dwóch tablic: {stala}$akcje_operacje_bd{/stala} oraz {stala}$akcje_walidacji{/stala}:

$akcje _ operacje _ bd = array(
   11, // NOWY AKTOR
   16, // EDYCJA AKTORA
   20, // USUNIĘCIE AKTORA
   ...
);

$akcje _ walidacji = array(
   ...
   10, // NOWY AKTOR - FORMULARZ
   15, // EDYCJA AKTORA - FORMULARZ
   ...
);

W tablicy {stala}$akcje_operacje_bd{/stala} umieszczamy wszystkie akcje typu {stala}D—{/stala}. Spośród akcji widocznych na zielonym tle na diagramie z rys. 10 są to akcje: 11, 16 oraz 20.

W tablicy {stala}$akcje_walidacji{/stala} umieszczamy wszystkie akcje typu {stala}-VT-{/stala}. Spośród akcji widocznych na zielonym tle na diagramie z rys. 10 są to akcje: 10 oraz 15.

Etap II: strona domyślna

Etap ten ustala stronę domyślną. Domyślnie: wyświetlamy stronę błędu. Jeśli użytkownik korzysta z adresu {stala}index.php{/stala}, to przechodzimy na stronę domową:

$akcja = 1;
if (empty($ _ GET)) {
   $akcja = 2;
}

Etap V: pobieranie danych z bazy i przekazywanie ich szablonu

Kolejna faza przetwarzania zajmuje się:

• pobraniem informacji z bazy danych,
• przekazaniem danych do szablonu.

Zarys tego etapu jest widoczny na listingu 5. W przypadku szczegółowych danych (case 6, szczegółowe dane aktora) obiekt przekazywany do szablonu (zmienna {stala}$aktor{/stala}) był utworzony na etapie walidacji.

/*
 * ETAP V
 * USTALENIE DANYCH I PRZEKAZANIE ICH DO SZABLONU
 *
 */

switch ($akcja) {

case 3:
    $c = new Criteria;
    $c->addAscendingOrderByColumn(AktorPeer::NAZWISKO);
    $c->addAscendingOrderByColumn(AktorPeer::IMIE);
    $aktorzy = AktorPeer::doSelect($c);
    $s->assign(\'aktorzy\', $aktorzy);
    break;
...

case 6:
    $s->assign(\'aktor\', $aktor);

    $filmy = FilmPeer::getFilmsByAktor($aktor->getAktorId());
    $s->assign(\'filmy\', $filmy);

    $c = new Criteria;
    $c->addAscendingOrderByColumn(FilmPeer::TYTUL);
    $c->addAscendingOrderByColumn(FilmPeer::ROK);
    $filmy = FilmPeer::doSelect($c);
    $s->assign(\'wszystkieFilmy\', $filmy);
    break;
...
}

Etap VI: przetworzenie szablonu

Ostatnim etapem jest przetworzenie szablonu. W najprostszym wypadku będzie to wywołanie metody {stala}display(){/stala}, co ilustruje listing 6.

/*
 * ETAP VI
 * PRZETWORZENIE SZABLONU
 *
 */
$s->assign(\'akcja\', $akcja);
$s->display(\'index.tpl\');

Etapy: podsumowanie

Cała aplikacja składa się z sześciu etapów. Strukturę całości ilustruje listing 7. Jeśli aplikacja będzie rozwijana, to po dodaniu do bazy danych kolejnych tabel w aplikacji pojawią się nowe stany, co wymusi rozszerzenie etapów:

• operacje na bazie danych (etap III),
• walidacja (etap IV),
• pobieranie danych i przekazywanie do szablonu (etap V)

o nowe przypadki.

...
{elseif $akcja == 10}

    
NOWY AKTOR: FORMULARZ
    {include file=\"10-nowy-aktor-formularz.tpl\"}

{elseif $akcja == 13}

    
NOWY AKTOR: WYJˇTEK PROPEL
    {include file=\"10-nowy-aktor-formularz.tpl\"}
    
BŁĄD: wyjątek Propel-a
    
{$komunikat}

{elseif $akcja == 14}

    
NOWY AKTOR: BŁĘDNE DANE
    {include file=\"10-nowy-aktor-formularz.tpl\"}
    
BŁˇD: błędne dane
{elseif ...}
...

Szablon

Analizę aplikacji zakończymy na pliku {stala}index.tpl{/stala} – głównym szablonie. Jak widać na listingu 8, w pliku tym nie występują akcje typu {stala}D—{/stala} (akcja 11: przetwarzanie formularza) ani {stala}—R{/stala} (akcja 12: sukces – przetwarzanie formularza powiodło się). Akcjami, które pojawiają się w szablonie są wyłącznie:

• wyświetlanie formularza (akcja 10),
• błąd przetwarzania formularza: wyjątek Propel (akcja 13),
• błąd przetwarzania formularza: błędne dane (akcja 14).

$ _ GET[\'id\'] = \'6\';
$ _ GET[\'id2\'] = (string)$aktor->getAktorId();

Podobna sytuacja ma miejsce w przypadku edycji oraz usuwania rekordów.

Etap III: operacje na bazie danych

W kolejnym etapie przetwarzamy akcje {stala}D—{/stala}, czyli wykonujemy operacje na bazie danych. Zarys całego przetwarzania jest przedstawiony na listingu 1. Po sprawdzeniu poprawności identyfikatora stanu (funkcje {stala}isset(){/stala}, {stala}str_ievpi()in_array(){/stala}) pojawia się instrukcja {stala}switch{/stala}. Każdy jej przypadek odpowiada jednemu stanowi {stala}D—{/stala}.

if (
    isset($_GET[\'id\']) &&
    str_ievpi($_GET[\'id\']) &&
    in_array($_GET[\'id\'], $akcje_operacje_bd)
) {

    switch ($_GET[\'id\']) {

    /*
     * NOWY AKTOR: OPERACJA
     *
     */
    case 11:
        ...
        break;

    /*
     * EDYCJA AKTORA: OPERACJA
     *
     */
    case 16:
        ...
        break;

    /*
     * USUNIĘCIE AKTORA: OPERACJA
     *
     */
    case 20:
        ...
        break;
    ...
    }
}

Przetwarzanie każdego stanu może być nieco inne. Stany wstawiania rekordu do bazy danych podpadają pod schemat widoczny na listingu 2. Jest to operacja wstawiania nowego aktora. Do operacji tej dochodzi, gdy wszystkie wymagane dane są poprawne. Sprawdzamy:

• liczbę zmiennych {stala}$_GET{/stala},
• liczbę zmiennych {stala}$_POST{/stala},
• obecność (funkcja {stala}isset(){/stala}) każdej zmiennej {stala}$_GET{/stala},
• obecność (funkcja {stala}isset(){/stala}) każdej zmiennej {stala}$_POST{/stala},
• ewentualnie: poprawność zmiennych (np. czy na podstawie id2 można utworzyć obiekt).

/*
 * NOWY AKTOR: OPERACJA
 *
 */
case 11:
    if (
        (count($_GET) == 1) && (count($_POST) == 2) &&
        isset($_POST[\'imie\']) && isset($_POST[\'nazwisko\'])
    ) {
        if (
            preg_match(\'...\', $_POST[\'imie\']) &&
            preg_match(\'...\', $_POST[\'nazwisko\'])
        ) {
            try {
                $aktor = new Aktor;
                $aktor->setImie($_POST[\'imie\']);
                $aktor->setNazwisko($_POST[\'nazwisko\']);
                $aktor->save();

                //$akcja = 12;

                /*
                 * AKCJA OZNACZONA JAKO R
                 * REDIRECT
                 * REALIZUJEMY PRZEKIEROWANIE
                 *
                 */
                $_GET[\'id\'] = \'6\';
                $_GET[\'id2\'] = (string)$aktor->getAktorId();

            } catch (PropelException $e) {

                $c = $e->getCause();
                $komunikat = $c->getNativeError();
                $s->assign(\'komunikat\', $komunikat);
                $s->assign(\'imie\', $_POST[\'imie\']);
                $s->assign(\'nazwisko\', $_POST[\'nazwisko\']);

                $akcja = 13;

            }
        } else {

            $imie = trim(preg_replace(\'...\', \'\', $_POST[\'imie\']));
            $nazwisko = trim(preg_replace(\'...\', \'\', $_POST[\'nazwisko\']));
            $s->assign(\'imie\', $imie);
            $s->assign(\'nazwisko\', $nazwisko);
            $akcja = 14;
        }
    }
    break;

Jeśli zmienne są podane, przechodzimy do wykonania akcji. Sprawdzamy poprawność danych, jakie mają być użyte w zapytaniu SQL. W przypadku błędu otrzymujemy stan 14 (błędne dane). W przypadku poprawności danych wykonujemy operację wstawiania rekordu (metoda {stala}save(){/stala} obiektu wygenerowanego przez Propel). W przypadku sukcesu mamy stan 12 (sukces). Wówczas wykonujemy przekierowanie do akcji o identyfikatorze 6. Za przekierowanie odpowiadają instrukcje:

$ _ GET[\'id\'] = \'6\';
$ _ GET[\'id2\'] = (string)$aktor->getAktorId();

W przypadku błędu mamy stan 13 (wyjątek Propel).

Etap IV: walidacja

W kolejnym etapie obsługiwane są strony wyświetlające różne dane z bazy. Szkielet przebiegu tego etapu jest widoczny na listingu 3. Listing 4 przedstawia szczegółowo przebieg walidacji danych na witrynie konkretnego aktora (np. zestawienie filmów Tima Rotha z rys. 4). Efektem ubocznym walidacji jest utworzenie obiektu {stala}$aktor{/stala}. Obiekt ten zostanie w kolejnym etapie przekazany do szablonu.

if (
    isset($_GET[\'id\']) &&
    str_ievpi($_GET[\'id\']) &&
    in_array($_GET[\'id\'],$akcje_walidacji)
) {

    switch ($_GET[\'id\']) {


    /*
     * STRONA DOMOWA
     *
     */
    case 2:
        ...
        break;

    /*
     * LISTA WSZYSTKICH: AKTORZY
     *
     */
    case 3:
        ...
        break;

    /*
     * LISTA WSZYSTKICH: FILMY
     *
     */
    case 4:
        ...
        break; 
    ...
    }  
}

/*
 * SZCZEGÓŁY: AKTOR
 *
 */
case 6:
    if (
        (count($_GET) == 2) &&
        isset($_GET[\'id2\']) &&
        str_ievpi($_GET[\'id2\']) &&
        ($aktor = AktorPeer::retrieveByPK($_GET[\'id2\']))
    ) {
        $akcja = $_GET[\'id\'];
    }
    break;

Instrukcje if w walidacji (listingi 3 oraz 4) odwołują się to tablicy {stala}$_GET{/stala}. Fakt ten wykorzystują przekierowania omówione w etapie III.