From abc5db3fd0349f38ce45717ea46b1f7715ded7c6 Mon Sep 17 00:00:00 2001
From: aztech <>
Date: Tue, 1 Jan 2008 17:54:32 +0000
Subject: [PL] Architecture, components, controls, pages, services and modules
translation
---
.../pages/Fundamentals/pl/Architecture.page | 15 +++
.../pages/Fundamentals/pl/Components.page | 128 +++++++++++++++++++++
.../protected/pages/Fundamentals/pl/Controls.page | 51 ++++++++
.../protected/pages/Fundamentals/pl/Modules.page | 50 ++++++++
.../protected/pages/Fundamentals/pl/Pages.page | 25 ++++
.../protected/pages/Fundamentals/pl/Services.page | 34 ++++++
6 files changed, 303 insertions(+)
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Architecture.page
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Components.page
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
create mode 100644 demos/quickstart/protected/pages/Fundamentals/pl/Services.page
(limited to 'demos/quickstart/protected/pages/Fundamentals')
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 @@
+
+Architektura
+
+
+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.
+
+
+$Id: Architecture.page 1650 2007-01-24 06:55:32Z wei $
\ 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 @@
+
+Komponenty
+
+Komponent jest instancją klasy lub klasy potomnej TComponent. Klasa bazowa TComponent implementuje mechanizm właściwości oraz zdarzeń kompomentu.
+
+
+Właściwości komponentu (ang. component properties)
+
+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,
+
+class TControl extends TComponent {
+ public function getID() {
+ ...
+ }
+ public function setID($value) {
+ ...
+ }
+}
+
+
+
+Aby pobrać lub ustawić właściwość ID, postępuj jak poniżej (tak jakbyś miał do czynienia ze zmienną):
+
+$id = $component->ID;
+$component->ID = $id;
+
+Jest to równoznaczne z następującym zapisem:
+
+$id = $component->getID();
+$component->setID( $id );
+
+
+
+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ści (ang. subproperties)
+
+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:
+
+$name = $component->getSubProperty('Font.Name');
+$component->setSubProperty('Font.Name', $name);
+
+Jest to równoznaczne z następującym zapisem:
+
+$name = $component->getFont()->getName();
+$component->getFont()->setName( $name );
+
+
+
+
+
+Zdarzenia komponentu
+
+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:
+
+class TButton extends TWebControl {
+ public function onClick( $param ) {
+ ...
+ }
+}
+
+W ten sposób definiujemy metodę o nazwie OnClick a uchwyt do zdarzenia przez nią definiowanego może być przypisany w jeden z następujących sposobów:
+
+$button->OnClick = $callback;
+$button->OnClick->add( $callback );
+$button->OnClick[] = $callback;
+$button->attachEventHandler( 'OnClick' , $callback );
+
+gdzie $callback odnosi się do poprawnej funkcji typu callback w PHP (np. nazwy funkcji, metody klasy array($object,'method'), itp.)
+
+
+Przestrzenie nazw (ang. namespaces)
+
+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:
+
+PathAlias.Dir1.Dir2
+
+gdzie PathAlias jest aliasem jakiegoś katalogu, gdzie Dir1 i Dir2 są podkatalogami tego katalogu. Klasa o nazwie MyClass zdefiniowana w Dir2 jest fully qualified poprzez PathAlias.Dir1.Dir2.MyClass.
+
+
+By używać przestrzeni nazw w kodzie, napisz:
+
+Prado::using('PathAlias.Dir1.Dir2.*');
+
+co spowoduje dołączenie katalogu wskazywanego przez PathAlias.Dir1.Dir2 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
+
+Prado::using('PathAlias.Dir1.Dir2.MyClass');
+
+co spowoduje zainkludowanie pliku klasy MyClass jeśli nie została ona jeszcze zdefiniowana.
+
+
+Aby zobaczyć więcej informacji o definiowaniu aliasów zobacz sekcję konfigurowanie aplikacji.
+
+
+Tworzenie instancji komponentu
+
+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
+
+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:
+
+$component = new ComponentClassName;
+$component = Prado::createComponent('ComponentType');
+
+gdzie ComponentType wskazuje na nazwę klasy lub nazwę typu w formacie przestrzeni nazw (np. System.Web.UI.TControl). Drugi sposób został wprowadzony aby wypełnić brak wsparcia dla przestrzeni nazw w PHP.
+
+
+Statyczne tworzenie instancji komponentów
+
+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:
+
+<com:TButton Text="Register" />
+
+
+
+$Id$
\ 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 @@
+
+Kontrolki (ang. controls)
+
+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.
+
+
+Drzewko kontrolek
+
+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:
+
+$parent->Controls->add($child);
+$parent->Controls[]=$child;
+
+gdzie właściwość Controls wskazuje na kolekcję kontrolek bedących dziećmi rodzica.
+
+
+Identyfikacja kontrolki
+
+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 (!#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 UniqueID lub ClientID.
+
+
+Kontenery nazw (ang. naming containers)
+
+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 (!#?items), które posiadają kontrolki-dzieci o tych samych ID. 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 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.
+
+
+Stan widoku (ang. ViewState) oraz stan kontrolki (ang. ControlState)
+
+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 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.
+
+
+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:
+
+$this->getViewState('Nazwa',$wartoscDomyslna);
+$this->setViewState('Nazwa',$wartosc,$wartoscDomyslna);
+$this->getControlState('Nazwa',$wartoscDomyslna);
+$this->setControlState('Nazwa',$wartosc,$wartoscDomyslna);
+
+gdzie $this odnosi się do instancji kontrolki, Nazwa odnosi się to klucza identyfikującego zachowaną wartość, $wartoscDomyslna jest opcjonalna. Kiedy przywracamy wartości z stanu widoku lub stanu kontrolki, jeśli podany klucz nie istnieje, wartość domyślna jest zwracana.
+
+
+$Id$
\ 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 @@
+
+
+Moduły (ang. modules)
+
+Moduł jest instancją klasy implementującej interfejs IModule. 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.
+
+
+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ł żądania (ang. request module)
+
+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 (ang. response module)
+
+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 (ang. session module)
+
+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ądzania błędami (ang. error handler module)
+
+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 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.
+
+
+
+Dodatkowe moduły (ang. custom modules)
+
+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 (!#? 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ę.
+
+
+$Id: Modules.page 1650 2007-01-24 06:55:32Z wei $
\ 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 @@
+
+
+Strony (ang. pages)
+
+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).
+
+
+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.
+
+
+PostBack
+
+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 (przetworzy?) zdarzenie postback na pewne specyficzne zdarzenia po stronie serwera (np. zdarzenia OnClick i OnCommand dla TButton).
+
+
+
+Cykl życia strony (ang. page lifecycles)
+
+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):
+
+
+
+$Id: Pages.page 1650 2007-01-24 06:55:32Z wei $
\ 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 @@
+
+
+Serwisy (ang. services)
+
+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 (!#? considered) dla tego serwisu 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,
+
+http://hostname/index.php?page=Fundamentals.Services
+
+
+
+Deweloper może zaimplementować dodatkowe serwisy dla swojej aplikacji. Aby uczynić serwis dostępnym należy go skonfigurować w konfiguracji aplikacji.
+
+
+Serwis strony (ang. page service)
+
+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:
+
+http://hostname/index.php
+http://hostname/index.php?page=About
+http://hostname/index.php?page=Users.Register
+
+gdzie pierwszy przukład wynika z faktu, że serwis strony jest domyślnym serwisem a strona Home jest stroną domyślną.
+
+
+$Id: Services.page 1650 2007-01-24 06:55:32Z wei $
\ No newline at end of file
--
cgit v1.2.3