Merge branch 'master' of https://github.com/majuca/prado

13 files changed, 0 insertions, 377 deletions

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Applications.page b/demos/quickstart/protected/pages/Fundamentals/pl/Applications.page
deleted file mode 100755
index 23866005..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Applications.page
+++ /dev/null
@@ -1,58 +0,0 @@
-<com:TContent ID="body" >

-

-<h1 id="1201">Aplikacja</h1>

-<p id="160157" class="block-content">

-Aplikacja jest instancją <tt>TApplication</tt> 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 <tt>Prado::getApplication()</tt>.

-</p>

-<p id="160158" class="block-content">

-Aplikacje są konfigurowane poprzez <a href="?page=Configurations.AppConfig">konfigurację aplikacji</a>. Są zazwyczaj tworzone w skrypcie wejściowym w podobny do następującego sposób,

-<com:TTextHighlighter CssClass="source block-content" id="code_160071">

-require_once('/path/to/prado.php');

-$application = new TApplication;

-$application->run();

-</com:TTextHighlighter>

-gdzie metoda <tt>run()</tt> rozpoczyna działanie aplikacji obsługującej żądania użytkownika.

-</p>

-

-<h2 id="1202">Organizacja folderów</h2>

-<p id="160159" class="block-content">

-Minimalna aplikacja PRADO zawiera dwa pliki: plik wejściowy i plik szablonu. Muszą być one zorganizowane w następujący sposób.

-<img src="<%~directory.gif%>" class="figure"/>

-</p>

-<ul id="u2" class="block-content">

-<li><tt>wwwroot</tt> - główny katalog serwera WWW lub jeden z podkatalogów.</li>

-<li><tt>index.php</tt> - skrypt wejściowy aplikacji PRADO.</li>

-<li><tt>assets</tt> - katalog przechowujący opublikowane pliki prywatne. Zobacz sekcję <a href="?page=Advanced.Assets">assets</a>.</li>

-<li><tt>protected</tt> - podstawowa ścieżka aplikacji zawierająca jej dane oraz prywatne pliki skryptów. Ten folder powinien być niedostepny z zewnątrz lub powinien znajdować się poza strukturą serwera WWW.</li>

-<li><tt>runtime</tt> - application runtime storage path. Ten folder jest używany przez PRADO do przechowywania informacji o wykonywanej aplikacji, takich jak stan aplikacji, kedzowane dane, itd.</li>

-<li><tt>pages</tt> - podstawowa ścieżka przechowująca wszystkie strony PRADO. Zobacz sekcję <a href="?page=Fundamentals.Services">serwisy</a>.</li>

-<li><tt>Home.page</tt> - domyślna strona zwracana gdy użytkownik nie poda jawnie żadanej strony. Jest to plik szablonu strony. Nazwa pliku bez rozszerzenia jest nazwą strony. Klasą strony jest klasa <tt>TPage</tt>. Jeśli znajduje się tam również plik klasy <tt>Home.php</tt>, klasą strony staje się <tt>Home</tt>.</li>

-</ul>

-

-<p id="160160" class="block-content">

-Produktywna aplikacja PRADO zazwyczaj potrzebuje więcej plików. Może ona zawierać plik konfiguracji aplikacji <tt>application.xml</tt> w podstawej ścieżce aplikacji <tt>protected</tt>. Strony mogą być zorganizowane w foldery, część z nich może zawierać pliki konfiguracji strony <tt>config.xml</tt>. Aby dowiedzieć się wiecej, zajrzyć do sekcji <a href="?page=Configurations.Overview">konfiguracji</a>.

-</p>

-

-<h2 id="1203">Osadzanie aplikacji</h2>

-<p id="160161" class="block-content">

-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.

-</p>

-<ol>

-<li>Skopiuj zawartość z <tt>wwwroot</tt> do dostępnego poprzez WWW foldera na nowym serwerze.</li>

