From 55d3e16a0732bbf410ef82d76614420396a903cc Mon Sep 17 00:00:00 2001 From: aztech <> Date: Thu, 3 Jan 2008 00:50:51 +0000 Subject: [PL] Some typos corrections and synchro with English version. --- demos/quickstart/protected/pages/Fundamentals/pl/Controls.page | 6 +++--- demos/quickstart/protected/pages/Fundamentals/pl/Modules.page | 6 +++--- demos/quickstart/protected/pages/Fundamentals/pl/Pages.page | 8 ++++---- demos/quickstart/protected/pages/Fundamentals/pl/Services.page | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) (limited to 'demos/quickstart/protected/pages/Fundamentals/pl') diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page index 3b1cff2b..94974de4 100644 --- a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page +++ b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page @@ -19,12 +19,12 @@ gdzie właściwość Controls wskazuje na kolekcję kontrolek bedących

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

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. +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. @@ -35,7 +35,7 @@ Kontrolka może służyć jako kontener naz jeśli implementuje interfejs IN 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. +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: diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page index 747f865d..f92b0eb3 100644 --- a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page +++ b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page @@ -2,7 +2,7 @@

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. +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. @@ -32,7 +32,7 @@ Moduł sesji enkapsuluje funkcjonalność związaną z zarządzaniem sesji użyt

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

@@ -41,7 +41,7 @@ Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszys 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). +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ę. diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page index e55509c2..e50df71f 100644 --- a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page +++ b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page @@ -3,7 +3,7 @@

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). +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. @@ -11,14 +11,14 @@ Każda strona musi posiadać plik szab

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

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

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page index 31144916..9c23e459 100644 --- a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page +++ b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page @@ -5,7 +5,7 @@ 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, +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, http://hostname/index.php?page=Fundamentals.Services -- cgit v1.2.3