Skip to content

Commit

Permalink
x
Browse files Browse the repository at this point in the history
  • Loading branch information
@dg
dg committed Apr 18, 2024
1 parent 37af13f commit 5a5382f
Showing 1 changed file with 18 additions and 18 deletions.
36 changes: 18 additions & 18 deletions application/cs/modules.texy
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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/
Expand All @@ -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;
Expand All @@ -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/
Expand All @@ -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/
Expand All @@ -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ů
Expand Down Expand Up @@ -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:
Expand All @@ -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:
Expand All @@ -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:

Expand Down

0 comments on commit 5a5382f

Please sign in to comment.