-<li>Zmodyfikuj skrypt wejściowy <tt>index.php</tt> tak by prawidłowo inkludował plik <tt>prado.php</tt>.</li>

-<li>Usuń całą zawartość z folderów <tt>assets</tt> i <tt>runtime</tt> i upewnij się, że oba umożliwiają zapis procesom serwera WWW.</li>

-</ol>

-

-<h2 id="1204">Cykle życia aplikacji</h2>

-<p id="160162" class="block-content">

-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 <tt>TAuthManager</tt>, używają tego sposobu aby wyknać swoje zadania.

-</p>

-<p id="160163" class="block-content">

-Cykle życia aplikacji mogą zostać przedstawione następująco:

-</p>

-<img src="<%~applifecycles.gif%>" />

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page b/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page
deleted file mode 100755
index db429253..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page
+++ /dev/null
@@ -1,15 +0,0 @@
-<com:TContent ID="body" >

-<h1 id="601">Architektura</h1>

-

-<p id="100111" class="block-content">

-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.    

-</p>

-<img src="<%~classtree.gif%>" />

-

-<p id="100112" class="block-content">

-Kiedy PRADO przetwarza żądanie strony, jego diagram obiektów statycznych wygląda następująco.

-</p>

-<img src="<%~objectdiagram.gif%>" />

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Components.page b/demos/quickstart/protected/pages/Fundamentals/pl/Components.page
deleted file mode 100755
index 5890f17f..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Components.page
+++ /dev/null
@@ -1,128 +0,0 @@
-<com:TContent ID="body" >

-<h1 id="701">Komponenty</h1>

-<p id="110113" class="block-content">

-Komponent jest instancją klasy lub klasy potomnej <tt>TComponent</tt>. Klasa bazowa <tt>TComponent</tt> implementuje mechanizm właściwości oraz zdarzeń kompomentu.

-</p>

-

-<h2 id="702">Właściwości komponentu (ang. component properties)</h2>

-<p id="110114" class="block-content">

-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 <tt>TControl</tt> definiujemy właściwość <tt>ID</tt> komponentu używając następujących funkcji typu getter i setter,

-<com:TTextHighlighter CssClass="source block-content" id="code_110056">

-class TControl extends TComponent {

-    public function getID() {

-        ...

-    }

-    public function setID($value) {

-        ...

-    }

-}

-</com:TTextHighlighter>

-</p>

-<p id="110115" class="block-content">

-Aby pobrać lub ustawić właściwość <tt>ID</tt>, postępuj jak poniżej (tak jakbyś miał do czynienia ze zmienną):

-<com:TTextHighlighter CssClass="source block-content" id="code_110057">

-$id = $component->ID;

-$component->ID = $id;

-</com:TTextHighlighter>

-Jest to równoznaczne z następującym zapisem:

-<com:TTextHighlighter CssClass="source block-content" id="code_110058">

-$id = $component->getID();

-$component->setID( $id );

-</com:TTextHighlighter>

-</p>

-<p id="110116" class="block-content">

-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.

-</p>

-

-<h3 id="706">Subwłaściwości (ang. subproperties)</h3>

-<p id="110117" class="block-content">

-Subwłaściwość jest właściwością właściwości typu obiektowego. Dla przykładu <tt>TWebControl</tt> posiada właściwość <tt>Font</tt>, która jest typu <tt>TFont</tt>. Wtedy właściwość <tt>Name</tt> właściwości <tt>Font</tt> jest subwłaściwością w stosunku do <tt>TWebControl</tt>.

-</p>

-<p id="110118" class="block-content">

-Aby pobrać lub ustawić subwłaściwość <tt>Name</tt> należy użyć następującej metody:

-<com:TTextHighlighter CssClass="source block-content" id="code_110059">

-$name = $component-&gt;getSubProperty('Font.Name');

-$component->setSubProperty('Font.Name', $name);

-</com:TTextHighlighter>

-Jest to równoznaczne z następującym zapisem:

