From 5a5382ffb33e937402f54fe5f77ed6c49d4a90ed Mon Sep 17 00:00:00 2001 From: David Grudl Date: Thu, 18 Apr 2024 21:53:33 +0200 Subject: [PATCH] x --- application/cs/modules.texy | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/application/cs/modules.texy b/application/cs/modules.texy index 77b528333a..cbc049c35d 100644 --- a/application/cs/modules.texy +++ b/application/cs/modules.texy @@ -4,7 +4,7 @@ Moduly .[perex] Moduly vnášejí do Nette aplikací přehlednost díky snadnému členění do logických celků. -Podobně jako si na disku třídíme soubory do jednotlivých adresářů, tak i v Nette si presentery, šablony a další pomocné třídy můžeme zařazovat do modulů. Jak to vypadá v praxi? Jednoduše uspořádáme strukturu do nových podadresářů. Příklad takové struktuy se dvěma moduly `Front` a `Admin`: +Podobně jako na pevném disku organizujeme soubory do jednotlivých složek, tak i v Nette můžeme presentery, šablony a další pomocné třídy rozdělovat do modulů. Jak to funguje v praxi? Jednoduše začleníme do struktury nové podadresáře. Příklad takové struktury se dvěma moduly Front a Admin: /--pre app/ @@ -23,7 +23,7 @@ app/ │ │ └── ... \-- -Tuto adresářovou strukturu budou reflektovat jmenné prostory tříd, takže třeba `DashboardPresenter` bude v prostoru `App\UI\Admin\...`: +Tato adresářová struktura se odráží v jmenných prostorech tříd, takže například `DashboardPresenter` se nachází ve jmenném prostoru `App\UI\Admin\...`: ```php namespace App\UI\Admin\Dashboard; @@ -34,11 +34,11 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Na presenter `Dashboard` uvnitř modulu `Admin` se v rámci aplikace odkazujeme pomocí dvojtečkové notace jako na `Admin:Dashboard`, na jeho akci `default` potom jako na `Admin:Dashboard:default`. +Na presenter `Dashboard` v rámci modulu `Admin` odkazujeme v aplikaci pomocí dvojtečkové notace jako na `Admin:Dashboard`. Na jeho akci `default` potom jako na `Admin:Dashboard:default`. -Uvedená struktura není pevná, naoapk si ji v konfiguraci můžete zcela [přizpůsobit dle potřeby#mapování] v konfiguraci. .[tip] +Představená struktura není pevná; můžete si ji zcela [přizpůsobit dle svých potřeb#mapování] v konfiguraci. .[tip] -Moduly mohou kromě presenterů a šablon samozřejmě obsahovat všechny další součásti, jako jsou třeba komponenty a různé pomocné třídy. Pokud přemýšlíte, do jaké složky je umístit, zkuste třeba `Accessory`: +Moduly mohou kromě presenterů a šablon samozřejmě zahrnovat všechny ostatní soubory, jako jsou například komponenty a různé pomocné třídy. Pokud uvažujete, kam je zařadit, zvažte využití složky `Accessory`: /--pre app/ @@ -55,7 +55,7 @@ app/ Vnořené moduly -------------- -Moduly nemusí představovat jen jednu úroveň zanoření. Stejně jako adresáře na disku je lze zanořovat hlouběji a vytvářet submoduly. Příklad: +Moduly mohou mít více úrovní zanoření, podobně jako adresářová struktura na disku. Například: /--pre app/ @@ -72,11 +72,11 @@ app/ │ │ └── ... \-- -Tedy modul `Blog` je rozdělen do submodulů `Admin` a `Front`. A opět se to odrazí na jmenných prostorech, které budou `App\UI\Blog\Admin` a podobně. Na presenter `Dashboard` uvnitř submodulu se odkazujeme jako `Blog:Admin:Dashboard`. +Modul `Blog` je rozdělen na submoduly `Admin` a `Front`. To se projeví i ve jmenných prostorech, které pak budou vypadat jako `App\UI\Blog\Admin` a podobně. Na presenter `Dashboard` v rámci submodulu odkazujeme jako na `Blog:Admin:Dashboard`. -Zanořování může pokračovat libovolně hluboko, lze tedy vytvářet sub-submoduly. +Zanoření může být libovolně hluboké, což umožňuje vytvářet sub-submoduly. -Pokud se vám například v administraci sejde větší počet presenterů pro správu objednávek (`OrderDetail`, `OrderEdit`, `OrderDispatch`, ...), můžete pro lepší přehlednost vytvořit modul `Order` a v něm mít presentery `Detail`, `Edit`, `Dispatch` atd. +Pokud například v administraci máte mnoho presenterů týkajících se správy objednávek, jako jsou `OrderDetail`, `OrderEdit`, `OrderDispatch` atd., můžete pro lepší organizovanost vytvořit modul `Order`, ve kterém budou presentery `Detail`, `Edit`, `Dispatch` a další. Vytváření odkazů @@ -118,32 +118,32 @@ Viz [kapitola o routování |routing#Moduly]. Mapování -------- -Definuje pravidla, podle kterých se z názvu presenteru odvodí název třídy. Zapisujeme je v [konfiguraci|configuration] pod klíčem `application › mapping`. +Mapování definuje pravidla pro odvozování názvu třídy z názvu presenteru. Specifikujeme je v [konfiguraci|configuration] pod klíčem `application › mapping`. -Všechny příklady, které jsme uváděli v této kapitole, předpokládají toto mapování: +Všechny příklady v této kapitole vycházejí z následujícího mapování: ```neon application: mapping: App\UI\*\**Presenter ``` -Ale pro lepší pochopení začneme ukázkou aplikace, která nepoužívá moduly. Budeme jen chtít, aby třídy presenterů patřily do jmenného prostoru `App\UI`. Tedy aby se presenter `Home` mapoval na třídu `App\UI\HomePresenter`. Toho lze docílit následující konfigurací: +Pro lepší pochopení si nejprve představíme aplikaci bez modulů. Chceme, aby třídy presenterů spadaly do jmenného prostoru `App\UI`. Aby se presenter `Home` mapoval na třídu `App\UI\HomePresenter`, což dosáhneme touto konfigurací: ```neon application: mapping: App\UI\*Presenter ``` -Název presenteru `Home` se nahradí za hvezdičku v masce třídy `App\UI\*Presenter` a máme výsledný název třídy `App\UI\HomePresenter`. Snadné! +Název presenteru `Home` nahradí hvězdičku v masce `App\UI\*Presenter`, čímž získáme výsledný název třídy `App\UI\HomePresenter`. Jednoduché! -Nicméně jak vidíte v ukázkách v této a dalších kapitolách, třídy presenterů se umisťují ještě do eponymních podadresářů, tj. presenter `Home` se mapuje na třídu `App\UI\Home\HomePresenter`. To zajistí zdvojená dvojtečka (vyžaduje Nette Application 3.2): +Jak ale vidíte v ukázkách v této a dalších kapitolách, třídy presenterů umisťujeme do eponymních podadresářů, například presenter `Home` se mapuje na třídu `App\UI\Home\HomePresenter`. Toho dosáhneme zdvojením dvojtečky (vyžaduje Nette Application 3.2): ```neon application: mapping: App\UI\**Presenter ``` -A nyní presentery rozčleníme do modulů. Pro každý modul můžeme definovat vlastní mapování: +Nyní přistoupíme k mapování presenterů do modulů. Pro každý modul můžeme definovat specifické mapování: ```neon application: @@ -153,9 +153,9 @@ application: Api: App\Api\*Presenter ``` -Tato konfigurace říká, že presenter `Front:Home` se mapuje na třídu `App\UI\Front\Home\HomePresenter`, zatímco třeba presenter `Api:OAuth` na třídu `App\Api\OAuthPresenter`. +Podle této konfigurace se presenter `Front:Home` mapuje na třídu `App\UI\Front\Home\HomePresenter`, zatímco presenter `Api:OAuth` na třídu `App\Api\OAuthPresenter`. -Protože moduly `Front` i `Admin` mají podobný způsob mapování a takových modulů bude nejspíš více, dá se vytvořit obecné pravidlo, které tyto dvě nahradí. V masce třídy nám přibude hvezdička navíc právě pro modul: +Protože moduly `Front` i `Admin` mají podobný způsob mapování a takových modulů bude nejspíš více, je možné vytvořit obecné pravidlo, které je nahradí. Do masky třídy přibude nová hvězdička pro modul: ```neon application: @@ -164,7 +164,7 @@ application: Api: App\Api\*Presenter ``` -Ale co když používáme vícenásobně zanořené moduly a máme třeba presenter `Admin:User:Edit`? V takovém případě se segment s hvězdičkou představující modul pro každou úroveň jednoduše zopakuje a výsledkem bude třída `App\UI\Admin\User\Edit\EditPresenter`. +Pro vícenásobně zanořené moduly, jako je například presenter `Admin:User:Edit`, se segment s hvězdičkou opakuje pro každou úroveň a výsledkem je třída `App\UI\Admin\User\Edit\EditPresenter`. Alternativním zápisem je místo řetězce použít pole skládající se ze tří segmentů. Tento zápis je ekvivaletní s předchozím: