[PL] Architecture, components, controls, pages, services and modules translation

6 files changed, 303 insertions, 0 deletions

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page b/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page
new file mode 100644
index 00000000..fb6f7310
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page
@@ -0,0 +1,15 @@
+<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%>" />

+<div class="last-modified">$Id: Architecture.page 1650 2007-01-24 06:55:32Z wei $</div></com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Components.page b/demos/quickstart/protected/pages/Fundamentals/pl/Components.page
new file mode 100644
index 00000000..9e6a2f63
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Components.page
@@ -0,0 +1,128 @@
+<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>

+

+<div class="last-modified">$Id$</div></com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
new file mode 100644
index 00000000..3b1cff2b
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
@@ -0,0 +1,51 @@
+<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 (!#corresponding) 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 zewnętrznym (!#explicit) 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 (!#?items), które posiadają kontrolki-dzieci o tych samych <tt>ID</tt>. Aby rozróżnić te kontrolki-dzieci, każdy (!#?item) służy jako kontener nazw serves. 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 mechanizmu ??? programowania (!#? stateful programming mechanism). Wartość zachowana w stanie widoku lub stanie kontrolki może być dostepna w następnym żądaniu jeśli nowe żądanie pochodzi od (!#?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>

+

+<div class="last-modified">$Id$</div></com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
new file mode 100644
index 00000000..747f865d
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
@@ -0,0 +1,50 @@
+<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 (~#?commonly) 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/warunki (!#ang. condition) 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 (!#? 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>

+

+<div class="last-modified">$Id: Modules.page 1650 2007-01-24 06:55:32Z wei $</div></com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
new file mode 100644
index 00000000..e55509c2
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
@@ -0,0 +1,25 @@
+<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 (!#Users access pages by 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 (przetworzy?) 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 niezbędne by zrozumieć(!#?grasp) programowanie w PRADO.

+Cykl życia strony odwołuje się do stanów (!#? transitions) strony, kiedy jest ona dostarczana użytkownikowi końcowemu. Może on (cykl) być przedstawiony za pomocą następującej ... stanów (!#? statechart):

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

+</p>

+

+<div class="last-modified">$Id: Pages.page 1650 2007-01-24 06:55:32Z wei $</div></com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
new file mode 100644
index 00000000..31144916
--- /dev/null
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
@@ -0,0 +1,34 @@
+<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 (!#? considered) dla tego serwisu 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>

+

+<div class="last-modified">$Id: Services.page 1650 2007-01-24 06:55:32Z wei $</div></com:TContent>
\ No newline at end of file