-<com:TTextHighlighter CssClass="source block-content" id="code_110060">

-$name = $component->getFont()->getName();

-$component-&gt;getFont()-&gt;setName( $name );

-</com:TTextHighlighter>

-

-

-</p>

-

-<h2 id="703">Zdarzenia komponentu</h2>

-<p id="110119" class="block-content">

-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.

-</p>

-<p id="110120" class="block-content">

-Zdarzenie komponentu jest definiowane poprzez istnienie metody, której nazwa zaczyna się przedrostkiem <tt>on</tt>. Nazwa zdarzenia jest nazwą metody i z tego powodu jest niewrażliwa na wielkość liter. Na przykład w komponencie <tt>TButton</tt> mamy:

-<com:TTextHighlighter CssClass="source block-content" id="code_110061">

-class TButton extends TWebControl {

-    public function onClick( $param ) {

-        ...

-    }

-}

-</com:TTextHighlighter>

-W ten sposób definiujemy metodę o nazwie <tt>OnClick</tt> a uchwyt do zdarzenia przez nią definiowanego może być przypisany w jeden z następujących sposobów:

-<com:TTextHighlighter CssClass="source block-content" id="code_110062">

-$button->OnClick = $callback;

-$button->OnClick->add( $callback );

-$button->OnClick[] = $callback;

-$button->attachEventHandler( 'OnClick' , $callback );

-</com:TTextHighlighter>

-gdzie <tt>$callback</tt> odnosi się do poprawnej funkcji typu callback w PHP (np. nazwy funkcji, metody klasy <tt>array($object,'method')</tt>, itp.)

-</p>

-

-<h2 id="704">Przestrzenie nazw (ang. namespaces)</h2>

-<p id="110121" class="block-content">

-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).

-</p>

-<p id="110122" class="block-content">

-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:

-<div class="source">

-PathAlias.Dir1.Dir2

-</div>

-gdzie <tt>PathAlias</tt> jest aliasem jakiegoś katalogu, gdzie <tt>Dir1</tt> i <tt>Dir2</tt> są podkatalogami tego katalogu. Klasa o nazwie <tt>MyClass</tt> zdefiniowana w <tt>Dir2</tt> jest fully qualified poprzez <tt>PathAlias.Dir1.Dir2.MyClass</tt>.

-</p>

-<p id="110123" class="block-content">

-By używać przestrzeni nazw w kodzie, napisz:

-<com:TTextHighlighter CssClass="source block-content" id="code_110063">

-Prado::using('PathAlias.Dir1.Dir2.*');

-</com:TTextHighlighter>

-co spowoduje dołączenie katalogu wskazywanego przez <tt>PathAlias.Dir1.Dir2</tt> do ścieżek include w PHP, dzięki czemu instancje klas zdefiniowanych w podanym katalogu mogą zostać utworzone bez podawania pełnej przestrzeni nazw. Możesz również zainkludować pojedyńczą definicję klasy poprzez

-<com:TTextHighlighter CssClass="source block-content" id="code_110064">

-Prado::using('PathAlias.Dir1.Dir2.MyClass');

-</com:TTextHighlighter>

-co spowoduje zainkludowanie pliku klasy <tt>MyClass</tt> jeśli nie została ona jeszcze zdefiniowana.

-</p>

-<p id="110124" class="block-content">

-Aby zobaczyć więcej informacji o definiowaniu aliasów zobacz sekcję <a href="?page=Configurations.AppConfig">konfigurowanie aplikacji</a>.

-</p>

-

-<h2 id="705">Tworzenie instancji komponentu</h2>

-<p id="110125" class="block-content">

-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.

-</p>

-

-<h3 id="707">Dynamiczne tworzenie instancji komponentów</h3>

-<p id="110126" class="block-content">

-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:

-<com:TTextHighlighter CssClass="source block-content" id="code_110065">

-$component = new ComponentClassName;

-$component = Prado::createComponent('ComponentType');

-</com:TTextHighlighter>

