From 654a9cae43358c7eecf3b522e9876aa7815e2453 Mon Sep 17 00:00:00 2001
From: Fabio Bas
-Aplikacja jest instancją TApplication lub klasy po niej dziedziczącej. Zarządza modułami dostarczającymi różnorodne funkcjonalności i ładuje je w razie potrzeby. Dostarcza użytkownikowu końcowemu serwisy.
-Jest centralnym miejscem do przechowywania różnych parametrów używanych w aplikacji. W aplikacji PRADO instancja aplikacji jest jedynym globalnie dostepnym obiektem poprzez wywołania funkcji Prado::getApplication().
-
-Aplikacje są konfigurowane poprzez konfigurację aplikacji. Są zazwyczaj tworzone w skrypcie wejściowym w podobny do następującego sposób,
-
-Minimalna aplikacja PRADO zawiera dwa pliki: plik wejściowy i plik szablonu. Muszą być one zorganizowane w następujący sposób.
-
-Produktywna aplikacja PRADO zazwyczaj potrzebuje więcej plików. Może ona zawierać plik konfiguracji aplikacji application.xml w podstawej ścieżce aplikacji protected. Strony mogą być zorganizowane w foldery, część z nich może zawierać pliki konfiguracji strony config.xml. Aby dowiedzieć się wiecej, zajrzyć do sekcji konfiguracji.
-
-Osadzanie aplikacji PRADO zazwyczaj wiąże się z kopiowaniem folderów. Na przykład, aby osadzić powyższą minimalną wersję aplikacji na innym serwerze należy wykonać następujące kroki.
-
-Tak jak cykle życia strony tak aplikacja również posiada cykle życia. Moduły aplikacji mogą rejestrować zdarzenia dla cykli życia.
-Kiedy aplikacja znajduje się w konkretnym cyklu i wywołuje odpowiednie zdarzenie, zarejstrowana metoda modułu jest wywoływana automatycznie.
-Moduły załaczone w oficjalnym wydaniu PRADO, takie jak TAuthManager, używają tego sposobu aby wyknać swoje zadania.
-
-Cykle życia aplikacji mogą zostać przedstawione następująco:
-
-Prado jest przede wszystkim frameworkiem służącym do prezentacji, mimo to nie jest on ograniczony jedynie do ten funkcjonalności.
-Framework skupia się na programowaniu webowym, które w większości czasu ma do czynienia z interakcją z użytkownikiem, bazując na programowaniu sterowanym zdarzeniami (ang. event driven) oraz bazującym na komponentach (ang. component based),
-tak by deweloper był bardziej produktywny. Następujące drzewko klas pokazuje główne klasy dostarczanych przez PRADO.
-
-Kiedy PRADO przetwarza żądanie strony, jego diagram obiektów statycznych wygląda następująco.
-
-Komponent jest instancją klasy lub klasy potomnej TComponent. Klasa bazowa TComponent implementuje mechanizm właściwości oraz zdarzeń kompomentu.
-
-Właściwość kompoenentu może być postrzegana jako publiczna zmienna opsiującą określoną cechę/właściwość komponentu, taką jak kolor tła, rozmiar czcionki, itp. Właściwość jest definiowana poprzez istnienie metody getter i/lub setter w klasie. Na przykład w TControl definiujemy właściwość ID komponentu używając następujących funkcji typu getter i setter,
-
-Aby pobrać lub ustawić właściwość ID, postępuj jak poniżej (tak jakbyś miał do czynienia ze zmienną):
-
-Właściwość jest "tylko do odczytu" jeśli posiada metodę getter a nie posiada metody setter. Odkąd nazwy metod w PHP nie są zależne od wielkiej bądź małej litery, właściwości również są niewrażliwe na wielkość liter. Klasa kompomentu dziedziny wszystkie właściwości rodzica.
-
-Subwłaściwość jest właściwością właściwości typu obiektowego. Dla przykładu TWebControl posiada właściwość Font, która jest typu TFont. Wtedy właściwość Name właściwości Font jest subwłaściwością w stosunku do TWebControl.
-
-Aby pobrać lub ustawić subwłaściwość Name należy użyć następującej metody:
-
-Zdarzenia komponentu są specjalnymi właściwościami, które pobierają nazwy metod jako swoje wartości. Przypisując (ustawiając) metodę do zdarzenia (will hook up the method ) do miejsca gdzie zdarzenie jest wywoływane. Dzięki temu zachowanie komponentu może zostać zmodyfikowane w sposób, który nie był przewidziany podczas fazy dewelopowania komponentu.
-
-Zdarzenie komponentu jest definiowane poprzez istnienie metody, której nazwa zaczyna się przedrostkiem on. Nazwa zdarzenia jest nazwą metody i z tego powodu jest niewrażliwa na wielkość liter. Na przykład w komponencie TButton mamy:
-
-Przestrzeń nazw odnosi się do logicznego pogrupowania nazwy klas w taki sposób, że moga być one odróżniane od innych klas, których nazwy są identyczne. Ponieważ PHP nie wspiera przestrzeni nazw sam w sobie, nie można stworzyć instancji dwóch klas, które mają tą samoą nazwę ale różne definicje. Aby odróżniać się od klas użytkowników wszystkie klasy PRADO posiadają prefix 'T' (oznaczający 'Type' - z angielskiego: typ). Zachęcamy do nazywania własnych klas w ten sposób. W odróznieniu można dodawać prefiksy klas zaczynające się dowolną inną literą (lub grupą liter).
-
-Przestrzeń nazw w PRADO jest postrzegana jako folder zawierający jednen lub więcej plików klas. Poprzez poprzedzania nazwy klasy przestrzenią nazw klasa może zostać określona jednoznacznie. Każda przestrzeń nazw jest w PRADO określona w następujący sposób:
-Aplikacja
-Organizacja folderów
-
-
-
-
-Osadzanie aplikacji
-
-
-
-Cykle życia aplikacji
-
-
-
Architektura
-
-
-
-
-
Komponenty
-Właściwości komponentu (ang. component properties)
-Subwłaściwości (ang. subproperties)
-Zdarzenia komponentu
-Przestrzenie nazw (ang. namespaces)
-
-By używać przestrzeni nazw w kodzie, napisz:
-
-Aby zobaczyć więcej informacji o definiowaniu aliasów zobacz sekcję konfigurowanie aplikacji. -
- --Tworzenie instancji komponentu oznacza tworzenie instancji klasy komponentu. Rozróżniamy dwa typy instancji komponentu: statyczną i dynamiczną. Utworzone komponenty nazywane są odpowiednio komponentami statycznymi i dynamicznymi. -
- -
-Dynamiczne tworzenie instancji komponentów oznacza tworzenie instancji komponentu w kodzie PHP. Wygląda to identycznie jak zwyczajne tworznie komponentów w PHP. Komponent może zostać dynamicznie utworzony w jeden z poniższych sposobów w PHP:
-
-Statyczne tworzenie instancji komponentów odnosi się do tworznenia komponentów poprzez konfigurację. Proces tworzenia odbywa się po stronie frameworku. Na przykład w konfiguracji aplikacji można skonfigurować moduł, który zostanie załadowany podczas uruchamiania aplikacji. Zatem moduł jest statycznym komponentem stworzonym przez framework. Statyczne tworzenie instancji jest często wspólnie używane w szablonach. Każdy tag komponentu w szablonie określa komponent, który będzie automatycznie stworzony przez framework, kiedy szablon będzie ładowany. Na przykład w szablonie strony następujący tag doprowadzi do stworzenia komponentu TButton na stronie:
-
-Kontrolka jest instancją klasy TControl lub jej dziecka. Kontrolka jest komponentem definiowanym z dodatkiem interfejsu użytkownika. Klasa bazowa TControl definiuje relację rodzic-dziecko among controls which reflects the containment relationship among user interface elements. -
- --Kontrolki są powiązane z sobą za pomocą relacji rodzic-dziecko. Każda kontrolka rodzica może posiadać jedną lub więcej kontrolek dzieci. Kontrolka rodzica jest in charge of the state transition of its child controls. Wynik renderowanie kontrolki dziecka jest zazwyczaj używany do stworzenia warstwy prezentacji kontrolki rodzica. Relacja rodzic-dziecko brings together controls into a control tree. Strona jest korzeniem drzewka, której warstwa prezentacji jest zwracana dla użytkownika końcowego. -
-
-Relacja rodzic-dziecko jest zazwyczaj ustalana przez framework poprzez szablony. W kodzie można bezpośrednio określić kontrolkę jako dziecko innej kontrolki stosując jedną z następujących metod:
-
-Każda kontrolka ma właściwość ID, która jednoznacznie identyfikuje ją samą spośród jej rodzeństwa. W dodatku każda kontrolka posiada właściwość UniqueID oraz ClientID, która może zostać użyta do identyfikacji "globalnej" kontrolki w drzewku gdzie znajduje się ta kontrolka. Właściwości UniqueID oraz ClientID są bardzo podobne. Pierwsza jest używana przez framework do określenia położenia odpowiedniej kontrolki w drzewku, druga jest głównie używana po stronie klienta jako ID w tagach HTML. Ogólnie rzecz ujmując nie powinno się polegać na tak sprecyzowanym formacie UniqueID lub ClientID. -
- --Każda kontrolka posiada kontener nazw, który jest kontrolką tworzącą unikalną przestrzeń nazw dla rozróżnienie pomiędzy kontrolkami o tych samych ID. Na przykład kontrolka TRepeater tworzy wiele pozycji, które posiadają kontrolki-dzieci o tych samych ID. Aby rozróżnić te kontrolki-dzieci, każda pozycja służy jako kontener nazw. Dzięki temu, kontrolka-dziecko może zostać jednoznacznie zidentyfikowana używając ID swojego kontenera nazw razem z swoim własnym ID. Powinieneś teraz zrozumieć, że właściwości UniqueID i ClientID bazują (wynikają?) na kontenerze nazw. -
--Kontrolka może służyć jako kontener naz jeśli implementuje interfejs INamingContainer. -
- --HTTP jest protokołem bezstanowym, co oznacza, że nie dostarcza on funkjonalności wspierającej kontynuowanie interakcji pomiędzy użytkownikiem a serwerem. Każde żądanie (ang. request) jest rozpatrywane jako pojedyńcze i niezależne w stosunku do innego żądania. Jednakże, aplikacja webowa często potrzebuje wiedzieć co użytkownik zrobił w poprzednich żądaniach. Dlatego wprowadzono sesje by pomóc zapamiętać te informacje o stanie. -
--PRADO zapożycza koncept stanu widoku oraz stanu kontrolki z ASP.NET Microsoftu by dostarczać dodatkowego stanowego mechanizmu programowania (ang. stateful programming mechanism). Wartość zachowana w stanie widoku lub stanie kontrolki może być dostępna w następnym żądaniu jeśli nowe żądanie pochodzi od wysłania formularza (ang. form submissions) (nazywanej postback'iem) do tej samej strony przez tego samego użytkownika. Różnica pomiędzy stanem widoku a stanem kontrolki wynika z tego iż pierwsza może zostać wyłączona a druga nie. -
-
-Stan widoku i stan kontrolki są zaimplementowane w TControl. Są one zazwyczaj używane do zdefiniowania różnych właściwościu kontrolki. By zapisać i przywrócić wartości ze stanu widoku lub stanu kontrolki, należy użyć następujących sposobów:
-
-Zobaczywszy prostą aplikację "Witaj Świecie" stworzymy teraz bardziej skomplikowaną aplikację "Wisielca". -W tej grze gracz musi odgadnąć słowo podając litery w zadanym czasie. Jeśli odgadnie prawidłowo litera pojawi się w słowie. Gracz może tak długo kontynuować zgadywanie dopóki liczba pomyłek znajduje się w zdefiniwanym na początku zakresie. -Gracz wygrywa grę jeśli znajdzie słowo zanim przekroczy dozwoloną liczbę pomyłek, w przeciwnym przypadku przegrywa. -
-
-Aby ułatwić stowrzenie tej gry, pokażemy diagram zmiany stanów gry następująco
-
-Ciąg dalszy nastąpi...
-
-Moduł jest instancją klasy implementującej interfejs IModule. Moduł jest zazwyczaj zaprojektowany by dostarczać określonej funkcjonalności, która może być podłączona do aplikacji PRADO i dzielona wśród wszystkich komponentów aplikacji. -
--PRADO używa konfiguracji aby określić kiedy załadować moduł, jaki rodzaj modułu i jak zainicjalizować załadowane moduły. Deweloper może zastąpić zródłowe (ang. core) moduły własnymi implementacjami poprzez konfigurację aplikacji lub może napisać nowe moduły by dostarczać dodatkowe funkcjonalności. Na przykład można stworzyć moduł, który będzie dostarczał wspólną logikę baz danych dla jednej lub więcej stron. Aby dowiedzieć się więcej zobacz sekcję konfiguracja. -
--Domyślnie ładowane są 3 moduły źródłowe (ang. core modules) podczas starty aplikacji. Są to moduł żądania (ang. request module), moduł odpowiedzi (ang. responce module) oraz moduł zarządzania błędami (ang. error handler module). Dodatkowo moduł sesji (ang. session module) jest ładowany kiedy jejst on używany w aplikacji. PRADO dostarcza domyślną implementację dla wszystkich tych modułów. Dodatkowe moduły (ang. custom modules) mogą być konfigurowane lub stworzone by nadpisać lub uzupełnić te trzy moduły źródłowe. -
- - --Moduł żądań reprezentuje i dostarcza schemat dostępu i przechowywania żądań użytkownika wysyłanych poprzez HTTP. Dane żądania użytkownika przychodzą z kilku źródeł wliczając adresy URL, dane z żądania POST, dane sesyjne, dane z ciasteczek, itd. Te dane są dostępne poprzez moduł żądania. Domyślnie PRADO używa THttpRequest jako moduł żądania. Moduł żądania jest dostępne poprzez właściwość Request aplikacjji i kontrolek. -
- - --Moduł odpowiedzi implementuje mechanizm do wysywałania wyjścia do klienta użytkwonika. Moduł odpowiedzi może zostać skonfigurowany by kontrolować jak wyjście jest keszowane po stronie klienta. Może on być również uzywany by wysyłać cookie z powrotem na stronę klienta. Domyślnie PRADO używa THttpResponse jako moduły odpowiedzi. Moduł odpowiedzi jest dostępny poprzez właściwość Response aplikacji i kontrolek. -
- - --Moduł sesji enkapsuluje funkcjonalność związaną z zarządzaniem sesji użytkowika. Moduł sesji jest automatycznie ładowany jeśli aplikacja używa sesji. Domyślnie PRADO używa THttpSession jako moduł sesji, który jest po prostu nadkładką (ang. wrapper) dla funkcji sesyjnych dostarczanych przez PHP. Moduł sesji jest dostępny poprzez właściwość Session aplikacji i kontrolek. -
- - --Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszystkie przypadki błędów w aplikacji. PRADO używa TErrorHandler jako moduł zarządzania błędami. Przechwytuje on wszystkie ostrzeżenia PHP (ang. warnings), wiadomości (ang. notices) oraz wyjątki (ang. exceptions) i wyświetla w odpowiedniej formie użytkownikowi końcowemu. Moduł zarządzania błędami jest dostępny poprzez właściwość ErrorHandler instancji aplikacji. -
- - --PRADO zostało wydane z większą ilością modułów niż wymienione moduły źródłowe. PRADO zawiera moduły keszujące (TSqliteCache oraz TMemCache), moduły zarządzające użytkownikami (TUserManager), moduły autentykacji i autoryzacji (TAuthManager), itd. -
--Kiedy wystąpi żądanie TPageService ładowane są także określone moduły dla serwisu stron, włączając menedżer elementów aktywnych (ang. assets manager) (TAssetManager), menedżer szablonów (TTemplateManager), menedżer tematów/skórek (ang. theme/skin manager) (TThemeManager). -
--Dodatkowe moduły oraz moduły źródłowe są konfigurowalne poprzez konfigurację. -
- --Strony są najwyżej umiejscowionymi w hierarchi kontrolkamki, które nie posiadają rodzica. -Prezentacja strony jest bezpośrednio wyświetlana użytkownikowi końcowemu. Użytkownicy posiadają dostęp do strony poprzez wysłanie żądanie do serwisu strony (ang. sending page service requests). -
--Każda strona musi posiadać plik szablonu. Musi posiadać on rozszerzenie .page. Nazwa pliku (bez rozszerzenia) jest nazwą strony. PRADO będzie próbować znaleźć plik klasy strony w katalogu zawierającym szablon strony. Taki plik klasy strony musi posiadać tą samą nazwę (z rozszerzeniem .php) jak plik szablonu. Jeśli klasa nie zostanie znaleziona, strona skorzysta z klasy TPage. -
- --Wysłanie formularza jest nazywane postback jeśli wysłanie następuje do strony zawierającej formularz. Postback może być postrzegany jako zdarzenie po stronie klienta, wywoływane przez użytkownika. PRADO będzie próbowało zidentyfikować, która kontrolka po stronie serwera jest odpowiedzialna za zdarzenie postblack. Jeśli znajdzie taką, np. przykład TButton, nazywać ją będziemy senderem zdarzenia postback, który przetłumaczy zdarzenie postback na pewne specyficzne zdarzenia po stronie serwera (np. zdarzenia OnClick i OnCommand dla TButton). - -
- -
-Zrozumienie cyklu życia strony jest kluczowe by zrozumieć istotę programowania w PRADO.
-Cykl życia strony odwołuje się do stanów przejściowych strony, gdy jest ona dostarczana użytkownikowi końcowemu. Może on (cykl) być przedstawiony za pomocą następującej tablicy stanów:
-
-
-Serwis jest instancją klasy implementującej interfejs IService. Każdy rodzaj serwisu przetwarza specyficzny typ żądania użytkownika. Na przykład serwis strony (ang. page service) odpowiada na żądania użytkownika dla stron PRADO. -
-
-Serwis jest jednoznacznie identyfikowany poprzez swoją właściwość ID. Domyślnie kiedy THttpRequest jest używany jako moduł żądania (ang. request module), nazwy zmiennych GET są używane by zidentyfikować serwis żadany przez użytkownika. Jeśli nazwa zmiennej GET zgadza się z jakimś ID serwisu, żądanie jest przetwarzane przez ten serwis oraz wartość parametru GET jest przekazywana jako parametr serwisu. Dla serwisu strony nazwą zmiennej GET musi być page. Na przykład następujący adres URL żadą strony Fundamentals.Services,
-
-Deweloper może zaimplementować dodatkowe serwisy dla swojej aplikacji. Aby uczynić serwis dostępnym należy go skonfigurować w konfiguracji aplikacji. -
- --PRADO implementuje TPageService by przetwarzać żądania stron użytkonika. Strony są przechowywane w katalogu określonej przez właściwość BasePath serwisu strony. Właściwość wskazuje domyślnie na katalog pages w ścieżce aplikacji. Możesz zmienić tą wartość domyślną poprzez skonfigurowanie serwisu w konfiguracji aplikacji. -
--Strony mogą być zorganizowane w podkatalogi w BasePath. W każdym katalogu może znajdować się plik konfiguracji strony o nazwie config.xml, który zawiera konfigurację aktywną tylko wtedy gdy strona spod tego katalogu lub podkatalogu jest żądana. Aby dowiedzieć się wiecej zobacz sekcję konfiguracja strony. -
-
-Parametr dla serwisu stron wskazuje na żądaną stronę. Parametr taki jak Fundamentals.Services wskazuje na stronę Services w katalogu <BasePath>/Fundamentals. Jeśli taki parametr nie jest obecny w żądaniu domyślnie przyjmowana jest jego wartość jako Home. Używając THttpRequest jako moduł żądania (domyślnie), następujący adres URL zażada stron Home, About i Register odpowiednio dla:
-