-gdzie <tt>ComponentType</tt> wskazuje na nazwę klasy lub nazwę typu w formacie przestrzeni nazw (np. <tt>System.Web.UI.TControl</tt>). Drugi sposób został wprowadzony aby wypełnić brak wsparcia dla przestrzeni nazw w PHP.

-</p>

-

-<h3 id="708">Statyczne tworzenie instancji komponentów</h3>

-<p id="110127" class="block-content">

-Statyczne tworzenie instancji komponentów odnosi się do tworznenia komponentów poprzez <a href="?page=Configurations.Overview">konfigurację</a>. Proces tworzenia odbywa się po stronie frameworku. Na przykład w <a href="?page=Configurations.AppConfig">konfiguracji aplikacji</a> 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 <a href="?page=Configurations.Templates1">szablonach</a>. 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 <tt>TButton</tt> na stronie:

-<com:TTextHighlighter Language="prado" CssClass="source block-content" id="code_110066">

-&lt;com:TButton Text="Register" /&gt;

-</com:TTextHighlighter>

-</p>

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
deleted file mode 100755
index 68fdb993..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
+++ /dev/null
@@ -1,51 +0,0 @@
-<com:TContent ID="body" >

-<h1 id="801">Kontrolki (ang. controls)</h1>

-<p id="120128" class="block-content">

-Kontrolka jest instancją klasy <tt>TControl</tt> lub jej dziecka. Kontrolka jest komponentem definiowanym z dodatkiem interfejsu użytkownika. Klasa bazowa <tt>TControl</tt> definiuje relację rodzic-dziecko among controls which reflects the containment relationship among user interface elements.

-</p>

-

-<h2 id="802">Drzewko kontrolek</h2>

-<p id="120129" class="block-content">

-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.

-</p>

-<p id="120130" class="block-content">

-Relacja rodzic-dziecko jest zazwyczaj ustalana przez framework poprzez <a href="?page=Configurations.Templates1">szablony</a>. W kodzie można bezpośrednio określić kontrolkę jako dziecko innej kontrolki stosując jedną z następujących metod:

-<com:TTextHighlighter CssClass="source block-content" id="code_120067">

-$parent->Controls->add($child);

-$parent->Controls[]=$child;

-</com:TTextHighlighter>

-gdzie właściwość <tt>Controls</tt> wskazuje na kolekcję kontrolek bedących dziećmi rodzica.

-</p>

-

-<h2 id="803">Identyfikacja kontrolki</h2>

-<p id="120131" class="block-content">

-Każda kontrolka ma właściwość <tt>ID</tt>, która jednoznacznie identyfikuje ją samą spośród jej rodzeństwa. W dodatku każda kontrolka posiada właściwość <tt>UniqueID</tt> oraz <tt>ClientID</tt>, która może zostać użyta do identyfikacji "globalnej" kontrolki w drzewku gdzie znajduje się ta kontrolka. Właściwości <tt>UniqueID</tt> oraz <tt>ClientID</tt> 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 <tt>UniqueID</tt> lub <tt>ClientID</tt>.

-</p>

-

-<h2 id="804">Kontenery nazw (ang. naming containers)</h2>

-<p id="120132" class="block-content">

-Każda kontrolka posiada kontener nazw, który jest kontrolką tworzącą unikalną przestrzeń nazw dla rozróżnienie pomiędzy kontrolkami o tych samych <tt>ID</tt>. Na przykład kontrolka <tt>TRepeater</tt> tworzy wiele pozycji, które posiadają kontrolki-dzieci o tych samych <tt>ID</tt>. 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 <tt>ID</tt> swojego kontenera nazw razem z swoim własnym <tt>ID</tt>. Powinieneś teraz zrozumieć, że właściwości <tt>UniqueID</tt> i <tt>ClientID</tt> bazują (wynikają?) na kontenerze nazw.

-</p>

-<p id="120133" class="block-content">

-Kontrolka może służyć jako kontener naz jeśli implementuje interfejs <tt>INamingContainer</tt>.

-</p>

-

-<h2 id="805">Stan widoku (ang. ViewState) oraz stan kontrolki (ang. ControlState)</h2>

-<p id="120134" class="block-content">

-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.

-</p>

-<p id="120135" class="block-content">

-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.

-</p>

-<p id="120136" class="block-content">

-Stan widoku i stan kontrolki są zaimplementowane w <tt>TControl</tt>. 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:

-<com:TTextHighlighter CssClass="source block-content" id="code_120068">

-$this->getViewState('Nazwa',$wartoscDomyslna);

-$this->setViewState('Nazwa',$wartosc,$wartoscDomyslna);

-$this->getControlState('Nazwa',$wartoscDomyslna);

-$this->setControlState('Nazwa',$wartosc,$wartoscDomyslna);

-</com:TTextHighlighter>

-gdzie <tt>$this</tt> odnosi się do instancji kontrolki, <tt>Nazwa</tt> odnosi się to klucza identyfikującego zachowaną wartość, <tt>$wartoscDomyslna</tt> jest opcjonalna. Kiedy przywracamy wartości z stanu widoku lub stanu kontrolki, jeśli podany klucz nie istnieje, wartość domyślna jest zwracana.

-</p>

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Hangman.page b/demos/quickstart/protected/pages/Fundamentals/pl/Hangman.page
deleted file mode 100755
index e3ad1338..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Hangman.page
+++ /dev/null
@@ -1,16 +0,0 @@
-<com:TContent ID="body" >

-

-<h1 id="1301">Przykład: wisielec</h1>

-<p id="60043" class="block-content">

-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. 

-</p>

-<p id="60044" class="block-content">

-Aby ułatwić stowrzenie tej gry, pokażemy diagram zmiany stanów gry następująco 

-<br /><br />

-Ciąg dalszy nastąpi...

-</p>

-<com:RunBar PagePath="Fundamentals.Samples.Hangman.Home" />

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
deleted file mode 100755
index 1bc8ca94..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
+++ /dev/null
@@ -1,50 +0,0 @@
-<com:TContent ID="body" >

-

-<h1 id="1001">Moduły (ang. modules)</h1>

-<p id="140141" class="block-content">

-Moduł jest instancją klasy implementującej interfejs <tt>IModule</tt>. 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.

-</p>

-<p id="140142" class="block-content">

-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ę <a href="?page=Configurations.Overview">konfiguracja</a>.

-</p>

-<p id="140143" class="block-content">

-Domyślnie ładowane są 3 moduły źródłowe (ang. core modules) podczas starty aplikacji. Są to <a href="#request">moduł żądania (ang. request module)</a>, <a href="#response">moduł odpowiedzi (ang. responce module)</a> oraz <a href="#error">moduł zarządzania błędami (ang. error handler module)</a>. Dodatkowo  <a href="#session">moduł sesji (ang. session module)</a> jest ładowany kiedy jejst on używany w aplikacji. PRADO dostarcza domyślną implementację dla wszystkich tych modułów. <a href="#custom">Dodatkowe moduły (ang. custom modules)</a> mogą być konfigurowane lub stworzone by nadpisać  lub uzupełnić te trzy moduły źródłowe.

-</p>

-

-<a name="request"></a>

-<h2 id="1002">Moduł żądania (ang. request module)</h2>

-<p id="140144" class="block-content">

-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 <tt>THttpRequest</tt> jako moduł żądania. Moduł żądania jest dostępne poprzez właściwość <tt>Request</tt> aplikacjji i kontrolek.

-</p>

-

-<a name="response"></a>

-<h2 id="1003">Moduł odpowiedzi (ang. response module)</h2>

-<p id="140145" class="block-content">

-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 <tt>THttpResponse</tt> jako moduły odpowiedzi. Moduł odpowiedzi jest dostępny poprzez właściwość <tt>Response</tt> aplikacji i kontrolek.

-</p>

-

-<a name="session"></a>

-<h2 id="1004">Moduł sesji (ang. session module)</h2>

-<p id="140146" class="block-content">

-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 <tt>THttpSession</tt> 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ść <tt>Session</tt> aplikacji i kontrolek.

-</p>

-

-<a name="error"></a>

-<h2 id="1005">moduł zarządzania błędami (ang. error handler module)</h2>

-<p id="140147" class="block-content">

-Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszystkie przypadki błędów w aplikacji. PRADO używa <tt>TErrorHandler</tt> 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ść <tt>ErrorHandler</tt> instancji aplikacji.

-</p>

-

-<a name="custom"></a>

-<h2 id="1006">Dodatkowe moduły (ang. custom modules)</h2>

-<p id="140148" class="block-content">

-PRADO zostało wydane z większą ilością modułów niż wymienione moduły źródłowe. PRADO zawiera moduły keszujące (<tt>TSqliteCache</tt> oraz <tt>TMemCache</tt>), moduły zarządzające użytkownikami (<tt>TUserManager</tt>), moduły autentykacji i autoryzacji (<tt>TAuthManager</tt>), itd.

-</p>

-<p id="140149" class="block-content">

-Kiedy wystąpi żądanie <tt>TPageService</tt> ładowane są także określone moduły dla serwisu stron, włączając menedżer elementów aktywnych (ang. assets manager) (<tt>TAssetManager</tt>), menedżer szablonów (<tt>TTemplateManager</tt>), menedżer tematów/skórek (ang. theme/skin manager) (<tt>TThemeManager</tt>).

-</p>

-<p id="140150" class="block-content">

-Dodatkowe moduły oraz moduły źródłowe są konfigurowalne poprzez <a href="?page=Configurations.Overview">konfigurację</a>.

-</p>

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
deleted file mode 100755
index a6318674..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
+++ /dev/null
@@ -1,25 +0,0 @@
-<com:TContent ID="body" >

-

-<h1 id="901">Strony (ang. pages)</h1>

-<p id="130137" class="block-content">

-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).

-</p>

-<p id="130138" class="block-content">

-Każda strona musi posiadać plik <a href="?page=Configurations.Templates1">szablonu</a>. Musi posiadać on rozszerzenie <tt>.page</tt>. 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 <tt>.php</tt>) jak plik szablonu. Jeśli klasa nie zostanie znaleziona, strona skorzysta z klasy <tt>TPage</tt>.

-</p>

-

-<h2 id="902">PostBack</h2>

-<p id="130139" class="block-content">

-Wysłanie formularza jest nazywane <i>postback</i> 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 <tt>TButton</tt>, nazywać ją będziemy senderem zdarzenia postback, który przetłumaczy zdarzenie postback na pewne specyficzne zdarzenia po stronie serwera (np. zdarzenia <tt>OnClick</tt> i <tt>OnCommand</tt> dla <tt>TButton</tt>).

-

-</p>

-

-<h2 id="903">Cykl życia strony (ang. page lifecycles)</h2>

-<p id="130140" class="block-content">

-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:

-<img src="<%~lifecycles.gif %>" />

-</p>

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
deleted file mode 100755
index 6d8b8866..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
+++ /dev/null
@@ -1,34 +0,0 @@
-<com:TContent ID="body" >

-

-<h1 id="1101">Serwisy (ang. services)</h1>

-<p id="150151" class="block-content">

-Serwis jest instancją klasy implementującej interfejs <tt>IService</tt>. 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.

-</p>

-<p id="150152" class="block-content">

-Serwis jest jednoznacznie identyfikowany poprzez swoją właściwość <tt>ID</tt>. Domyślnie kiedy <tt>THttpRequest</tt> jest używany jako <a href="?page=Fundamentals.Modules#request">moduł żądania</a> (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ś <tt>ID</tt> serwisu, żądanie jest przetwarzane przez ten serwis oraz wartość parametru GET jest przekazywana jako parametr serwisu. Dla serwisu strony nazwą zmiennej GET musi być <tt>page</tt>. Na przykład następujący adres URL żadą strony <tt>Fundamentals.Services</tt>,

-<com:TTextHighlighter Language="none" CssClass="source block-content" id="code_150069">

-http://hostname/index.php?page=Fundamentals.Services

-</com:TTextHighlighter>

-</p>

-<p id="150153" class="block-content">

-Deweloper może zaimplementować dodatkowe serwisy dla swojej aplikacji. Aby uczynić serwis dostępnym należy go skonfigurować w <a href="?page=Configurations.AppConfig">konfiguracji aplikacji</a>.

-</p>

-

-<h2 id="1102">Serwis strony (ang. page service)</h2>

-<p id="150154" class="block-content">

-PRADO implementuje <tt>TPageService</tt> by przetwarzać żądania stron użytkonika. Strony są przechowywane w katalogu określonej przez właściwość <tt>BasePath</tt> serwisu strony. Właściwość wskazuje domyślnie na katalog <tt>pages</tt> w ścieżce aplikacji. Możesz zmienić tą wartość domyślną poprzez skonfigurowanie serwisu w konfiguracji aplikacji.

-</p>

-<p id="150155" class="block-content">

-Strony mogą być zorganizowane w podkatalogi w <tt>BasePath</tt>. W każdym katalogu może znajdować się plik konfiguracji strony o nazwie <tt>config.xml</tt>, który zawiera konfigurację aktywną tylko wtedy gdy strona spod tego katalogu lub podkatalogu jest żądana. Aby dowiedzieć się wiecej zobacz sekcję <a href="?page=Configurations.PageConfig">konfiguracja strony</a>.

-</p>

-<p id="150156" class="block-content">

-Parametr dla serwisu stron wskazuje na żądaną stronę. Parametr taki jak <tt>Fundamentals.Services</tt> wskazuje na stronę <tt>Services</tt> w katalogu <tt>&lt;BasePath&gt;/Fundamentals</tt>. Jeśli taki parametr nie jest obecny w żądaniu domyślnie przyjmowana jest jego wartość jako <tt>Home</tt>. Używając <tt>THttpRequest</tt> jako moduł żądania (domyślnie), następujący adres URL zażada stron <tt>Home</tt>, <tt>About</tt> i <tt>Register</tt> odpowiednio dla:

-<com:TTextHighlighter Language="none" CssClass="source block-content" id="code_150070">

-http://hostname/index.php

-http://hostname/index.php?page=About

-http://hostname/index.php?page=Users.Register

-</com:TTextHighlighter>

-gdzie pierwszy przukład wynika z faktu, że serwis strony jest domyślnym serwisem a strona <tt>Home</tt> jest stroną domyślną.

-</p>

-

-</com:TContent>

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/applifecycles.gif b/demos/quickstart/protected/pages/Fundamentals/pl/applifecycles.gif
deleted file mode 100755
index caf16028..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/applifecycles.gif
+++ /dev/null
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/classtree.gif b/demos/quickstart/protected/pages/Fundamentals/pl/classtree.gif
deleted file mode 100755
index b1fbf0d6..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/classtree.gif
+++ /dev/null
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/directory.gif b/demos/quickstart/protected/pages/Fundamentals/pl/directory.gif
deleted file mode 100755
index c7d5086d..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/directory.gif
+++ /dev/null
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/lifecycles.gif b/demos/quickstart/protected/pages/Fundamentals/pl/lifecycles.gif
deleted file mode 100755
index 5edaff5f..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/lifecycles.gif
+++ /dev/null
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/objectdiagram.gif b/demos/quickstart/protected/pages/Fundamentals/pl/objectdiagram.gif
deleted file mode 100755
index 7910469c..00000000
--- a/demos/quickstart/protected/pages/Fundamentals/pl/objectdiagram.gif
+++ /dev/null