From 8974872afe4e554b5667f4cfda31677159d890fc Mon Sep 17 00:00:00 2001 From: David Grudl Date: Thu, 18 Apr 2024 22:40:12 +0200 Subject: [PATCH 01/47] nette/application 3.2.3: new directory structure --- application/bg/how-it-works.texy | 25 +++--- application/bg/modules.texy | 128 +++++++++++++++++++----------- application/bg/templates.texy | 84 +++++++++++++++----- application/cs/how-it-works.texy | 25 +++--- application/cs/modules.texy | 118 +++++++++++++++++---------- application/cs/templates.texy | 76 ++++++++++++++---- application/de/how-it-works.texy | 25 +++--- application/de/modules.texy | 132 ++++++++++++++++++++----------- application/de/templates.texy | 84 +++++++++++++++----- application/el/how-it-works.texy | 25 +++--- application/el/modules.texy | 128 +++++++++++++++++++----------- application/el/templates.texy | 84 +++++++++++++++----- application/en/how-it-works.texy | 25 +++--- application/en/modules.texy | 128 +++++++++++++++++++----------- application/en/templates.texy | 84 +++++++++++++++----- application/es/how-it-works.texy | 25 +++--- application/es/modules.texy | 132 ++++++++++++++++++++----------- application/es/templates.texy | 84 +++++++++++++++----- application/fr/how-it-works.texy | 25 +++--- application/fr/modules.texy | 128 +++++++++++++++++++----------- application/fr/templates.texy | 84 +++++++++++++++----- application/hu/how-it-works.texy | 25 +++--- application/hu/modules.texy | 132 ++++++++++++++++++++----------- application/hu/templates.texy | 84 +++++++++++++++----- application/it/how-it-works.texy | 25 +++--- application/it/modules.texy | 126 ++++++++++++++++++----------- application/it/templates.texy | 84 +++++++++++++++----- application/pl/how-it-works.texy | 25 +++--- application/pl/modules.texy | 128 +++++++++++++++++++----------- application/pl/templates.texy | 84 +++++++++++++++----- application/pt/how-it-works.texy | 25 +++--- application/pt/modules.texy | 128 +++++++++++++++++++----------- application/pt/templates.texy | 84 +++++++++++++++----- application/ro/how-it-works.texy | 25 +++--- application/ro/modules.texy | 128 +++++++++++++++++++----------- application/ro/templates.texy | 84 +++++++++++++++----- application/ru/how-it-works.texy | 25 +++--- application/ru/modules.texy | 126 ++++++++++++++++++----------- application/ru/templates.texy | 84 +++++++++++++++----- application/sl/how-it-works.texy | 25 +++--- application/sl/modules.texy | 126 ++++++++++++++++++----------- application/sl/templates.texy | 84 +++++++++++++++----- application/tr/how-it-works.texy | 25 +++--- application/tr/modules.texy | 128 +++++++++++++++++++----------- application/tr/templates.texy | 84 +++++++++++++++----- application/uk/how-it-works.texy | 25 +++--- application/uk/modules.texy | 130 +++++++++++++++++++----------- application/uk/templates.texy | 84 +++++++++++++++----- 48 files changed, 2523 insertions(+), 1259 deletions(-) diff --git a/application/bg/how-it-works.texy b/application/bg/how-it-works.texy index 3cdb0786e2..5ca8332a47 100644 --- a/application/bg/how-it-works.texy +++ b/application/bg/how-it-works.texy @@ -22,13 +22,13 @@ /--pre web-project/ ├── app/ ← каталог с приложением -│ ├── Presenters/ ← классы презентеров -│ │ ├── HomePresenter.php ← Класс презентера главной страницы -│ │ └── templates/ ← директория шаблонов -│ │ ├── @layout.latte ← шаблон общего макета -│ │ └── Home/ ← шаблоны презентера главной страницы -│ │ └── default.latte ← шаблон действия `default` -│ ├── Router/ ← конфигурация URL-адресов +│ ├── Основни/ ← основни необходими класове +│ │ └── RouterFactory.php ← конфигуриране на URL адреси +│ ├── UI/ ← презентатори, шаблони и др. +│ │ ├── @layout.latte ← шаблон на споделено оформление +│ │ └── Home/ ← Директория за водещи +│ │ ├── HomePresenter.php ← Клас на Home Presenter +│ │ └── default.latte ← шаблон за действие default │ └── Bootstrap.php ← загрузочный класс Bootstrap ├── bin/ ← скрипты командной строки ├── config/ ← файлы конфигурации @@ -91,7 +91,7 @@ Nette е наставник, който ви напътства да пишет Приложението започва с искане към т.нар. маршрутизатор да реши на кой от презентаторите да изпрати текущата заявка за обработка. Маршрутизаторът решава чия е отговорността. Той разглежда входния URL адрес `https://example.com/product/123`, който иска продукт `показать` с `id: 123` като действие. Добър навик е да записвате двойките водещ + действие, разделени с двоеточие: `Продукт:показать`. -Следователно маршрутизаторът е преобразувал URL адреса в двойка `Presenter:action` + параметри, в нашия случай `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Router/RouterFactory.php`, и ще го опишем подробно в главата [Маршрутизация |routing]. +Следователно маршрутизаторът е преобразувал URL адреса в двойка `Presenter:action` + параметри, в нашия случай `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Core/RouterFactory.php`, и ще го опишем подробно в главата [Маршрутизация |routing]. Да продължим. Приложението вече знае името на водещия и може да продължи. Чрез създаване на обект `ProductPresenter`, който е кодът на предентера `Product`. По-точно, той иска от контейнера DI да създаде презентатора, тъй като създаването на обекти е негова работа. @@ -121,12 +121,9 @@ class ProductPresenter extends Nette\Application\UI\Presenter След това водещият връща отговор. Това може да бъде HTML страница, изображение, XML документ, файл, изпратен от диска, JSON или пренасочване към друга страница. Важно е да се отбележи, че ако не посочим изрично как да се отговори (какъвто е случаят с `ProductPresenter`), отговорът ще бъде шаблон, показващ HTML страница. Защо? Ами защото в 99% от случаите искаме да покажем шаблон, водещият приема това поведение по подразбиране и иска да улесни работата ни. Това е гледната точка на Нете. -Дори не е необходимо да указваме кой шаблон да се покаже, той сам извежда пътя до него според проста логика. В случая с водещия `Product` и действието `show`, той се опитва да провери дали някой от тези файлове с шаблони съществува спрямо директорията, в която се намира класът `ProductPresenter`: +Дори не е необходимо да посочваме кой шаблон да се визуализира; рамката сама ще определи пътя. В случая с действието `show` тя просто се опитва да зареди шаблона `show.latte` в директорията с класа `ProductPresenter`. Тя също така се опитва да намери оформлението във файла `@layout.latte` (повече за [търсенето на шаблони |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -След това се показва шаблонът. Задачата на водещия и на цялото приложение вече е изпълнена. Ако шаблонът не съществува, ще бъде върната страница за грешка 404. Можете да прочетете повече за водещите на страницата [Водещи |presenters]. +Впоследствие шаблоните се визуализират. С това задачата на презентатора и на цялото приложение е изпълнена и работата е приключила. Ако шаблонът не съществува, ще бъде върната страница с грешка 404. Можете да прочетете повече за презентаторите на страницата [Презентатори |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ class ProductPresenter extends Nette\Application\UI\Presenter 3) маршрутизаторът декодира URL адреса като двойка `Home:default` 4) обектът е създаден `HomePresenter` 5) извиква се методът `renderDefault()` (ако съществува) -6) шаблонът `templates/Home/default.latte` с оформлението `templates/@layout.latte` се визуализира +6) шаблонът `default.latte` с оформлението `@layout.latte` се визуализира Може би сега ще се сблъскате с много нови концепции, но ние смятаме, че те имат смисъл. Създаването на приложения в Nette е лесно. diff --git a/application/bg/modules.texy b/application/bg/modules.texy index ddecd3f1a8..b675e91dd1 100644 --- a/application/bg/modules.texy +++ b/application/bg/modules.texy @@ -2,29 +2,31 @@ ****** .[perex] -В Nette модулите са логическите единици, от които се състои едно приложение. Те включват главни модули, шаблони, евентуално компоненти и класове модели. +Модулите внасят яснота в приложенията на Nette, като улесняват лесното им разделяне на логически единици. -Един компонент за презентатори и един за шаблони няма да са достатъчни за реални проекти. Натрупването на десетки файлове в една папка е меко казано неорганизирано. Как да излезем от тази ситуация? Просто ги разделяме на поддиректории на диска и на пространства от имена в кода. Точно това правят модулите Nette. - -Така че нека забравим за една папка за презентатори и шаблони и вместо това да създадем модули като `Admin` и `Front`. +Подобно на организирането на файловете в папки на твърдия диск, в Nette можем да разделим презентатори, шаблони и други спомагателни класове на модули. Как работи това на практика? Просто чрез включване на нови поддиректории в структурата. Ето един пример за структура с два модула - Front и Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← директория с модулями -│ ├── Admin/ ← модуль Admin -│ │ ├── Presenters/ ← его презентеры -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← модуль Front -│ └── Presenters/ ← его презентеры -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Тази структура на директориите ще бъде отразена в пространствата за имена на класовете, така че например `DashboardPresenter` ще бъде в пространството `App\Modules\Admin\Presenters`: +Тази структура на директориите е отразена в пространствата от имена на класовете, така че например `DashboardPresenter` се намира в пространството от имена `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Главното устройство `Dashboard` в модула `Admin` се обозначава в приложението с помощта на запис с двойна точка като `Admin:Dashboard`, а неговото действие `default` се обозначава като `Admin:Dashboard:default`. -И откъде Nette знае, че `Admin:Dashboard` представлява класа `App\Modules\Admin\Presenters\DashboardPresenter`? Говорим за това, като използваме [картографирането |#Mapping] в конфигурацията. -Така че дадената структура не е фиксирана и можете да я променяте по свое усмотрение. +В приложението се позоваваме на презентатора `Dashboard` в рамките на модула `Admin`, като използваме запис с двоеточие като `Admin:Dashboard`. За неговото действие `default` го наричаме `Admin:Dashboard:default`. -Модулите, разбира се, могат да съдържат всички други части, освен презентатори и шаблони, като компоненти, класове модели и др. +Представената структура не е твърда; в конфигурацията можете [напълно |#mapping] да [я адаптирате към вашите нужди |#mapping]. .[tip] + +Модулите могат да включват всички други файлове, като компоненти и спомагателни класове, в допълнение към презентаторите и шаблоните. Ако обмисляте къде да ги поставите, помислете за използването на папка `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Вложени модули .[#toc-nested-modules] ------------------------------------- -Модулите не трябва да образуват само плоска структура, можете да създавате и подмодули, например: +Модулите могат да имат няколко нива на влагане, подобно на структурата на директориите на диска: /--pre -app/ -├── Modules/ ← директория с модулями -│ ├── Blog/ ← модуль Blog -│ │ ├── Admin/ ← подмодуль Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← подмодуль Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← модуль Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Така модулът `Blog` се разделя на подмодули `Admin` и `Front`. Това отново ще бъде отразено в пространствата от имена, които ще бъдат `App\Modules\Blog\Admin\Presenters` и т.н. Главният модул `Dashboard` в рамките на подмодула се нарича `Blog:Admin:Dashboard`. +Модулът `Blog` е разделен на подмодули `Admin` и `Front`. Това е отразено и в пространствата от имена, които след това се появяват като `App\UI\Blog\Admin` и по подобен начин. За да се позовем на презентатора `Dashboard` в рамките на подмодула `Admin`, го наричаме `Blog:Admin:Dashboard`. -Разклоненията могат да бъдат толкова дълбоки, колкото искате, така че можете да създавате подмодули. +Влагането може да бъде толкова дълбоко, колкото е необходимо, като позволява създаването на подмодули. + +Например, ако в администрацията имате много презентатори, свързани с управлението на поръчки, като `OrderDetail`, `OrderEdit`, `OrderDispatch` и т.н., може да създадете модул `Order`, в който ще бъдат организирани презентатори като `Detail`, `Edit`, `Dispatch` и други. Създаване на връзки .[#toc-creating-links] @@ -102,46 +118,66 @@ class DashboardPresenter extends Nette\Application\UI\Presenter Картографиране .[#toc-mapping] ------------------------------ -Определя правилата, по които името на класа се извежда от главното име. Записваме ги в [конфигурацията |configuration] под ключа `application › mapping`. +Съпоставянето определя правилата за извеждане на името на класа от името на водещия. Тези правила се посочват в [конфигурацията |configuration] под ключа `application › mapping`. + +Структурите на директориите, споменати по-рано на тази страница, се основават на следното съпоставяне: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Нека започнем с пример, при който не се използват модули. Искаме само главните класове да имат пространството от имена `App\Presenters`. Това означава, че искаме главното име, например `Home`, да се съпостави с класа `App\Presenters\HomePresenter`. Това може да се постигне със следната конфигурация: +Как работи картографирането? За по-добро разбиране нека първо си представим приложение без модули. Искаме класовете на презентаторите да попадат в пространството от имена `App\UI`, така че презентаторът `Home` да се съпостави с класа `App\UI\HomePresenter`. Това може да се постигне с тази конфигурация: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Името на водещия се заменя със звездичка и резултатът е името на класа. Лесно! +Това съпоставяне се извършва чрез замяна на звездичката в маската `App\UI\*Presenter` с името на презентатора `Home`, в резултат на което се получава крайното име на класа `App\UI\HomePresenter`. Просто! + +Въпреки това, както можете да видите в примерите в тази и други глави, ние поставяме класовете на водещите в едноименни поддиректории, например водещият `Home` е картографиран към клас `App\UI\Home\HomePresenter`. Това се постига чрез удвояване на звездичката (изисква Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Ако разделим презентаторите на модули, можем да използваме различни карти за всеки модул: +Сега нека преминем към картографиране на презентатори в модули. Можем да дефинираме специфични съпоставки за всеки модул: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Сега водещият `Front:Home` е определен от класа `App\Modules\Front\HomePresenter`, а презентер `Admin:Dashboard` - `App\AdminModule\DashboardPresenter`. +Според тази конфигурация презентаторът `Front:Home` се съотнася към класа `App\UI\Front\Home\HomePresenter`, а презентаторът `Api:OAuth` се съотнася към класа `App\Api\OAuthPresenter`. -Би било по-удобно да се създаде общо правило (звездичка), което да замени първите две правила, и да се добави допълнителна звездичка само за модула: +Тъй като модулите `Front` и `Admin` имат сходен подход на картографиране и вероятно има повече такива модули, е възможно да се създаде общо правило, което да ги замени. Към маската на класа се добавя нова звездичка за модула: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Но какво става, ако използваме няколко вложени модула и имаме например главен модул `Admin:User:Edit`? В този случай сегментът със звездичка, представляващ модула за всяко ниво, просто ще се повтори и резултатът ще бъде класът `App\Modules\Admin\User\Presenters\EditPresenter`. +За вложени модули на няколко нива, като например водещия `Admin:User:Edit`, сегментът със звездичка се повтаря за всяко ниво, в резултат на което се получава клас `App\UI\Admin\User\Edit\EditPresenter`. -Алтернативен начин за записване е използването на масив от три сегмента вместо низ. Този запис е еквивалентен на предишния: +Алтернативен запис е да се използва масив, съставен от три сегмента, вместо низ. Този запис е еквивалентен на предишния: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Стойността по подразбиране е `*Module\*Presenter`. +Ако имаме само едно правило в конфигурацията, общото, можем да го напишем накратко: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/bg/templates.texy b/application/bg/templates.texy index 850d3e2ecd..584b6cbff3 100644 --- a/application/bg/templates.texy +++ b/application/bg/templates.texy @@ -34,35 +34,81 @@ Nette използва системата за шаблони [Latte |latte:]. L Той дефинира блок `content`, който се вмъква вместо `{include content}` в оформлението, и замества блока `title`, който презаписва `{block title}` в оформлението. Опитайте се да си представите резултата. -Търсене на шаблони .[#toc-search-for-templates] ------------------------------------------------ +Търсене на шаблони .[#toc-template-lookup] +------------------------------------------ + +В презентаторите не е необходимо да посочвате кой шаблон трябва да бъде визуализиран; рамката автоматично ще определи пътя, което ще ви улесни при кодирането. + +Ако използвате структура от директории, в която всеки презентатор има своя собствена директория, просто поставете шаблона в тази директория под името на действието (т.е. изглед). Например, за действието `default` използвайте шаблона `default.latte`: -Пътят към шаблоните се определя от главния модул с помощта на проста логика. Той ще се опита да провери дали има някой от тези файлове, разположен спрямо главната директория на класа, където `` е името на текущия главен модул, а `` е името на текущото събитие: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Ако използвате структура, в която презентаторите са заедно в една директория, а шаблоните - в папка `templates`, запишете я или във файл `..latte` или `/.latte`: -Ако шаблонът не бъде намерен, ще се опита да търси в директорията `templates` едно ниво по-нагоре, т.е. на същото ниво като директорията с класа на водещия. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Ако шаблонът не бъде намерен и там, отговорът ще бъде [грешка 404 |presenters#Error 404 etc.]. +Директорията `templates` може да бъде поставена и едно ниво по-нагоре, на същото ниво като директорията с класовете на водещите. -Можете също така да промените изгледа с помощта на `$this->setView('jineView')`. Или вместо да търсите директно, посочете името на файла с шаблона, като използвате `$this->template->setFile('/path/to/template.latte')`. +Ако шаблонът не бъде намерен, презентаторът отговаря с [грешка 404 - страница не е намерена |presenters#Error 404 etc]. + +Можете да промените изгледа, като използвате `$this->setView('anotherView')`. Възможно е също така директно да посочите файла с шаблона с помощта на `$this->template->setFile('/path/to/template.latte')`. .[note] -Файловете, които се търсят за шаблони, могат да се променят чрез наслагване на метода [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], който връща масив от възможни имена на файлове. +Файловете, в които се търсят шаблони, могат да се променят чрез надграждане на метода [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], който връща масив от възможни имена на файлове. + + +Търсене на шаблони за оформление .[#toc-layout-template-lookup] +--------------------------------------------------------------- + +Nette също така автоматично търси файла с оформлението. + +Ако използвате структура на директориите, в която всеки водещ има своя собствена директория, поставете макета или в папката с водещия, ако е специфичен само за него, или на по-високо ниво, ако е общ за няколко водещи: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Ако използвате структура, в която презентаторите са групирани в една директория, а шаблоните са в папка `templates`, макетът ще се очаква на следните места: -В тези файлове се очаква оформление: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` Разположение, общо за няколко високоговорителя +Ако презентаторът е в [модул |modules], той ще търси и по-нагоре в дървото на директориите според вложеността на модула. -Къде: `` е името на текущия водещ, а `` е името на оформлението, което по подразбиране е `'layout'`. Името може да бъде променено с помощта на `$this->setLayout('jinyLayout')`, така че ще бъдат изпробвани файлове `@jinyLayout.latte`. +Името на макета може да бъде променено с помощта на `$this->setLayout('layoutAdmin')` и тогава то ще бъде очаквано във файла `@layoutAdmin.latte`. Можете също така директно да посочите файла с шаблона на оформлението, като използвате `$this->setLayout('/path/to/template.latte')`. -Можете също така директно да посочите името на файла на шаблона за оформление, като използвате `$this->setLayout('/path/to/template.latte')`. Използването на `$this->setLayout(false)` деактивира проследяването на оформлението. +Използването на `$this->setLayout(false)` или на тага `{layout none}` вътре в шаблона деактивира търсенето на оформление. .[note] -Файловете, в които се търсят шаблоните за оформление, могат да се променят чрез наслагване на метода [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], който връща масив от възможни имена на файлове. +Файловете, в които се търсят шаблони за оформление, могат да бъдат променяни чрез надграждане на метода [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], който връща масив от възможни имена на файлове. Променливи в шаблона .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template Можете също така да си позволите лукса да шепнете в шаблоните, просто инсталирайте плъгина Latte в PhpStorm и поставете името на класа в началото на шаблона, за повече информация вижте статията "Latte: как да въведем системата":https://blog.nette.org/bg/latte-kak-da-izpolzvame-sistemata-ot-tipove: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Версия 3 на Latte предлага по-усъвършенстван начин за създаване на [разширение за |latte:creating-extension] всеки уеб проект. Ето кратък пример за такъв клас: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ final class LatteExtension extends Latte\Extension ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/cs/how-it-works.texy b/application/cs/how-it-works.texy index 92ff5e9d9b..d58cd6c833 100644 --- a/application/cs/how-it-works.texy +++ b/application/cs/how-it-works.texy @@ -22,13 +22,13 @@ Adresářová struktura vypadá nějak takto: /--pre web-project/ ├── app/ ← adresář s aplikací -│ ├── Presenters/ ← presentery a šablony -│ │ ├── HomePresenter.php ← třída presenteru Home -│ │ └── templates/ ← adresář se šablonami -│ │ ├── @layout.latte ← šablona layoutu -│ │ └── Home/ ← šablony presenteru Home -│ │ └── default.latte ← šablona akce 'default' -│ ├── Router/ ← konfigurace URL adres +│ ├── Core/ ← základní třídy nutné pro chod +│ │ └── RouterFactory.php ← konfigurace URL adres +│ ├── UI/ ← presentery, šablony & spol. +│ │ ├── @layout.latte ← šablona layoutu +│ │ └── Home/ ← adresář presenteru Home +│ │ ├── HomePresenter.php ← třída presenteru Home +│ │ └── default.latte ← šablona akce default │ └── Bootstrap.php ← zaváděcí třída Bootstrap ├── bin/ ← skripty spouštěné z příkazové řádky ├── config/ ← konfigurační soubory @@ -91,7 +91,7 @@ Aplikace psané v Nette se člení do spousty tzv. presenterů (v jiných framew Application začne tím, že požádá tzv. router, aby rozhodl, kterému z presenterů předat aktuální požadavek k vyřízení. Router rozhodne, čí je to zodpovědnost. Podívá se na vstupní URL `https://example.com/product/123` a na základě toho, jak je nastavený, rozhodne, že tohle je práce např. pro **presenter** `Product`, po kterém bude chtít jako **akci** zobrazení (`show`) produktu s `id: 123`. Dvojici presenter + akce je dobrým zvykem zapisovat oddělené dvojtečkou jako `Product:show`. -Tedy router transformoval URL na dvojici `Presenter:action` + parametry, v našem případě `Product:show` + `id: 123`. Jak takový router vypadá se můžete podívat v souboru `app/Router/RouterFactory.php` a podrobně ho popisujeme v kapitole [Routing]. +Tedy router transformoval URL na dvojici `Presenter:action` + parametry, v našem případě `Product:show` + `id: 123`. Jak takový router vypadá se můžete podívat v souboru `app/Core/RouterFactory.php` a podrobně ho popisujeme v kapitole [Routing]. Pojďme dál. Application už zná jméno presenteru a může pokračovat dál. Tím že vyrobí objekt třídy `ProductPresenter`, což je kód presenteru `Product`. Přesněji řečeno, požádá DI kontejner, aby presenter vyrobil, protože od vyrábění je tu on. @@ -121,12 +121,9 @@ Takže, zavolala se metoda `renderShow(123)`, jejíž kód je sice smyšlený p Následně presenter vrátí odpověď. Tou může být HTML stránka, obrázek, XML dokument, odeslání souboru z disku, JSON nebo třeba přesměrování na jinou stránku. Důležité je, že pokud explicitně neřekneme, jak má odpovědět (což je případ `ProductPresenter`), bude odpovědí vykreslení šablony s HTML stránkou. Proč? Protože v 99 % případů chceme vykreslit šablonu, tudíž presenter tohle chování bere jako výchozí a chce nám ulehčit práci. To je smyslem Nette. -Nemusíme ani uvádět, jakou šablonu vykreslit, cestu k ní si odvodí podle jednoduché logiky. V případě presenteru `Product` a akce `show` zkusí, zda existuje jeden z těchto souborů se šablonou uložených relativně od adresáře s třídou `ProductPresenter`: +Nemusíme ani uvádět, jakou šablonu vykreslit, cestu k ní si odvodí sám. V případě akce `show` jednodušše zkusí načíst šablonu `show.latte` v adresáři s třídou `ProductPresenter`. Taktéž se pokusí dohledat layout v souboru `@layout.latte` (podrobněji o [dohledávání šablon|templates#hledani-sablon]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Taktéž se pokusí dohledat layout v souboru `@layout.latte` a následně šablonu vykreslí. Tím je úkol presenteru i celé aplikace dokonán a dílo jest završeno. Pokud by šablona neexistovala, vrátí se stránka s chybou 404. Více se o presenterech dočtete na stránce [Presentery|presenters]. +A následně šablony vykreslí. Tím je úkol presenteru i celé aplikace dokonán a dílo jest završeno. Pokud by šablona neexistovala, vrátí se stránka s chybou 404. Více se o presenterech dočtete na stránce [Presentery|presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Pro jistotu, zkusme si zrekapitulovat celý proces s trošku jinou URL: 3) router URL dekóduje jako dvojici `Home:default` 4) vytvoří se objekt třídy `HomePresenter` 5) zavolá se metoda `renderDefault()` (pokud existuje) -6) vykreslí se šablona např. `templates/Home/default.latte` s layoutem např. `templates/@layout.latte` +6) vykreslí se šablona např. `default.latte` s layoutem např. `@layout.latte` Možná jste se teď setkali s velkou spoustou nových pojmů, ale věříme, že dávají smysl. Tvorba aplikací v Nette je ohromná pohodička. diff --git a/application/cs/modules.texy b/application/cs/modules.texy index dd58b910d4..f215baec63 100644 --- a/application/cs/modules.texy +++ b/application/cs/modules.texy @@ -2,29 +2,31 @@ Moduly ****** .[perex] -Moduly představují v Nette logické celky, ze kterých se aplikace skládá. Jejich součástí jsou presentery, šablony, případně i komponenty a modelové třídy. +Moduly vnášejí do Nette aplikací přehlednost díky snadnému členění do logických celků. -S jednou složkou pro presentery a jednou pro šablony bychom si u reálných projektů nevystačili. Mít v jedné složce desítky souborů je minimálně nepřehledné. Jak z toho ven? Jednoduše je na disku rozdělíme do podadresářů a v kódu do jmenných prostorů. A přesně to jsou v Nette moduly. - -Zapomeňme tedy na jednu složku pro presentery a šablony a místo toho vytvoříme moduly, například `Admin` a `Front`. +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/ -├── Presenters/ -├── Modules/ ← adresář s moduly +app/ +├── UI/ │ ├── Admin/ ← modul Admin -│ │ ├── Presenters/ ← jeho presentery -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← modul Front -│ └── Presenters/ ← jeho presentery -│ └── ... +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← modul Front +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Tuto adresářovou strukturu budou reflektovat jmenné prostory tříd, takže třeba `DashboardPresenter` bude v prostoru `App\Modules\Admin\Presenters`: +Tato adresářová struktura se odráží ve jmenných prostorech tříd, takže například `DashboardPresenter` se nachází ve jmenném prostoru `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ 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`. -A jak Nette vlastní ví, že `Admin:Dashboard` představuje třídu `App\Modules\Admin\Presenters\DashboardPresenter`? To mu řekneme pomocí [#mapování] v konfiguraci. -Tedy uvedená struktura není pevná a můžete si ji upravit podle potřeb. +Na presenter `Dashboard` uvnitř modulu `Admin` odkazujeme v aplikaci pomocí dvojtečkové notace jako na `Admin:Dashboard`. Na jeho akci `default` potom jako na `Admin:Dashboard:default`. -Moduly mohou kromě presenterů a šablon samozřejmě obsahovat všechny další součásti, jako jsou třeba komponenty, modelové třídy, atd. +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ě zahrnovat všechny ostatní soubory, jako jsou například komponenty a pomocné třídy. Pokud uvažujete, kam je zařadit, zvažte využití složky `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Vnořené moduly -------------- -Moduly nemusí tvořit jen plochou strukturu, lze vytvářet i submoduly, například: +Moduly mohou mít více úrovní zanoření, podobně jako adresářová struktura na disku: /--pre -app/ -├── Modules/ ← adresář s moduly +app/ +├── UI/ │ ├── Blog/ ← modul Blog │ │ ├── Admin/ ← submodul Admin -│ │ │ ├── Presenters/ +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← submodul Front +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodul Front -│ │ ├── Presenters/ -│ │ └── ... │ ├── Forum/ ← modul Forum │ │ └── ... \-- -Tedy modul `Blog` je rozdělen do submodulů `Admin` a `Front`. A opět se to odrazí na jmenných prostorech, které budou `App\Modules\Blog\Admin\Presenters` apod. 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 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ů @@ -102,46 +118,66 @@ 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`. + +Adresářové struktury uváděné výše na této stránce vycházejí z tohoto mapování: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Začněme ukázkou, která moduly nepoužívá. Budeme jen chtít, aby třídy presenterů měly jmenný prostor `App\Presenters`. Tedy aby se presenter například `Home` mapoval na třídu `App\Presenters\HomePresenter`. Toho lze docílit následující konfigurací: +Jak mapování funguje? Pro lepší pochopení si nejprve představme 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\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Název presenteru se nahradí za hvezdičku v masce třídy a výsledkem je název třídy. Snadné! +Mapování funguje tak, že 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é! + +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 +``` -Pokud presentery členíme do modulů, můžeme pro každý modul mít 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: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Nyní se presenter `Front:Home` mapuje na třídu `App\Modules\Front\Presenters\HomePresenter` a presenter `Admin:Dashboard` na třídu `App\Modules\Admin\Presenters\DashboardPresenter`. +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`. -Praktičtější bude vytvořit obecné (hvězdičkové) pravidlo, které první dvě nahradí. V masce třídy 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 tak přibude nová hvězdička pro modul: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter 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\Modules\Admin\User\Presenters\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: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Výchozí hodnotou je `*Module\*Presenter`. +Pokud bychom měli v konfiguraci jen jediné pravidlo, ono obecné, můžeme zkráceně zapsat: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/cs/templates.texy b/application/cs/templates.texy index 5d0de8dc1a..8caa687b44 100644 --- a/application/cs/templates.texy +++ b/application/cs/templates.texy @@ -37,29 +37,75 @@ Ta definuje blok `content`, který se vloží na místo `{include content}` v la Hledání šablon -------------- -Cestu k šablonám odvodí presenter podle jednoduché logiky. Zkusí, zda existuje jeden z těchto souborů umístěných relativně od adresáře s třídou presenteru, kde `` je název aktuálního presenteru a `` je název aktuální akce: +Nemusíte v presenterech uvádět, jaká šablona se má vykreslit, framework cestu odvodí sám a ušetří vám psaní. -- `templates//.latte` -- `templates/..latte` +Pokud používáte adresářovou strukturu, kde každý presenter má vlastní adresář, jednodušše umístěte šablonu do tohoto adresáře pod jménem akce (resp. view), tj. pro akci `default` použijte šablonu `default.latte`: -Pokud šablonu nenajde, zkusí hledat ještě v adresáři `templates` o úroveň výš, tj. na stejné úrovni, jako je adresář s třídou presenteru. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Pokud ani tam šablonu nenajde, je odpovědí [chyba 404|presenters#Chyba 404 a spol.]. +Pokud používáte strukturu, kde jsou společně presentery v jednom adresáři a šablony ve složce `templates`, uložte ji buď do souboru `..latte` nebo `/.latte`: -Můžete také změnit view pomocí `$this->setView('jineView')`. Nebo místo dohledávání přímo určit jméno souboru se šablonou pomocí `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1. varianta + └── Home/ + └── default.latte ← 2. varianta +\-- + +Adresář `templates` může být umístěn také o úroveň výš, tj. na stejné úrovni, jako je adresář s třídami presenterů. + +Pokud se šablona nenajde, presenter odpoví [chybou 404 - page not found|presenters#Chyba 404 a spol]. + +View změníte pomocí `$this->setView('jineView')`. Také lze přímo určit soubor se šablonou pomocí `$this->template->setFile('/path/to/template.latte')`. .[note] Soubory, kde se dohledávají šablony, lze změnit překrytím metody [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], která vrací pole možných názvů souborů. -Layout se očekává v těchto souborech: -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` layout společný pro více presenterů +Hledání šablony layoutu +----------------------- + +Nette také automaticky dohledává soubor s layoutem. + +Pokud používáte adresářovou strukturu, kde každý presenter má vlastní adresář, umístěte layout buď do složky s presenterem, pokud je specifický jen pro něj, nebo o úroveň výš, pokud je společný pro více presenterů: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← společný layout + └── Home/ + ├── @layout.latte ← jen pro presenter Home + ├── HomePresenter.php + └── default.latte +\-- + +Pokud používáte strukturu, kde jsou společně presentery v jednom adresáři a šablony ve složce `templates`, bude se layout očekávat na těchto místech: + +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← společný layout + ├── Home.@layout.latte ← jen pro Home, 1. varianta + └── Home/ + └── @layout.latte ← jen pro Home, 2. varianta +\-- + +Pokud se presenter nachází v [modulu|modules], bude se dohledávat i o další adresářové úrovně výš, podle zanoření modulu. -Kde `` je název aktuálního presenteru a `` je název layoutu, což je standardně `'layout'`. Název lze změnit pomocí `$this->setLayout('jinyLayout')`, takže se budou zkoušet soubory `@jinyLayout.latte`. +Název layoutu lze změnit pomocí `$this->setLayout('layoutAdmin')` a pak se bude očekávat v souboru `@layoutAdmin.latte`. Také lze přímo určit soubor se šablonou layoutu pomocí `$this->setLayout('/path/to/template.latte')`. -Můžete také přímo určit jméno souboru se šablonou layoutu pomocí `$this->setLayout('/path/to/template.latte')`. Pomocí `$this->setLayout(false)` se dohledávání layoutu vypne. +Pomocí `$this->setLayout(false)` nebo značky `{layout none}` uvnitř šablony se dohledávání layoutu vypne. .[note] Soubory, kde se dohledávají šablony layoutu, lze změnit překrytím metody [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], která vrací pole možných názvů souborů. @@ -104,7 +150,7 @@ Anotace `@property-read` je určená pro IDE a statickou analýzu, díky ní bud Luxusu našeptávání si můžete dopřát i v šablonách, stačí do PhpStorm nainstalovat plugin pro Latte a uvést na začátek šablony název třídy, více v článku "Latte: jak na typový systém":https://blog.nette.org/cs/latte-jak-na-typovy-system: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte ve verzi 3 nabízí pokročilejší způsob a to vytvoření si [extension |latte:creating-extension] pro každý webový projekt. Kusý příklad takové třídy: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Zaregistrujeme ji pomocí [konfigurace |configuration#Šablony Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/de/how-it-works.texy b/application/de/how-it-works.texy index 010ba04907..fde1735364 100644 --- a/application/de/how-it-works.texy +++ b/application/de/how-it-works.texy @@ -22,13 +22,13 @@ Die Verzeichnisstruktur sieht in etwa so aus: /--pre web-project/ ├── app/ ← Verzeichnis mit Anwendung -│ ├── Presenters/ ← Presenter-Klassen -│ │ ├── HomePresenter.php ← Home presenterklasse -│ │ └── templates/ ← Vorlagenverzeichnis -│ │ ├── @layout.latte ← Vorlage für gemeinsames Layout -│ │ └── Home/ ← Vorlagen für Home-presenter -│ │ └── default.latte ← Vorlage für Aktion `default` -│ ├── Router/ ← Konfiguration von URL-Adressen +│ ├── Core/ ← grundlegende notwendige Klassen +│ │ └── RouterFactory.php ← Konfiguration der URL-Adressen +│ ├── UI/ ← Moderatoren, Vorlagen & Co. +│ │ ├── @layout.latte ← Vorlage für gemeinsames Layout +│ │ └── Home/ ← Home Presenter Verzeichnis +│ │ ├── HomePresenter.php ← Home Presenter Klasse +│ │ └── default.latte ← Vorlage für Aktion default │ └── Bootstrap.php ← bootende Klasse Bootstrap ├── bin/ ← Skripte für die Kommandozeile ├── config/ ← Konfigurationsdateien @@ -91,7 +91,7 @@ In Nette geschriebene Anwendungen sind in viele so genannte Presenter unterteilt Die Anwendung beginnt damit, dass sie den so genannten Router bittet, zu entscheiden, an welchen der Presenter die aktuelle Anfrage zur Bearbeitung weitergeleitet werden soll. Der Router entscheidet, wer dafür zuständig ist. Er sieht sich die Eingabe-URL `https://example.com/product/123` handelt, der ein Produkt mit `id: 123` als Aktion an `show` weiterleiten möchte. Es ist eine gute Angewohnheit, ein durch einen Doppelpunkt getrenntes Paar aus Präsentator + Aktion als `Product:show` zu schreiben. -Der Router verwandelt also die URL in ein Paar `Presenter:action` + Parameter, in unserem Fall `Product:show` + `id: 123`. Sie können sehen, wie ein Router in der Datei `app/Router/RouterFactory.php` aussieht, und wir werden ihn im Kapitel [Routing] ausführlich beschreiben. +Der Router verwandelt also die URL in ein Paar `Presenter:action` + Parameter, in unserem Fall `Product:show` + `id: 123`. Sie können sehen, wie ein Router in der Datei `app/Core/RouterFactory.php` aussieht, und wir werden ihn im Kapitel [Routing] ausführlich beschreiben. Machen wir weiter. Die Anwendung kennt bereits den Namen des Präsentators und kann fortfahren. Sie erstellt ein Objekt `ProductPresenter`, das den Code des Presenters `Product` darstellt. Genauer gesagt, sie bittet den DI-Container um die Erstellung des Presenters, denn die Erstellung von Objekten ist seine Aufgabe. @@ -121,12 +121,9 @@ So wurde die Methode `renderShow(123)` aufgerufen, deren Code ein fiktives Beisp Anschließend gibt der Präsentator die Antwort zurück. Dies kann eine HTML-Seite, ein Bild, ein XML-Dokument, das Senden einer Datei von der Festplatte, JSON oder die Routing zu einer anderen Seite sein. Wichtig ist, dass, wenn wir nicht ausdrücklich sagen, wie zu antworten ist (was bei `ProductPresenter` der Fall ist), die Antwort darin besteht, die Vorlage mit einer HTML-Seite wiederzugeben. Und warum? Nun, weil wir in 99 % der Fälle eine Vorlage zeichnen wollen, so dass der Präsentator dieses Verhalten als Standard annimmt und uns die Arbeit erleichtern will. Das ist der Punkt von Nette. -Wir müssen nicht einmal angeben, welche Vorlage gezeichnet werden soll, er leitet den Pfad dorthin nach einer einfachen Logik ab. Im Fall von presenter `Product` und action `show` versucht er zu sehen, ob eine dieser Vorlagendateien relativ zu dem Verzeichnis existiert, in dem sich die Klasse `ProductPresenter` befindet: +Wir müssen nicht einmal angeben, welche Vorlage gerendert werden soll; das Framework wird den Pfad selbst ermitteln. Im Fall der Aktion `show` versucht es einfach, die Vorlage `show.latte` im Verzeichnis mit der Klasse `ProductPresenter` zu laden. Es versucht auch, das Layout in der Datei `@layout.latte` zu finden (mehr über die [Vorlagensuche |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Außerdem wird versucht, das Layout in der Datei `@layout.latte` zu finden, und dann wird die Vorlage gerendert. Nun ist die Aufgabe des Präsentators und der gesamten Anwendung abgeschlossen. Wenn die Vorlage nicht existiert, wird eine Seite mit dem Fehler 404 zurückgegeben. Weitere Informationen über Präsentatoren finden Sie auf der Seite [Präsentatoren |Presenters]. +Anschließend werden die Vorlagen gerendert. Damit ist die Aufgabe des Präsentators und der gesamten Anwendung abgeschlossen, und die Arbeit ist getan. Wenn die Vorlage nicht vorhanden wäre, würde eine 404-Fehlerseite zurückgegeben werden. Weitere Informationen über Präsentatoren finden Sie auf der Seite [Präsentatoren |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Um sicherzugehen, versuchen wir, den gesamten Prozess mit einer etwas anderen UR 3) der Router dekodiert die URL als ein Paar `Home:default` 4) ein `HomePresenter` Objekt wird erstellt 5) die Methode `renderDefault()` wird aufgerufen (falls vorhanden) -6) eine Vorlage `templates/Home/default.latte` mit einem Layout `templates/@layout.latte` wird gerendert +6) eine Vorlage `default.latte` mit einem Layout `@layout.latte` wird gerendert Vielleicht sind Sie jetzt auf eine Menge neuer Konzepte gestoßen, aber wir glauben, dass sie sinnvoll sind. Das Erstellen von Anwendungen in Nette ist ein Kinderspiel. diff --git a/application/de/modules.texy b/application/de/modules.texy index 090bd4702e..75981ac23a 100644 --- a/application/de/modules.texy +++ b/application/de/modules.texy @@ -2,29 +2,31 @@ Module ****** .[perex] -In Nette stellen Module die logischen Einheiten dar, aus denen eine Anwendung besteht. Sie umfassen Presenter, Templates, eventuell auch Komponenten und Modellklassen. +Module bringen Klarheit in Nette-Anwendungen, indem sie eine einfache Unterteilung in logische Einheiten ermöglichen. -Ein Verzeichnis für Presenter und eines für Templates würde für echte Projekte nicht ausreichen. Dutzende von Dateien in einem Ordner zu haben, ist zumindest unorganisiert. Wie kommt man da wieder raus? Wir teilen sie einfach in Unterverzeichnisse auf der Festplatte und in Namensräume im Code auf. Und das ist genau das, was die Nette-Module tun. - -Vergessen wir also einen einzigen Ordner für Präsentatoren und Vorlagen und erstellen wir stattdessen Module, zum Beispiel `Admin` und `Front`. +Ähnlich wie bei der Organisation von Dateien in Ordnern auf einer Festplatte, können wir in Nette Presenter, Vorlagen und andere Hilfsklassen in Module unterteilen. Wie funktioniert das in der Praxis? Ganz einfach, indem man neue Unterverzeichnisse in die Struktur einfügt. Hier ist ein Beispiel für eine Struktur mit zwei Modulen, Front und Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← Verzeichnis mit Modulen -│ ├── Admin/ ← Modul Admin -│ │ ├── Presenters/ ← seine Presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← Modul Front -│ └── Presenters/ ← seine Presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Diese Verzeichnisstruktur spiegelt sich in den Klassennamensräumen wider, so dass z. B. `DashboardPresenter` im Namensraum `App\Modules\Admin\Presenters` liegt: +Diese Verzeichnisstruktur spiegelt sich in den Namespaces der Klassen wider, so befindet sich z.B. `DashboardPresenter` im Namespace `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Der Präsentator `Dashboard` innerhalb des Moduls `Admin` wird innerhalb der Anwendung mit der Doppelpunktschreibweise als `Admin:Dashboard` referenziert, und seine Aktion `default` als `Admin:Dashboard:default`. -Und woher weiß Nette selbst, dass `Admin:Dashboard` die Klasse `App\Modules\Admin\Presenters\DashboardPresenter` repräsentiert? Dies wird durch ein [Mapping |#mapping] in der Konfiguration festgelegt. -Die vorgegebene Struktur ist also nicht fest vorgegeben und kann nach Belieben verändert werden. +In der Anwendung wird der Presenter `Dashboard` innerhalb des Moduls `Admin` mit Doppelpunkt als `Admin:Dashboard` bezeichnet. Für die Aktion `default` wird er als `Admin:Dashboard:default` bezeichnet. -Module können neben Presentern und Templates natürlich auch alle anderen Elemente enthalten, wie z.B. Komponenten, Modellklassen, etc. +Die vorgestellte Struktur ist nicht starr; Sie können [sie |#mapping] in der Konfiguration [vollständig an Ihre Bedürfnisse anpassen |#mapping]. .[tip] + +Module können neben Presentern und Vorlagen auch alle anderen Dateien, wie Komponenten und Hilfsklassen, enthalten. Wenn Sie überlegen, wo Sie diese ablegen wollen, sollten Sie einen Ordner `Accessory` verwenden: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Verschachtelte Module .[#toc-nested-modules] -------------------------------------------- -Module müssen nicht nur eine flache Struktur bilden, Sie können auch Untermodule erstellen, zum Beispiel: +Module können mehrere Verschachtelungsebenen haben, ähnlich wie eine Verzeichnisstruktur auf einer Festplatte: /--pre -app/ -├── Modules/ ← Verzeichnis mit Modulen -│ ├── Blog/ ← Modul Blog -│ │ ├── Admin/ ← Submodul Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← Submodul Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← Modul Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -So wird das Modul `Blog` in die Untermodule `Admin` und `Front` aufgeteilt. Dies spiegelt sich auch in den Namensräumen wider, die dann `App\Modules\Blog\Admin\Presenters` usw. lauten. Der Präsentator `Dashboard` innerhalb des Submoduls wird als `Blog:Admin:Dashboard` bezeichnet. +Das Modul `Blog` ist in die Untermodule `Admin` und `Front` unterteilt. Dies spiegelt sich auch in den Namespaces wider, die dann als `App\UI\Blog\Admin` und ähnlich erscheinen. Um auf den Präsentator `Dashboard` innerhalb des Submoduls `Admin` zu verweisen, wird er als `Blog:Admin:Dashboard` bezeichnet. -Die Verschachtelung kann beliebig tief gehen, so dass Sub-Submodule erstellt werden können. +Die Verschachtelung kann so tief wie nötig sein und erlaubt die Erstellung von Sub-Submodulen. + +Wenn Sie zum Beispiel in der Verwaltung viele Präsentatoren haben, die mit der Auftragsverwaltung zusammenhängen, wie `OrderDetail`, `OrderEdit`, `OrderDispatch`, usw., könnten Sie ein `Order` Modul erstellen, in dem Präsentatoren wie `Detail`, `Edit`, `Dispatch` und andere organisiert werden. Erstellen von Links .[#toc-creating-links] @@ -99,49 +115,69 @@ Routing .[#toc-routing] Siehe [Kapitel über Routing |routing#Modules]. -Abbildung .[#toc-mapping] -------------------------- +Kartierung .[#toc-mapping] +-------------------------- + +Mapping definiert die Regeln für die Ableitung des Klassennamens aus dem Presenter-Namen. Diese Regeln werden in der [Konfiguration |configuration] unter dem Schlüssel `application › mapping` angegeben. + +Die oben auf dieser Seite erwähnten Verzeichnisstrukturen basieren auf der folgenden Zuordnung: -Legt die Regeln fest, nach denen der Klassenname aus dem Namen des Präsentators abgeleitet wird. Wir schreiben sie in die [Konfiguration |configuration] unter dem Schlüssel `application › mapping`. +```neon +application: + mapping: App\UI\*\**Presenter +``` -Beginnen wir mit einem Beispiel, das keine Module verwendet. Wir wollen nur, dass die Presenter-Klassen den Namespace `App\Presenters` haben. Das bedeutet, dass ein Presenter wie `Home` auf die Klasse `App\Presenters\HomePresenter` abgebildet werden soll. Dies kann durch die folgende Konfiguration erreicht werden: +Wie funktioniert das Mapping? Zum besseren Verständnis stellen wir uns zunächst eine Anwendung ohne Module vor. Wir wollen, dass die Presenter-Klassen in den Namensraum `App\UI` fallen, so dass der Presenter `Home` auf die Klasse `App\UI\HomePresenter` abgebildet wird. Dies kann mit dieser Konfiguration erreicht werden: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Der Name des Presenters wird durch das Sternchen in der Klassenmaske ersetzt und das Ergebnis ist der Klassenname. Einfach! +Diese Zuordnung funktioniert, indem das Sternchen in der Maske `App\UI\*Presenter` durch den Presenter-Namen `Home` ersetzt wird, was zu dem endgültigen Klassennamen `App\UI\HomePresenter` führt. Einfach! + +Wie Sie jedoch in den Beispielen in diesem und anderen Kapiteln sehen können, platzieren wir Presenter-Klassen in gleichnamigen Unterverzeichnissen, z. B. wird der Presenter `Home` der Klasse `App\UI\Home\HomePresenter` zugeordnet. Dies wird durch die Verdoppelung des Sternchens erreicht (erfordert Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Wenn wir die Vortragenden in Module unterteilen, können wir für jedes Modul eine eigene Zuordnung vornehmen: +Gehen wir nun dazu über, Presenter in Modulen abzubilden. Für jedes Modul können wir spezifische Zuordnungen definieren: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Der Referent `Front:Home` wird der Klasse `App\Modules\Front\Presenters\HomePresenter` zugeordnet und der Referent `Admin:Dashboard` der Klasse `App\Modules\Admin\Presenters\DashboardPresenter`. +Nach dieser Konfiguration wird der Präsentator `Front:Home` der Klasse `App\UI\Front\Home\HomePresenter` zugeordnet, während der Präsentator `Api:OAuth` der Klasse `App\Api\OAuthPresenter` zugeordnet wird. -Es ist praktischer, eine allgemeine (Stern-)Regel zu erstellen, um die ersten beiden zu ersetzen. Das zusätzliche Sternchen wird der Klassenmaske nur für dieses Modul hinzugefügt: +Da die Module `Front` und `Admin` einen ähnlichen Zuordnungsansatz haben und es wahrscheinlich noch mehr solcher Module gibt, ist es möglich, eine allgemeine Regel zu erstellen, die sie ersetzt. In der Klassenmaske wird ein neues Sternchen für das Modul hinzugefügt: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Was aber, wenn wir verschachtelte Module verwenden und einen Präsentator `Admin:User:Edit` haben? In diesem Fall wird das Segment mit dem Sternchen, das das Modul für jede Ebene darstellt, einfach wiederholt und das Ergebnis ist die Klasse `App\Modules\Admin\User\Presenters\EditPresenter`. +Bei mehrstufig verschachtelten Modulen, wie z. B. dem Moderator `Admin:User:Edit`, wird das Sternchen-Segment für jede Stufe wiederholt, was zu der Klasse `App\UI\Admin\User\Edit\EditPresenter` führt. -Eine alternative Schreibweise ist die Verwendung eines Arrays, das aus drei Segmenten anstelle einer Zeichenkette besteht. Diese Notation ist gleichwertig mit der vorherigen: +Eine alternative Schreibweise ist die Verwendung eines Arrays, das aus drei Segmenten besteht, anstelle einer Zeichenkette. Diese Notation ist äquivalent zur vorherigen: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Der Standardwert ist `*Module\*Presenter`. +Wenn wir nur eine Regel in der Konfiguration haben, die allgemeine, können wir kurz schreiben: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/de/templates.texy b/application/de/templates.texy index a21bd7266f..8860819f5f 100644 --- a/application/de/templates.texy +++ b/application/de/templates.texy @@ -34,35 +34,81 @@ Und dies könnte die Aktionsvorlage sein: Sie definiert den Block `content`, der anstelle von `{include content}` in das Layout eingefügt wird, und definiert auch den Block `title` neu, der `{block title}` im Layout überschreibt. Versuchen Sie, sich das Ergebnis vorzustellen. -Suche nach Templates .[#toc-search-for-templates] -------------------------------------------------- +Vorlage nachschlagen .[#toc-template-lookup] +-------------------------------------------- + +In Presentern müssen Sie nicht angeben, welche Vorlage gerendert werden soll; das Framework bestimmt den Pfad automatisch, was die Codierung für Sie einfacher macht. + +Wenn Sie eine Verzeichnisstruktur verwenden, in der jeder Präsentator sein eigenes Verzeichnis hat, legen Sie die Vorlage einfach in diesem Verzeichnis unter dem Namen der Aktion (d. h. der Ansicht) ab. Verwenden Sie zum Beispiel für die Aktion `default` die Vorlage `default.latte`: -Der Pfad zu den Vorlagen wird nach einer einfachen Logik hergeleitet. Es wird versucht zu sehen, ob eine dieser Vorlagendateien relativ zu dem Verzeichnis existiert, in dem sich die Presenter-Klasse befindet, wobei `` der Name des aktuellen Präsentators ist und `` der Name der aktuellen Aktion ist: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Wenn Sie eine Struktur verwenden, bei der sich die Präsentatoren in einem Verzeichnis und die Vorlagen in einem Ordner `templates` befinden, speichern Sie sie entweder in einer Datei `..latte` oder `/.latte`: -Wird die Vorlage nicht gefunden, wird versucht, im Verzeichnis `templates` eine Ebene höher zu suchen, d. h. auf der gleichen Ebene wie das Verzeichnis mit der Presenter-Klasse. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Wenn die Vorlage auch dort nicht gefunden wird, ist die Antwort ein [404-Fehler |presenters#Error 404 etc.]. +Das Verzeichnis `templates` kann auch eine Ebene höher platziert werden, auf derselben Ebene wie das Verzeichnis mit den Presenter-Klassen. -Sie können die Ansicht auch mit `$this->setView('otherView')` ändern. Oder geben Sie statt der Suche direkt den Namen der Vorlagendatei mit `$this->template->setFile('/path/to/template.latte')` an. +Wenn die Vorlage nicht gefunden wird, antwortet der Präsentator mit dem [Fehler 404 - Seite nicht gefunden |presenters#Error 404 etc]. + +Sie können die Ansicht mit `$this->setView('anotherView')` ändern. Es ist auch möglich, die Vorlagendatei direkt mit `$this->template->setFile('/path/to/template.latte')` anzugeben. .[note] -Sie können die Pfade, in denen Vorlagen gesucht werden, ändern, indem Sie die Methode [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()] überschreiben, die ein Array mit möglichen Dateipfaden zurückgibt. +Dateien, in denen Vorlagen gesucht werden, können durch Überschreiben der Methode [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()] geändert werden, die ein Array mit möglichen Dateinamen zurückgibt. + + +Layout-Vorlagen-Suche .[#toc-layout-template-lookup] +---------------------------------------------------- + +Nette sucht auch automatisch nach der Layout-Datei. + +Wenn Sie eine Verzeichnisstruktur verwenden, in der jeder Präsentator sein eigenes Verzeichnis hat, legen Sie das Layout entweder in dem Ordner mit dem Präsentator ab, wenn es nur für diesen spezifisch ist, oder eine Ebene höher, wenn es für mehrere Präsentatoren gemeinsam ist: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Wenn Sie eine Struktur verwenden, bei der die Vortragenden in einem Verzeichnis zusammengefasst sind und sich die Vorlagen in einem Ordner `templates` befinden, wird das Layout an den folgenden Stellen erwartet: -Das Layout wird in den folgenden Dateien erwartet: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` gemeinsames Layout für mehrere Präsentatoren +Befindet sich der Präsentator in einem [Modul |modules], wird er auch weiter oben im Verzeichnisbaum entsprechend der Verschachtelung des Moduls gesucht. -`` ist der Name des aktuellen Präsentators und `` ist der Name des Layouts, der standardmäßig `'layout'` lautet. Der Name kann mit `$this->setLayout('otherLayout')` geändert werden, so dass `@otherLayout.latte` Dateien ausprobiert werden. +Der Name des Layouts kann mit `$this->setLayout('layoutAdmin')` geändert werden und wird dann in der Datei `@layoutAdmin.latte` erwartet. Sie können die Layout-Vorlagendatei auch direkt mit `$this->setLayout('/path/to/template.latte')` angeben. -Sie können auch direkt den Dateinamen der Layoutvorlage mit `$this->setLayout('/path/to/template.latte')` angeben. Durch die Verwendung von `$this->setLayout(false)` wird die Layout-Suche deaktiviert. +Die Verwendung von `$this->setLayout(false)` oder des Tags `{layout none}` innerhalb der Vorlage deaktiviert die Layout-Suche. .[note] -Sie können die Pfade, in denen Vorlagen gesucht werden, ändern, indem Sie die Methode [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] überschreiben, die ein Array mit möglichen Dateipfaden zurückgibt. +Die Dateien, in denen Layoutvorlagen gesucht werden, können durch Überschreiben der Methode [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] geändert werden, die ein Array mit möglichen Dateinamen zurückgibt. Variablen in der Vorlage .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ Die `@property-read` Annotation ist für die IDE und die statische Analyse, sie Sie können sich auch den Luxus gönnen, in Vorlagen zu flüstern. Installieren Sie einfach das Latte-Plugin in PhpStorm und geben Sie den Klassennamen am Anfang der Vorlage an, siehe den Artikel "Latte: how to type system":https://blog.nette.org/de/latte-wie-benutzt-man-das-typensystem: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte Version 3 bietet einen fortgeschritteneren Weg, indem es eine [Erweiterung |latte:creating-extension] für jedes Webprojekt erstellt. Hier ist ein grobes Beispiel für eine solche Klasse: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Wir registrieren sie mit [configuration |configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/el/how-it-works.texy b/application/el/how-it-works.texy index f7a4be0a0b..8593798f00 100644 --- a/application/el/how-it-works.texy +++ b/application/el/how-it-works.texy @@ -22,13 +22,13 @@ /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← βασικές αναγκαίες τάξεις +│ │ └── RouterFactory.php ← διαμόρφωση των διευθύνσεων URL +│ ├── UI/ ← παρουσιαστές, πρότυπα και λοιπά. +│ │ ├── @layout.latte ← πρότυπο κοινής διάταξης +│ │ └── Home/ ← Αρχικός κατάλογος παρουσιαστών +│ │ ├── HomePresenter.php ← Κλάση οικιακού παρουσιαστή +│ │ └── default.latte ← πρότυπο για τη δράση default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ composer create-project nette/web-project Η εφαρμογή ξεκινά ζητώντας από τον λεγόμενο δρομολογητή να αποφασίσει ποιος από τους παρουσιαστές θα περάσει το τρέχον αίτημα για επεξεργασία. Ο δρομολογητής αποφασίζει ποιανού ευθύνη είναι. Κοιτάζει τη διεύθυνση URL εισόδου `https://example.com/product/123`, ο οποίος θέλει να `show` ένα προϊόν με `id: 123` ως ενέργεια. Είναι καλή συνήθεια να γράφετε τα ζεύγη παρουσιαστής + δράση χωρισμένα με άνω και κάτω τελεία ως `Product:show`. -Έτσι, ο δρομολογητής μετατρέπει τη διεύθυνση URL σε ένα ζεύγος `Presenter:action` + παράμετροι, στην περίπτωσή μας `Product:show` + `id: 123`. Μπορείτε να δείτε πώς μοιάζει ένας δρομολογητής στο αρχείο `app/Router/RouterFactory.php` και θα τον περιγράψουμε αναλυτικά στο κεφάλαιο [Δρομολόγηση |Routing]. +Έτσι, ο δρομολογητής μετατρέπει τη διεύθυνση URL σε ένα ζεύγος `Presenter:action` + παράμετροι, στην περίπτωσή μας `Product:show` + `id: 123`. Μπορείτε να δείτε πώς μοιάζει ένας δρομολογητής στο αρχείο `app/Core/RouterFactory.php` και θα τον περιγράψουμε αναλυτικά στο κεφάλαιο [Δρομολόγηση |Routing]. Ας συνεχίσουμε. Η εφαρμογή γνωρίζει ήδη το όνομα του παρουσιαστή και μπορεί να συνεχίσει. Δημιουργώντας ένα αντικείμενο `ProductPresenter`, το οποίο είναι ο κώδικας του παρουσιαστή `Product`. Πιο συγκεκριμένα, ζητάει από το DI container τη δημιουργία του presenter, επειδή η παραγωγή αντικειμένων είναι η δουλειά του. @@ -121,12 +121,9 @@ class ProductPresenter extends Nette\Application\UI\Presenter Στη συνέχεια, ο παρουσιαστής επιστρέφει την απάντηση. Αυτό μπορεί να είναι μια σελίδα HTML, μια εικόνα, ένα έγγραφο XML, η αποστολή ενός αρχείου από το δίσκο, JSON ή η ανακατεύθυνση σε μια άλλη σελίδα. Σημαντικό είναι ότι, αν δεν πούμε ρητά πώς να απαντήσουμε (κάτι που συμβαίνει στην περίπτωση του `ProductPresenter`), η απάντηση θα είναι η απόδοση του προτύπου με μια σελίδα HTML. Γιατί; Λοιπόν, επειδή στο 99% των περιπτώσεων θέλουμε να σχεδιάσουμε ένα πρότυπο, οπότε ο παρουσιαστής θεωρεί αυτή τη συμπεριφορά ως προεπιλεγμένη και θέλει να διευκολύνει τη δουλειά μας. Αυτό είναι το νόημα της Nette. -Δεν χρειάζεται καν να δηλώσουμε ποιο πρότυπο θέλουμε να σχεδιάσουμε, αυτός εξάγει τη διαδρομή προς αυτό σύμφωνα με απλή λογική. Στην περίπτωση του presenter `Product` και της δράσης `show`, προσπαθεί να δει αν ένα από αυτά τα αρχεία προτύπων υπάρχει σε σχέση με τον κατάλογο όπου βρίσκεται η κλάση `ProductPresenter`: +Δεν χρειάζεται καν να καθορίσουμε ποιο πρότυπο θα αναπαραχθεί- το πλαίσιο θα βρει μόνο του τη διαδρομή. Στην περίπτωση της ενέργειας `show`, απλώς προσπαθεί να φορτώσει το πρότυπο `show.latte` στον κατάλογο με την κλάση `ProductPresenter`. Προσπαθεί επίσης να βρει τη διάταξη στο αρχείο `@layout.latte` (περισσότερα για την [αναζήτηση προτύπων |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Θα προσπαθήσει επίσης να βρει τη διάταξη στο αρχείο `@layout.latte` και στη συνέχεια θα αποδώσει το πρότυπο. Τώρα ολοκληρώνεται η εργασία του παρουσιαστή και ολόκληρης της εφαρμογής. Εάν το πρότυπο δεν υπάρχει, θα επιστραφεί μια σελίδα με σφάλμα 404. Μπορείτε να διαβάσετε περισσότερα για τους παρουσιαστές στη σελίδα [Παρουσιαστές |Presenters]. +Στη συνέχεια, τα πρότυπα αποδίδονται. Με αυτόν τον τρόπο ολοκληρώνεται η εργασία του παρουσιαστή και ολόκληρης της εφαρμογής, και η εργασία έχει τελειώσει. Εάν το πρότυπο δεν υπήρχε, θα επιστρεφόταν μια σελίδα σφάλματος 404. Μπορείτε να διαβάσετε περισσότερα για τους παρουσιαστές στη σελίδα [Παρουσιαστές |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ class ProductPresenter extends Nette\Application\UI\Presenter 3) ο δρομολογητής αποκωδικοποιεί τη διεύθυνση URL ως ζεύγος `Home:default` 4) δημιουργείται ένα αντικείμενο `HomePresenter` 5) καλείται η μέθοδος `renderDefault()` (αν υπάρχει) -6) αποδίδεται ένα πρότυπο `templates/Home/default.latte` με διάταξη `templates/@layout.latte` +6) αποδίδεται ένα πρότυπο `default.latte` με διάταξη `@layout.latte` Μπορεί να έχετε συναντήσει πολλές νέες έννοιες τώρα, αλλά πιστεύουμε ότι βγάζουν νόημα. Η δημιουργία εφαρμογών στη Nette είναι πανεύκολη. diff --git a/application/el/modules.texy b/application/el/modules.texy index 3277cccce0..5e22451dba 100644 --- a/application/el/modules.texy +++ b/application/el/modules.texy @@ -2,29 +2,31 @@ ******** .[perex] -Στη Nette, οι ενότητες αντιπροσωπεύουν τις λογικές μονάδες που συνθέτουν μια εφαρμογή. Περιλαμβάνουν παρουσιαστές, πρότυπα, ενδεχομένως επίσης συστατικά και κλάσεις μοντέλων. +Οι ενότητες φέρνουν σαφήνεια στις εφαρμογές Nette διευκολύνοντας τον εύκολο διαχωρισμό σε λογικές μονάδες. -Ένας κατάλογος για τους παρουσιαστές και ένας για τα πρότυπα δεν θα ήταν αρκετός για πραγματικά έργα. Το να έχετε δεκάδες αρχεία σε έναν φάκελο είναι τουλάχιστον ανοργάνωτο. Πώς να απαλλαγείτε από αυτό; Απλώς τα χωρίζουμε σε υποκαταλόγους στο δίσκο και σε χώρους ονομάτων στον κώδικα. Και αυτό ακριβώς κάνουν τα modules της Nette. - -Ας ξεχάσουμε λοιπόν έναν ενιαίο φάκελο για τους παρουσιαστές και τα πρότυπα και ας δημιουργήσουμε αντ' αυτού ενότητες, για παράδειγμα `Admin` και `Front`. +Παρόμοια με την οργάνωση των αρχείων σε φακέλους σε ένα σκληρό δίσκο, στη Nette μπορούμε να χωρίσουμε τους παρουσιαστές, τα πρότυπα και άλλες βοηθητικές κλάσεις σε ενότητες. Πώς λειτουργεί αυτό στην πράξη; Απλά με την ενσωμάτωση νέων υποκαταλόγων στη δομή. Ακολουθεί ένα παράδειγμα δομής με δύο ενότητες, Front και Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Αυτή η δομή καταλόγου θα αντικατοπτρίζεται από τα namespaces των κλάσεων, έτσι για παράδειγμα το `DashboardPresenter` θα βρίσκεται στο namespace `App\Modules\Admin\Presenters`: +Αυτή η δομή καταλόγου αντικατοπτρίζεται στα namespaces των κλάσεων, έτσι για παράδειγμα, η `DashboardPresenter` βρίσκεται στο namespace `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Ο παρουσιαστής `Dashboard` μέσα στην ενότητα `Admin` αναφέρεται μέσα στην εφαρμογή χρησιμοποιώντας τον συμβολισμό της άνω και κάτω τελείας ως `Admin:Dashboard`, και η ενέργεια `default` ως `Admin:Dashboard:default`. -Και πώς γνωρίζει η Nette proper ότι το `Admin:Dashboard` αντιπροσωπεύει την κλάση `App\Modules\Admin\Presenters\DashboardPresenter`; Αυτό καθορίζεται από την [αντιστοίχιση |#mapping] στη διαμόρφωση. -Έτσι, η δεδομένη δομή δεν είναι αυστηρά καθορισμένη και μπορείτε να την τροποποιήσετε ανάλογα με τις ανάγκες σας. +Στην εφαρμογή, αναφερόμαστε στον παρουσιαστή `Dashboard` μέσα στην ενότητα `Admin` χρησιμοποιώντας τον συμβολισμό της άνω και κάτω τελείας ως `Admin:Dashboard`. Για τη δράση του `default`, αναφερόμαστε σε αυτόν ως `Admin:Dashboard:default`. -Οι ενότητες μπορούν φυσικά να περιέχουν όλα τα άλλα στοιχεία εκτός από τους παρουσιαστές και τα πρότυπα, όπως συστατικά, κλάσεις μοντέλων κ.λπ. +Η δομή που παρουσιάζεται δεν είναι άκαμπτη- μπορείτε να [την προσαρμόσετε πλήρως στις ανάγκες σας |#mapping] στη διαμόρφωση. .[tip] + +Οι ενότητες μπορούν να περιλαμβάνουν όλα τα άλλα αρχεία, όπως συστατικά και βοηθητικές κλάσεις, εκτός από τους παρουσιαστές και τα πρότυπα. Αν σκέφτεστε πού να τα τοποθετήσετε αυτά, σκεφτείτε να χρησιμοποιήσετε έναν φάκελο `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Ενσωματωμένες ενότητες .[#toc-nested-modules] --------------------------------------------- -Οι ενότητες δεν χρειάζεται να σχηματίζουν μόνο μια επίπεδη δομή, μπορείτε επίσης να δημιουργήσετε υποενότητες, για παράδειγμα: +Οι ενότητες μπορούν να έχουν πολλαπλά επίπεδα ένθεσης, παρόμοια με μια δομή καταλόγου σε ένα δίσκο: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Έτσι, η ενότητα `Blog` χωρίζεται σε υποενότητες `Admin` και `Front`. Και πάλι, αυτό θα αντικατοπτρίζεται στα namespaces, τα οποία θα είναι `App\Modules\Blog\Admin\Presenters` κ.λπ. Ο παρουσιαστής `Dashboard` μέσα στην υποενότητα αναφέρεται ως `Blog:Admin:Dashboard`. +Η ενότητα `Blog` χωρίζεται σε υποενότητες `Admin` και `Front`. Αυτό αντικατοπτρίζεται επίσης στα namespaces, τα οποία εμφανίζονται ως `App\UI\Blog\Admin` και παρόμοια. Για να αναφερθούμε στον παρουσιαστή `Dashboard` μέσα στην υποενότητα `Admin`, αναφερόμαστε σε αυτόν ως `Blog:Admin:Dashboard`. -Η ένθεση μπορεί να προχωρήσει όσο βαθιά θέλετε, οπότε μπορούν να δημιουργηθούν υπο-υποενότητες. +Η φωλεοποίηση μπορεί να είναι όσο βαθιά χρειάζεται, επιτρέποντας τη δημιουργία υπο-υπομονάδων. + +Για παράδειγμα, αν στη διαχείριση έχετε πολλούς παρουσιαστές που σχετίζονται με τη διαχείριση παραγγελιών, όπως `OrderDetail`, `OrderEdit`, `OrderDispatch`, κ.λπ., μπορείτε να δημιουργήσετε μια ενότητα `Order` στην οποία θα οργανωθούν παρουσιαστές όπως `Detail`, `Edit`, `Dispatch` και άλλοι. Δημιουργία συνδέσμων .[#toc-creating-links] @@ -102,46 +118,66 @@ class DashboardPresenter extends Nette\Application\UI\Presenter Χαρτογράφηση .[#toc-mapping] ---------------------------- -Καθορίζει τους κανόνες με τους οποίους το όνομα της κλάσης προκύπτει από το όνομα του παρουσιαστή. Τους γράφουμε στη [διαμόρφωση |configuration] κάτω από το κλειδί `application › mapping`. +Η αντιστοίχιση ορίζει τους κανόνες για την εξαγωγή του ονόματος της κλάσης από το όνομα του παρουσιαστή. Οι κανόνες αυτοί καθορίζονται στη [διαμόρφωση |configuration] στο κλειδί `application › mapping`. + +Οι δομές καταλόγων που αναφέρθηκαν νωρίτερα σε αυτή τη σελίδα βασίζονται στην ακόλουθη αντιστοίχιση: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Ας ξεκινήσουμε με ένα δείγμα που δεν χρησιμοποιεί ενότητες. Θα θέλουμε απλώς οι κλάσεις presenter να έχουν το namespace `App\Presenters`. Αυτό σημαίνει ότι ένας παρουσιαστής όπως το `Home` θα πρέπει να αντιστοιχίζεται στην κλάση `App\Presenters\HomePresenter`. Αυτό μπορεί να επιτευχθεί με την ακόλουθη διαμόρφωση: +Πώς λειτουργεί η χαρτογράφηση; Για καλύτερη κατανόηση, ας φανταστούμε πρώτα μια εφαρμογή χωρίς ενότητες. Θέλουμε οι κλάσεις του παρουσιαστή να υπάγονται στο χώρο ονομάτων `App\UI`, έτσι ώστε ο παρουσιαστής `Home` να αντιστοιχίζεται στην κλάση `App\UI\HomePresenter`. Αυτό μπορεί να επιτευχθεί με αυτή τη διαμόρφωση: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Το όνομα του παρουσιαστή αντικαθίσταται με τον αστερίσκο στη μάσκα κλάσης και το αποτέλεσμα είναι το όνομα της κλάσης. Εύκολο! +Αυτή η αντιστοίχιση λειτουργεί αντικαθιστώντας τον αστερίσκο στη μάσκα `App\UI\*Presenter` με το όνομα του παρουσιαστή `Home`, με αποτέλεσμα το τελικό όνομα της κλάσης `App\UI\HomePresenter`. Απλό! + +Ωστόσο, όπως μπορείτε να δείτε στα παραδείγματα σε αυτό και σε άλλα κεφάλαια, τοποθετούμε τις κλάσεις παρουσιαστή σε επώνυμους υποκαταλόγους, π.χ. ο παρουσιαστής `Home` αντιστοιχίζεται στην κλάση `App\UI\Home\HomePresenter`. Αυτό επιτυγχάνεται με τον διπλασιασμό του αστερίσκου (απαιτεί Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Αν χωρίσουμε τους παρουσιαστές σε ενότητες, μπορούμε να έχουμε τη δική μας χαρτογράφηση για κάθε ενότητα: +Τώρα, ας προχωρήσουμε στην αντιστοίχιση των παρουσιαστών σε ενότητες. Μπορούμε να ορίσουμε συγκεκριμένες αντιστοιχίσεις για κάθε ενότητα: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Τώρα ο παρουσιαστής `Front:Home` αντιστοιχίζεται στην κλάση `App\Modules\Front\Presenters\HomePresenter` και ο παρουσιαστής `Admin:Dashboard` στην κλάση `App\Modules\Admin\Presenters\DashboardPresenter`. +Σύμφωνα με αυτή τη διαμόρφωση, ο παρουσιαστής `Front:Home` αντιστοιχίζεται στην κλάση `App\UI\Front\Home\HomePresenter`, ενώ ο παρουσιαστής `Api:OAuth` αντιστοιχίζεται στην κλάση `App\Api\OAuthPresenter`. -Είναι πιο πρακτικό να δημιουργήσετε έναν γενικό κανόνα (αστέρι) για να αντικαταστήσετε τους δύο πρώτους. Ο επιπλέον αστερίσκος θα προστεθεί στη μάσκα κλάσης μόνο για την ενότητα: +Δεδομένου ότι οι ενότητες `Front` και `Admin` έχουν παρόμοια προσέγγιση αντιστοίχισης και είναι πιθανό να υπάρχουν περισσότερες τέτοιες ενότητες, είναι δυνατόν να δημιουργηθεί ένας γενικός κανόνας που να τις αντικαθιστά. Ένας νέος αστερίσκος για την ενότητα προστίθεται στη μάσκα κλάσης: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Τι γίνεται όμως αν χρησιμοποιούμε φωλιασμένες ενότητες και έχουμε έναν παρουσιαστή `Admin:User:Edit`; Σε αυτή την περίπτωση, το τμήμα με τον αστερίσκο που αντιπροσωπεύει την ενότητα για κάθε επίπεδο απλώς επαναλαμβάνεται και το αποτέλεσμα είναι η κλάση `App\Modules\Admin\User\Presenters\EditPresenter`. +Για πολυεπίπεδες φωλιασμένες ενότητες, όπως ο παρουσιαστής `Admin:User:Edit`, το τμήμα αστερίσκου επαναλαμβάνεται για κάθε επίπεδο, με αποτέλεσμα την κλάση `App\UI\Admin\User\Edit\EditPresenter`. -Ένας εναλλακτικός συμβολισμός είναι η χρήση ενός πίνακα που αποτελείται από τρία τμήματα αντί για συμβολοσειρά. Αυτή η σημειογραφία είναι ισοδύναμη με την προηγούμενη: +Ένας εναλλακτικός συμβολισμός είναι η χρήση ενός πίνακα που αποτελείται από τρία τμήματα αντί για μια συμβολοσειρά. Αυτός ο συμβολισμός είναι ισοδύναμος με τον προηγούμενο: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Η προεπιλεγμένη τιμή είναι `*Module\*Presenter`. +Αν έχουμε μόνο έναν κανόνα στη διαμόρφωση, τον γενικό, μπορούμε να γράψουμε συνοπτικά: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/el/templates.texy b/application/el/templates.texy index 4b83599f45..39c2ddca2e 100644 --- a/application/el/templates.texy +++ b/application/el/templates.texy @@ -34,35 +34,81 @@ Ορίζει το μπλοκ `content`, το οποίο εισάγεται στη θέση του `{include content}` στη διάταξη, και επίσης επαναπροσδιορίζει το μπλοκ `title`, το οποίο αντικαθιστά το `{block title}` στη διάταξη. Προσπαθήστε να φανταστείτε το αποτέλεσμα. -Αναζήτηση προτύπων .[#toc-search-for-templates] ------------------------------------------------ +Αναζήτηση προτύπου .[#toc-template-lookup] +------------------------------------------ -Η διαδρομή προς τα πρότυπα προκύπτει σύμφωνα με μια απλή λογική. Προσπαθεί να δει αν ένα από αυτά τα αρχεία προτύπων υπάρχει σε σχέση με τον κατάλογο όπου βρίσκεται η κλάση presenter, όπου `` είναι το όνομα του τρέχοντος παρουσιαστή και `` είναι το όνομα της τρέχουσας δράσης: +Στους παρουσιαστές, δεν χρειάζεται να καθορίσετε ποιο πρότυπο πρέπει να αποδοθεί- το πλαίσιο θα καθορίσει αυτόματα τη διαδρομή, διευκολύνοντας την κωδικοποίηση για εσάς. -- `templates//.latte` -- `templates/..latte` +Αν χρησιμοποιείτε μια δομή καταλόγου όπου κάθε παρουσιαστής έχει το δικό του κατάλογο, απλά τοποθετήστε το πρότυπο σε αυτόν τον κατάλογο κάτω από το όνομα της ενέργειας (π.χ. προβολή). Για παράδειγμα, για τη δράση `default`, χρησιμοποιήστε το πρότυπο `default.latte`: -Αν το πρότυπο δεν βρεθεί, θα προσπαθήσει να ψάξει στον κατάλογο `templates` ένα επίπεδο πιο πάνω, δηλαδή στο ίδιο επίπεδο με τον κατάλογο με την κλάση παρουσιαστή. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Εάν το πρότυπο δεν βρεθεί ούτε εκεί, η απάντηση είναι ένα [σφάλμα 404 |presenters#Error 404 etc.]. +Εάν χρησιμοποιείτε μια δομή όπου οι παρουσιαστές βρίσκονται μαζί σε έναν κατάλογο και τα πρότυπα σε έναν φάκελο `templates`, αποθηκεύστε το είτε σε ένα αρχείο `..latte` είτε στο `/.latte`: -Μπορείτε επίσης να αλλάξετε την προβολή χρησιμοποιώντας το `$this->setView('otherView')`. Ή, αντί για αναζήτηση, καθορίστε απευθείας το όνομα του αρχείου προτύπου χρησιμοποιώντας τη διεύθυνση `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +Ο κατάλογος `templates` μπορεί επίσης να τοποθετηθεί ένα επίπεδο ψηλότερα, στο ίδιο επίπεδο με τον κατάλογο με τις κλάσεις παρουσιαστών. + +Εάν το πρότυπο δεν βρεθεί, ο παρουσιαστής απαντά με το [σφάλμα 404 - σελίδα δεν βρέθηκε |presenters#Error 404 etc]. + +Μπορείτε να αλλάξετε την προβολή χρησιμοποιώντας το `$this->setView('anotherView')`. Είναι επίσης δυνατό να καθορίσετε απευθείας το αρχείο προτύπου με το `$this->template->setFile('/path/to/template.latte')`. .[note] -Μπορείτε να αλλάξετε τις διαδρομές στις οποίες αναζητούνται τα πρότυπα υπερκαλύπτοντας τη μέθοδο [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], η οποία επιστρέφει έναν πίνακα πιθανών διαδρομών αρχείων. +Τα αρχεία στα οποία αναζητούνται τα πρότυπα μπορούν να αλλάξουν με την παράκαμψη της μεθόδου [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], η οποία επιστρέφει έναν πίνακα πιθανών ονομάτων αρχείων. + + +Αναζήτηση προτύπων διάταξης .[#toc-layout-template-lookup] +---------------------------------------------------------- + +Η Nette αναζητά επίσης αυτόματα το αρχείο διάταξης. + +Εάν χρησιμοποιείτε μια δομή καταλόγου όπου κάθε παρουσιαστής έχει το δικό του κατάλογο, τοποθετήστε τη διάταξη είτε στο φάκελο με τον παρουσιαστή, εάν αφορά μόνο αυτόν, είτε ένα επίπεδο ψηλότερα εάν είναι κοινή για πολλούς παρουσιαστές: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Εάν χρησιμοποιείτε μια δομή όπου οι παρουσιαστές είναι ομαδοποιημένοι σε έναν κατάλογο και τα πρότυπα βρίσκονται σε έναν φάκελο `templates`, η διάταξη αναμένεται στις ακόλουθες θέσεις: -Η διάταξη αναμένεται στα ακόλουθα αρχεία: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` διάταξη κοινή για πολλούς παρουσιαστές +Εάν ο παρουσιαστής βρίσκεται σε μια [ενότητα |modules], θα αναζητήσει επίσης πιο πάνω στο δέντρο καταλόγων σύμφωνα με την ένθεση της ενότητας. -`` είναι το όνομα του τρέχοντος παρουσιαστή και `` είναι το όνομα της διάταξης, η οποία είναι εξ ορισμού `'layout'`. Το όνομα μπορεί να αλλάξει με το `$this->setLayout('otherLayout')`, έτσι ώστε να δοκιμάζονται τα αρχεία `@otherLayout.latte`. +Το όνομα της διάταξης μπορεί να αλλάξει χρησιμοποιώντας το `$this->setLayout('layoutAdmin')` και τότε θα αναμένεται στο αρχείο `@layoutAdmin.latte`. Μπορείτε επίσης να καθορίσετε απευθείας το αρχείο προτύπου διάταξης χρησιμοποιώντας το `$this->setLayout('/path/to/template.latte')`. -Μπορείτε επίσης να καθορίσετε απευθείας το όνομα του αρχείου του προτύπου διάταξης χρησιμοποιώντας το `$this->setLayout('/path/to/template.latte')`. Η χρήση του `$this->setLayout(false)` θα απενεργοποιήσει την αναζήτηση διάταξης. +Η χρήση του `$this->setLayout(false)` ή της ετικέτας `{layout none}` μέσα στο πρότυπο απενεργοποιεί την αναζήτηση διάταξης. .[note] -Μπορείτε να αλλάξετε τις διαδρομές στις οποίες αναζητούνται τα πρότυπα με την παράκαμψη της μεθόδου [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], η οποία επιστρέφει έναν πίνακα πιθανών διαδρομών αρχείων. +Τα αρχεία στα οποία αναζητούνται τα πρότυπα διάταξης μπορούν να αλλάξουν με την παράκαμψη της μεθόδου [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], η οποία επιστρέφει έναν πίνακα πιθανών ονομάτων αρχείων. Μεταβλητές στο πρότυπο .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template Μπορείτε επίσης να αφεθείτε στην πολυτέλεια του ψιθυρίσματος στα πρότυπα, απλά εγκαταστήστε το πρόσθετο Latte στο PhpStorm και καθορίστε το όνομα της κλάσης στην αρχή του προτύπου, δείτε το άρθρο "Latte: πώς να πληκτρολογήσετε το σύστημα":https://blog.nette.org/el/latte-pos-na-chresimopoiesete-to-systema-typon: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte έκδοση 3 προσφέρει έναν πιο προηγμένο τρόπο δημιουργώντας μια [επέκταση |latte:creating-extension] για κάθε έργο ιστού. Εδώ είναι ένα πρόχειρο παράδειγμα μιας τέτοιας κλάσης: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ final class LatteExtension extends Latte\Extension ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/en/how-it-works.texy b/application/en/how-it-works.texy index 612d192393..cb0f291e1b 100644 --- a/application/en/how-it-works.texy +++ b/application/en/how-it-works.texy @@ -22,13 +22,13 @@ The directory structure looks something like this: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← basic necessary classes +│ │ └── RouterFactory.php ← configuration of URL addresses +│ ├── UI/ ← presenters, templates & co. +│ │ ├── @layout.latte ← template of shared layout +│ │ └── Home/ ← Home presenter directory +│ │ ├── HomePresenter.php ← Home presenter class +│ │ └── default.latte ← template for action default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ Applications written in Nette are divided into many so-called presenters (in oth The application starts by asking the so-called router to decide which of the presenters to pass the current request for processing. The router decides whose responsibility it is. It looks at the input URL `https://example.com/product/123` and, based on how it is set up, decides that this is a job, for example, for **presenter** `Product`, who wants to `show` a product with `id: 123` as an action. It is a good habit to write a pairs of presenter + action separated by a colon as `Product:show`. -So the router transformed the URL into a pair `Presenter:action` + parameters, in our case `Product:show` + `id: 123`. You can see how a router looks like in file `app/Router/RouterFactory.php` and we will describe it in detail in chapter [Routing]. +So the router transformed the URL into a pair `Presenter:action` + parameters, in our case `Product:show` + `id: 123`. You can see how a router looks like in file `app/Core/RouterFactory.php` and we will describe it in detail in chapter [Routing]. Let's move on. The application already knows the name of the presenter and can continue. By creating an object `ProductPresenter`, which is the code of presenter `Product`. More precisely, it asks the DI container for creating the presenter, because producting objects is its job. @@ -121,12 +121,9 @@ So, the method `renderShow(123)` was called, whose code is fictional example, bu Subsequently, the presenter returns the answer. This can be an HTML page, an image, an XML document, sending a file from disk, JSON or redirecting to another page. Importantly, if we do not explicitly say how to respond (which is the case of `ProductPresenter`), the answer will be to render the template with an HTML page. Why? Well, because in 99% of cases we want to draw a template, so the presenter takes this behavior as the default and wants to make our work easier. That's Nette's point. -We don't even have to state which template to draw, he derives the path to it according to simple logic. In the case of presenter `Product` and action `show`, it tries to see if one of these template files exists relative to the directory where class `ProductPresenter` is located: +We don't even need to specify which template to render; the framework will deduce the path itself. In the case of the `show` action, it simply tries to load the `show.latte` template in the directory with the `ProductPresenter` class. It also attempts to find the layout in the `@layout.latte` file (more about [template searching |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -It will also try to find the layout in file `@layout.latte` and then it renders the template. Now the task of the presenter and the entire application is completed. If the template does not exist, a page with error 404 will be returned. You can read more about presenters on the [Presenters] page. +Subsequently, the templates are rendered. This completes the task of the presenter and the entire application, and the work is done. If the template did not exist, a 404 error page would be returned. You can read more about presenters on the page [Presenters|presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Just to be sure, let's try to recap the whole process with a slightly different 3) the router decodes the URL as a pair `Home:default` 4) an `HomePresenter` object is created 5) method `renderDefault()` is called (if exists) -6) a template `templates/Home/default.latte` with a layout `templates/@layout.latte` is rendered +6) a template `default.latte` with a layout `@layout.latte` is rendered You may have come across a lot of new concepts now, but we believe they make sense. Creating applications in Nette is a breeze. diff --git a/application/en/modules.texy b/application/en/modules.texy index 376ac872b9..528cc1600c 100644 --- a/application/en/modules.texy +++ b/application/en/modules.texy @@ -2,29 +2,31 @@ Modules ******* .[perex] -In Nette, modules represent the logical units that make up an application. They include presenters, templates, possibly also components and model classes. +Modules bring clarity to Nette applications by facilitating easy division into logical units. -One directory for presenters and one for templates would not be enough for real projects. Having dozens of files in one folder is at least unorganized. How to get out of it? We simply split them into subdirectories on disk and into namespaces in the code. And that's exactly what the Nette modules do. - -So let's forget about a single folder for presenters and templates and instead create modules, for example `Admin` and `Front`. +Similar to organizing files into folders on a hard drive, in Nette we can divide presenters, templates, and other auxiliary classes into modules. How does this work in practice? Simply by incorporating new subdirectories into the structure. Here’s an example of a structure with two modules, Front and Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -This directory structure will be reflected by the class namespaces, so for example `DashboardPresenter` will be in the `App\Modules\Admin\Presenters` namespace: +This directory structure is reflected in the namespaces of the classes, so for example, `DashboardPresenter` is located in the namespace `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -The `Dashboard` presenter inside the `Admin` module is referenced within the application using the colon notation as `Admin:Dashboard`, and its `default` action as `Admin:Dashboard:default`. -And how does Nette proper know that `Admin:Dashboard` represents the `App\Modules\Admin\Presenters\DashboardPresenter` class? This is determined by [#mapping] in the configuration. -Thus, the given structure is not hard set and you can modify it according to your needs. +In the application, we refer to the `Dashboard` presenter within the `Admin` module using colon notation as `Admin:Dashboard`. For its `default` action, we refer to it as `Admin:Dashboard:default`. -Modules can of course contain all other items besides presenters and templates, such as components, model classes, etc. +The structure presented is not rigid; you can [fully customize it to your needs|#mapping] in the configuration. .[tip] + +Modules can include all other files, such as components and auxiliary classes, in addition to presenters and templates. If you are considering where to place these, consider using an `Accessory` folder: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Nested Modules -------------- -Modules don't have to form only a flat structure, you can also create submodules, for example: +Modules can have multiple levels of nesting, similar to a directory structure on a disk: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Thus, the `Blog` module is divided into `Admin` and `Front` submodules. Again, this will be reflected in the namespaces, which will be `App\Modules\Blog\Admin\Presenters` etc. The presenter `Dashboard` inside the submodule is referred to as `Blog:Admin:Dashboard`. +The `Blog` module is divided into `Admin` and `Front` submodules. This is also reflected in the namespaces, which then appear as `App\UI\Blog\Admin` and similarly. To refer to the `Dashboard` presenter within the `Admin` submodule, we refer to it as `Blog:Admin:Dashboard`. -The nesting can go as deep as you like, so sub-submodules can be created. +Nesting can be as deep as needed, allowing the creation of sub-submodules. + +For example, if in administration you have many presenters related to order management, such as `OrderDetail`, `OrderEdit`, `OrderDispatch`, etc., you might create an `Order` module in which presenters like `Detail`, `Edit`, `Dispatch`, and others will be organized. Creating Links @@ -102,46 +118,66 @@ See [chapter on routing |routing#Modules]. Mapping ------- -Defines the rules by which the class name is derived from the presenter name. We write them in [configuration] under the `application › mapping` key. +Mapping defines the rules for deriving the class name from the presenter name. These rules are specified in the [configuration|configuration] under the key `application › mapping`. + +The directory structures mentioned earlier on this page are based on the following mapping: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Let's start with a sample that doesn't use modules. We'll just want the presenter classes to have the `App\Presenters` namespace. That means that a presenter such as `Home` should map to the `App\Presenters\HomePresenter` class. This can be achieved by the following configuration: +How does the mapping work? For a better understanding, let's first imagine an application without modules. We want the presenter classes to fall under the namespace `App\UI`, so that the `Home` presenter maps to the class `App\UI\HomePresenter`. This can be achieved with this configuration: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -The presenter name is replaced with the asterisk in the class mask and the result is the class name. Easy! +This mapping works by replacing the asterisk in the mask `App\UI\*Presenter` with the presenter name `Home`, resulting in the final class name `App\UI\HomePresenter`. Simple! + +However, as you can see in the examples in this and other chapters, we place presenter classes in eponymous subdirectories, e.g., the `Home` presenter is mapped to the class `App\UI\Home\HomePresenter`. This is achieved by doubling the asterisk (requires Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -If we divide presenters into modules, we can have our own mapping for each module: +Now, let's move on to mapping presenters into modules. We can define specific mappings for each module: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Now presenter `Front:Home` maps to class `App\Modules\Front\Presenters\HomePresenter` and presenter `Admin:Dashboard` to class `App\Modules\Admin\Presenters\DashboardPresenter`. +According to this configuration, the presenter `Front:Home` maps to the class `App\UI\Front\Home\HomePresenter`, while the presenter `Api:OAuth` maps to the class `App\Api\OAuthPresenter`. -It is more practical to create a general (star) rule to replace the first two. The extra asterisk will be added to the class mask just for the module: +Since the `Front` and `Admin` modules have a similar mapping approach and there are likely to be more such modules, it is possible to create a general rule that replaces them. A new asterisk for the module is added to the class mask: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -But what if we use nested modules and have a presenter `Admin:User:Edit`? In this case, the segment with an asterisk representing the module for each level is simply repeated and the result is class `App\Modules\Admin\User\Presenters\EditPresenter`. +For multi-level nested modules, such as the presenter `Admin:User:Edit`, the asterisk segment repeats for each level, resulting in the class `App\UI\Admin\User\Edit\EditPresenter`. -An alternative notation is to use an array consisting of three segments instead of a string. This notation is equivalent to the previous one: +An alternative notation is to use an array composed of three segments instead of a string. This notation is equivalent to the previous one: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -The default value is `*Module\*Presenter`. +If we have only one rule in the configuration, the general one, we can write briefly: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/en/templates.texy b/application/en/templates.texy index 5107b4493a..8069d6b23d 100644 --- a/application/en/templates.texy +++ b/application/en/templates.texy @@ -34,35 +34,81 @@ And this might be the action template: It defines block `content`, which is inserted in place of `{include content}` in the layout, and also re-defines block `title`, which overwrites `{block title}` in the layout. Try to imagine the result. -Search for Templates --------------------- +Template Lookup +--------------- -The path to the templates is deduced according to simple logic. It tries to see if one of these template files exists relative to the directory where presenter class is located, where `` is the name of the current presenter and `` is the name of the current action: +In presenters, you don't need to specify which template should be rendered; the framework will automatically determine the path, making coding easier for you. -- `templates//.latte` -- `templates/..latte` +If you use a directory structure where each presenter has its own directory, simply place the template in this directory under the name of the action (i.e. view). For example, for the `default` action, use the `default.latte` template: -If the template is not found, it will try to search in the `templates` directory one level up, i.e., at the same level as the directory with the presenter class. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -If the template is not found there either, the response is a [404 error|presenters#Error 404 etc.]. +If you use a structure where presenters are together in one directory and templates in a `templates` folder, save it either in a file `..latte` or `/.latte`: -You can also change the view using `$this->setView('otherView')`. Or, instead of searching, directly specify the name of the template file using `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +The `templates` directory can also be placed one level higher, at the same level as the directory with presenter classes. + +If the template is not found, the presenter responds with [404 - page not found error|presenters#Error 404 etc]. + +You can change the view using `$this->setView('anotherView')`. It is also possible to directly specify the template file with `$this->template->setFile('/path/to/template.latte')`. .[note] -You can change the paths where templates are searched by overriding the [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()] method, which returns an array of possible file paths. +Files where templates are searched can be changed by overriding the method [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], which returns an array of possible file names. + + +Layout Template Lookup +---------------------- + +Nette also automatically searches for the layout file. + +If you use a directory structure where each presenter has its own directory, place the layout either in the folder with the presenter, if it is specific only to them, or a level higher if it is common to multiple presenters: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +If you use a structure where presenters are grouped together in one directory and templates are in a `templates` folder, the layout will be expected in the following places: -The layout is expected in the following files: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` layout common to multiple presenters +If the presenter is in a [module|modules], it will also search further up the directory tree according to the module's nesting. -`` is the name of the current presenter and `` is the name of the layout, which is by default `'layout'`. The name can be changed with `$this->setLayout('otherLayout')`, so that `@otherLayout.latte` files will be tried. +The name of the layout can be changed using `$this->setLayout('layoutAdmin')` and then it will be expected in the file `@layoutAdmin.latte`. You can also directly specify the layout template file using `$this->setLayout('/path/to/template.latte')`. -You can also directly specify the file name of the layout template using `$this->setLayout('/path/to/template.latte')`. Using `$this->setLayout(false)` will disable the layout searching. +Using `$this->setLayout(false)` or the `{layout none}` tag inside the template disables layout search. .[note] -You can change the paths where templates are searched by overriding the [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] method, which returns an array of possible file paths. +Files where layout templates are searched can be changed by overriding the method [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], which returns an array of possible file names. Variables in the Template @@ -104,7 +150,7 @@ The `@property-read` annotation is for IDE and static analysis, it will make aut You can indulge in the luxury of whispering in templates too, just install the Latte plugin in PhpStorm and specify the class name at the beginning of the template, see the article "Latte: how to type system":https://blog.nette.org/en/latte-how-to-use-type-system: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte version 3 offers a more advanced way by creating an [extension |latte:creating-extension] for each web project. Here is a rough example of such a class: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ We register it using [configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/es/how-it-works.texy b/application/es/how-it-works.texy index 1706cb62a5..e4e0447853 100644 --- a/application/es/how-it-works.texy +++ b/application/es/how-it-works.texy @@ -22,13 +22,13 @@ La estructura de directorios se parece a esto /--pre web-project/ ├── app/ ← directorio con la aplicación -│ ├── Presenters/ ← clases para presentadores -│ │ ├── HomePresenter.php ← Home de inicio de la clase de presentador -│ │ └── templates/ ← directorio de plantillas -│ │ ├── @layout.latte ← plantilla de diseño compartida -│ │ └── Home/ ← plantillas para Home presentador de inicio -│ │ └── default.latte ← plantilla para la acción `default` -│ ├── Router/ ← configuración de direcciones URL +│ ├── Core/ ← clases básicas necesarias. +│ │ └── RouterFactory.php ← configuración de direcciones URL. +│ ├── UI/ ← presentadores, plantillas & co. +│ │ ├── @layout.latte ← plantilla de maquetación compartida +│ │ └── Home/ ← Home directorio del presentador +│ │ ├── HomePresenter.php ← Clase del presentador de inicio +│ │ └── default.latte ← plantilla para la acción default │ └── Bootstrap.php ← clase de arranque Bootstrap ├── bin/ ← scripts para la línea de comandos ├── config/ ← archivos de configuración @@ -91,7 +91,7 @@ Las aplicaciones escritas en Nette se dividen en muchos de los llamados presenta La aplicación comienza pidiendo al llamado enrutador que decida a cuál de los presentadores debe pasar la petición actual para su procesamiento. El enrutador decide de quién es la responsabilidad. Mira la URL de entrada `https://example.com/product/123`, que quiere `show` un producto con `id: 123` como acción. Es una buena costumbre escribir pares de presentador + acción separados por dos puntos como `Product:show`. -Así que el enrutador transforma la URL en un par `Presenter:action` + parámetros, en nuestro caso `Product:show` + `id: 123`. Puedes ver el aspecto de un enrutador en el archivo `app/Router/RouterFactory.php` y lo describiremos en detalle en el capítulo [Enrutamiento |Routing]. +Así que el enrutador transforma la URL en un par `Presenter:action` + parámetros, en nuestro caso `Product:show` + `id: 123`. Puedes ver el aspecto de un enrutador en el archivo `app/Core/RouterFactory.php` y lo describiremos en detalle en el capítulo [Enrutamiento |Routing]. Sigamos. La aplicación ya conoce el nombre del presentador y puede continuar. Creando un objeto `ProductPresenter`, que es el código del presentador `Product`. Más concretamente, le pide al contenedor DI que cree el presentador, porque producir objetos es su trabajo. @@ -121,12 +121,9 @@ Así, se llamó al método `renderShow(123)`, cuyo código es ficticio ejemplo, Posteriormente, el presentador devuelve la respuesta. Esta puede ser una página HTML, una imagen, un documento XML, el envío de un fichero desde disco, JSON o la redirección a otra página. Es importante destacar que, si no decimos explícitamente cómo responder (que es el caso de `ProductPresenter`), la respuesta será renderizar la plantilla con una página HTML. ¿Por qué? Pues porque en el 99% de los casos queremos dibujar una plantilla, así que el presentador toma este comportamiento por defecto y quiere facilitarnos el trabajo. Ese es el punto de Nette. -Ni siquiera tenemos que indicar qué plantilla dibujar, él deriva la ruta hacia ella según una lógica simple. En el caso del presentador `Product` y la acción `show`, intenta ver si uno de estos archivos de plantilla existe en relación al directorio donde se encuentra la clase `ProductPresenter`: +Ni siquiera necesitamos especificar qué plantilla renderizar; el framework deducirá la ruta por sí mismo. En el caso de la acción `show`, simplemente intenta cargar la plantilla `show.latte` en el directorio con la clase `ProductPresenter`. También intenta encontrar el diseño en el archivo `@layout.latte` (más información sobre la [búsqueda de plantillas |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -También intentará encontrar el diseño en el archivo `@layout.latte` y luego renderizará la plantilla. Ahora se completa la tarea del presentador y de toda la aplicación. Si la plantilla no existe, se devolverá una página con el error 404. Puedes leer más sobre los presentadores en la página de [Presentadores |Presenters]. +Posteriormente, se renderizan las plantillas. Esto completa la tarea del presentador y de toda la aplicación, y el trabajo está hecho. Si la plantilla no existiera, se devolvería una página de error 404. Puede leer más sobre los presentadores en la página [Presentadores |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Sólo para estar seguros, intentemos recapitular todo el proceso con una URL lig 3) el router decodifica la URL como un par `Home:default` 4) se crea un objeto `HomePresenter` 5) se llama al método `renderDefault()` (si existe) -6) se renderiza una plantilla `templates/Home/default.latte` con un diseño `templates/@layout.latte` +6) se renderiza una plantilla `default.latte` con un diseño `@layout.latte` Puede que ahora te hayas encontrado con un montón de conceptos nuevos, pero creemos que tienen sentido. Crear aplicaciones en Nette es pan comido. diff --git a/application/es/modules.texy b/application/es/modules.texy index 644cab5c1f..2827183beb 100644 --- a/application/es/modules.texy +++ b/application/es/modules.texy @@ -2,29 +2,31 @@ Módulos ******* .[perex] -En Nette, los módulos representan las unidades lógicas que componen una aplicación. Incluyen presentadores, plantillas, posiblemente también componentes y clases modelo. +Los módulos aportan claridad a las aplicaciones Nette al facilitar su división en unidades lógicas. -Un directorio para los presentadores y otro para las plantillas no serían suficientes para los proyectos reales. Tener docenas de archivos en una carpeta es, como mínimo, desorganizado. ¿Cómo salir de ello? Simplemente los dividimos en subdirectorios en el disco y en espacios de nombres en el código. Y eso es exactamente lo que hacen los módulos de Nette. - -Así que olvidémonos de una única carpeta para presentadores y plantillas y en su lugar creemos módulos, por ejemplo `Admin` y `Front`. +De forma similar a la organización de archivos en carpetas en un disco duro, en Nette podemos dividir los presentadores, plantillas y otras clases auxiliares en módulos. ¿Cómo funciona esto en la práctica? Simplemente incorporando nuevos subdirectorios a la estructura. He aquí un ejemplo de estructura con dos módulos, Front y Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directorio con módulos -│ ├── Admin/ ← módulo Admin -│ │ ├── Presenters/ ← sus presentadores -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← módulo Front -│ └── Presenters/ ← sus presentadores -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Esta estructura de directorios se reflejará en los espacios de nombres de las clases, así por ejemplo `DashboardPresenter` estará en el espacio de nombres `App\Modules\Admin\Presenters`: +Esta estructura de directorios se refleja en los espacios de nombres de las clases, así por ejemplo, `DashboardPresenter` se encuentra en el espacio de nombres `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -El presentador `Dashboard` dentro del módulo `Admin` es referenciado dentro de la aplicación usando la notación de dos puntos como `Admin:Dashboard`, y su acción `default` como `Admin:Dashboard:default`. -¿Y cómo sabe Nette que `Admin:Dashboard` representa la clase `App\Modules\Admin\Presenters\DashboardPresenter`? Esto se determina mediante el [mapeo |#mapping] en la configuración. -Por lo tanto, la estructura dada no es rígida y puede modificarla según sus necesidades. +En la aplicación, nos referimos al presentador `Dashboard` dentro del módulo `Admin` utilizando la notación de dos puntos como `Admin:Dashboard`. Para su acción `default`, nos referimos a él como `Admin:Dashboard:default`. -Por supuesto, los módulos pueden contener todos los demás elementos además de presentadores y plantillas, como componentes, clases modelo, etc. +La estructura presentada no es rígida; puede [adaptarla totalmente a sus necesidades |#mapping] en la configuración. .[tip] + +Los módulos pueden incluir todos los demás archivos, como componentes y clases auxiliares, además de presentadores y plantillas. Si está pensando dónde colocarlos, considere la posibilidad de utilizar una carpeta `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Módulos anidados .[#toc-nested-modules] --------------------------------------- -Los módulos no tienen por qué formar sólo una estructura plana, también puedes crear submódulos, por ejemplo: +Los módulos pueden tener múltiples niveles de anidamiento, similar a una estructura de directorios en un disco: /--pre -app/ -├── Modules/ ← directorio con módulos -│ ├── Blog/ ← módulo Blog -│ │ ├── Admin/ ← submódulo Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submódulo Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← módulo Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Así, el módulo `Blog` se divide en los submódulos `Admin` y `Front`. De nuevo, esto se reflejará en los espacios de nombres, que serán `App\Modules\Blog\Admin\Presenters`, etc. El presentador `Dashboard` dentro del submódulo se denomina `Blog:Admin:Dashboard`. +El módulo `Blog` se divide en los submódulos `Admin` y `Front`. Esto también se refleja en los espacios de nombres, que aparecen como `App\UI\Blog\Admin` y similares. Para referirnos al presentador `Dashboard` dentro del submódulo `Admin`, lo denominamos `Blog:Admin:Dashboard`. -El anidamiento puede ser tan profundo como se desee, por lo que pueden crearse submódulos. +El anidamiento puede ser tan profundo como sea necesario, permitiendo la creación de sub-submódulos. + +Por ejemplo, si en administración tiene muchos presentadores relacionados con la gestión de pedidos, como `OrderDetail`, `OrderEdit`, `OrderDispatch`, etc., puede crear un módulo `Order` en el que se organizarán presentadores como `Detail`, `Edit`, `Dispatch`, y otros. Creación de enlaces .[#toc-creating-links] @@ -99,49 +115,69 @@ Enrutamiento .[#toc-routing] Véase el [capítulo sobre en rutamiento|routing#Modules]. -Mapeo .[#toc-mapping] ---------------------- +Cartografía .[#toc-mapping] +--------------------------- + +El mapeo define las reglas para derivar el nombre de la clase del nombre del presentador. Estas reglas se especifican en la [configuración |configuration] bajo la clave `application › mapping`. + +Las estructuras de directorios mencionadas anteriormente en esta página se basan en la siguiente asignación: -Define las reglas por las que el nombre de la clase se deriva del nombre del presentador. Las escribimos en [configuración |configuration] bajo la clave `application › mapping`. +```neon +application: + mapping: App\UI\*\**Presenter +``` -Empecemos con un ejemplo que no utiliza módulos. Sólo querremos que las clases del presentador tengan el espacio de nombres `App\Presenters`. Eso significa que un presentador como `Home` debe mapearse a la clase `App\Presenters\HomePresenter`. Esto se puede lograr con la siguiente configuración: +¿Cómo funciona el mapeo? Para entenderlo mejor, imaginemos primero una aplicación sin módulos. Queremos que las clases del presentador pertenezcan al espacio de nombres `App\UI`, de modo que el presentador `Home` se asigne a la clase `App\UI\HomePresenter`. Esto se puede lograr con esta configuración: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -El nombre del presentador se sustituye por el asterisco en la máscara de clase y el resultado es el nombre de la clase. Muy fácil. +Este mapeo funciona reemplazando el asterisco en la máscara `App\UI\*Presenter` con el nombre del presentador `Home`, resultando en el nombre final de la clase `App\UI\HomePresenter`. Es muy sencillo. + +Sin embargo, como puede ver en los ejemplos de este y otros capítulos, colocamos las clases de presentador en subdirectorios epónimos, por ejemplo, el presentador `Home` se asigna a la clase `App\UI\Home\HomePresenter`. Esto se consigue duplicando el asterisco (requiere Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Si dividimos a los presentadores en módulos, podemos tener nuestra propia asignación para cada módulo: +Pasemos ahora a la asignación de presentadores a módulos. Podemos definir asignaciones específicas para cada módulo: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Ahora el presentador `Front:Home` se asigna a la clase `App\Modules\Front\Presenters\HomePresenter` y el presentador `Admin:Dashboard` a la clase `App\Modules\Admin\Presenters\DashboardPresenter`. +Según esta configuración, el presentador `Front:Home` se asigna a la clase `App\UI\Front\Home\HomePresenter`, mientras que el presentador `Api:OAuth` se asigna a la clase `App\Api\OAuthPresenter`. -Es más práctico crear una regla general (estrella) para sustituir a las dos primeras. El asterisco adicional se añadirá a la máscara de clase sólo para el módulo: +Puesto que los módulos `Front` y `Admin` tienen un enfoque de asignación similar y es probable que haya más módulos de este tipo, es posible crear una regla general que los sustituya. Se añade un nuevo asterisco para el módulo a la máscara de la clase: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Pero, ¿y si utilizamos módulos anidados y tenemos un presentador `Admin:User:Edit`? En este caso, el segmento con un asterisco que representa el módulo para cada nivel simplemente se repite y el resultado es la clase `App\Modules\Admin\User\Presenters\EditPresenter`. +Para los módulos anidados de varios niveles, como el presentador `Admin:User:Edit`, el segmento del asterisco se repite para cada nivel, lo que da como resultado la clase `App\UI\Admin\User\Edit\EditPresenter`. -Una notación alternativa es utilizar una matriz formada por tres segmentos en lugar de una cadena. Esta notación es equivalente a la anterior: +Una notación alternativa consiste en utilizar una matriz compuesta por tres segmentos en lugar de una cadena. Esta notación es equivalente a la anterior: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -El valor por defecto es `*Module\*Presenter`. +Si sólo tenemos una regla en la configuración, la general, podemos escribir brevemente: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/es/templates.texy b/application/es/templates.texy index 761f7a648e..44a0bbeb7a 100644 --- a/application/es/templates.texy +++ b/application/es/templates.texy @@ -34,35 +34,81 @@ Y esta podría ser la plantilla de acción: Define el bloque `content`, que se inserta en lugar de `{include content}` en el diseño, y también redefine el bloque `title`, que sobrescribe `{block title}` en el diseño. Intenta imaginar el resultado. -Búsqueda de plantillas .[#toc-search-for-templates] ---------------------------------------------------- +Búsqueda de plantillas .[#toc-template-lookup] +---------------------------------------------- -La ruta a las plantillas se deduce según una lógica simple. Se intenta ver si uno de estos archivos de plantilla existe en relación con el directorio donde se encuentra la clase de presentador, donde `` es el nombre del presentador actual y `` es el nombre de la acción actual: +En los presentadores, no es necesario especificar qué plantilla debe renderizarse; el framework determinará automáticamente la ruta, facilitándole la codificación. -- `templates//.latte` -- `templates/..latte` +Si utiliza una estructura de directorios donde cada presentador tiene su propio directorio, simplemente coloque la plantilla en este directorio bajo el nombre de la acción (es decir, vista). Por ejemplo, para la acción `default`, utilice la plantilla `default.latte`: -Si no se encuentra la plantilla, se intentará buscar en el directorio `templates` un nivel más arriba, es decir, al mismo nivel que el directorio con la clase presentadora. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Si la plantilla tampoco se encuentra allí, la respuesta es un [error 404 |presenters#Error 404 etc.]. +Si utiliza una estructura en la que los presentadores están juntos en un directorio y las plantillas en una carpeta `templates`, guárdela en un archivo `..latte` o en `/.latte`: -También puede cambiar la vista utilizando `$this->setView('otherView')`. O, en lugar de buscar, especifique directamente el nombre del archivo de plantilla utilizando `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +El directorio `templates` también puede colocarse un nivel más arriba, al mismo nivel que el directorio con las clases de presentador. + +Si no se encuentra la plantilla, el presentador responde con el [error 404 - página no encontrada |presenters#Error 404 etc]. + +Puede cambiar la vista utilizando `$this->setView('anotherView')`. También es posible especificar directamente el archivo de plantilla con `$this->template->setFile('/path/to/template.latte')`. .[note] -Puede cambiar las rutas donde se buscan las plantillas anulando el método [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], que devuelve una matriz de posibles rutas de archivo. +Los archivos en los que se buscan las plantillas pueden cambiarse anulando el método [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], que devuelve una matriz de posibles nombres de archivo. + + +Búsqueda de plantillas de diseño .[#toc-layout-template-lookup] +--------------------------------------------------------------- + +Nette también busca automáticamente el archivo de diseño. + +Si utiliza una estructura de directorios en la que cada presentador tiene su propio directorio, coloque la maqueta en la carpeta con el presentador, si es específica sólo para él, o en un nivel superior si es común a varios presentadores: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Si utiliza una estructura en la que los presentadores están agrupados en un directorio y las plantillas se encuentran en una carpeta `templates`, la maquetación se esperará en los siguientes lugares: -El diseño se espera en los siguientes archivos: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` diseño común a varios presentadores +Si el presentador está en un [módulo |modules], también buscará más arriba en el árbol de directorios según el anidamiento del módulo. -`` es el nombre del presentador actual y `` es el nombre de la maquetación, que por defecto es `'layout'`. El nombre puede cambiarse con `$this->setLayout('otherLayout')`, de modo que se intentarán los archivos `@otherLayout.latte`. +El nombre de la presentación puede cambiarse utilizando `$this->setLayout('layoutAdmin')` y entonces se esperará en el archivo `@layoutAdmin.latte`. También puede especificar directamente el archivo de plantilla de presentación utilizando `$this->setLayout('/path/to/template.latte')`. -También puede especificar directamente el nombre de archivo de la plantilla de maquetación con `$this->setLayout('/path/to/template.latte')`. El uso de `$this->setLayout(false)` desactivará la búsqueda de diseños. +El uso de `$this->setLayout(false)` o de la etiqueta `{layout none}` dentro de la plantilla desactiva la búsqueda de diseños. .[note] -Puede cambiar las rutas donde se buscan las plantillas anulando el método [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], que devuelve una matriz de posibles rutas de archivo. +Los archivos en los que se buscan las plantillas de diseño pueden modificarse modificando el método [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], que devuelve una matriz de posibles nombres de archivo. Variables en la plantilla .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ La anotación `@property-read` es para IDE y análisis estático, hará que func Puedes permitirte el lujo de susurrar en las plantillas también, simplemente instala el plugin Latte en PhpStorm y especifica el nombre de la clase al principio de la plantilla, ver el artículo "Latte: cómo escribir sistema:https://blog.nette.org/es/latte-como-utilizar-el-sistema-de-tipos": ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void La versión 3 de Latte ofrece una forma más avanzada creando una [extensión |latte:creating-extension] para cada proyecto web. He aquí un ejemplo aproximado de una clase de este tipo: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ La registramos usando [configuration|configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/fr/how-it-works.texy b/application/fr/how-it-works.texy index 9c4358110a..57aeb786a4 100644 --- a/application/fr/how-it-works.texy +++ b/application/fr/how-it-works.texy @@ -22,13 +22,13 @@ La structure des répertoires ressemble à ceci : /--pre web-project/ ├── app/ ← répertoire avec application -│ ├── Presenters/ ← classes d'presenter -│ │ ├── HomePresenter.php ← Home classe des présentateurs -│ │ └── templates/ ← répertoire des modèles -│ │ ├── @layout.latte ← modèle de disposition partagée -│ │ └── Home/ ← Modèles pour le présentateur de la page d'accueil -│ │ └── default.latte ← modèle pour l'action `default` -│ ├── Router/ ← configuration des adresses URL +│ ├── Core/ ← basic necessary classes +│ │ └── RouterFactory.php ← configuration des adresses URL +│ ├── UI/ ← presenters, templates & co. +│ │ ├─── @layout.latte ← template of shared layout +│ │ └── Home/ ← Home presenter directory +│ │ ├── HomePresenter.php ← Classe Home Presenter +│ │ └── default.latte ← template for action default │ └── Bootstrap.php ← classe de démarrage Bootstrap ├── bin/ ← scripts pour la ligne de commande ├── config/ ← configuration files @@ -91,7 +91,7 @@ Les applications écrites dans Nette sont divisées en plusieurs présentateurs L'application commence par demander à ce qu'on appelle le routeur de décider lequel des présentateurs doit transmettre la demande actuelle pour traitement. Le routeur décide de la responsabilité qui lui incombe. Il examine l'URL d'entrée `https://example.com/product/123`, qui veut `show` un produit avec `id: 123` comme action. C'est une bonne habitude d'écrire une paire présentateur + action séparée par un deux-points comme `Product:show`. -Le routeur transforme donc l'URL en une paire `Presenter:action` + paramètres, dans notre cas `Product:show` + `id: 123`. Vous pouvez voir à quoi ressemble un routeur dans le fichier `app/Router/RouterFactory.php` et nous le décrirons en détail dans le chapitre [Routage |Routing]. +Le routeur transforme donc l'URL en une paire `Presenter:action` + paramètres, dans notre cas `Product:show` + `id: 123`. Vous pouvez voir à quoi ressemble un routeur dans le fichier `app/Core/RouterFactory.php` et nous le décrirons en détail dans le chapitre [Routage |Routing]. Continuons. L'application connaît déjà le nom du présentateur et peut continuer. En créant un objet `ProductPresenter`, qui est le code du présentateur `Product`. Plus précisément, elle demande au conteneur DI de créer le présentateur, car la production d'objets est son travail. @@ -121,12 +121,9 @@ Ainsi, la méthode `renderShow(123)` a été appelée, dont le code est un exemp Ensuite, le présentateur renvoie la réponse. Cela peut être une page HTML, une image, un document XML, l'envoi d'un fichier depuis le disque, JSON ou la redirection vers une autre page. Il est important de noter que si nous ne disons pas explicitement comment répondre (ce qui est le cas de `ProductPresenter`), la réponse sera de rendre le modèle avec une page HTML. Pourquoi ? Eh bien, parce que dans 99% des cas, nous voulons dessiner un modèle, donc le présentateur prend ce comportement par défaut et veut nous faciliter le travail. C'est le point de vue de Nette. -Nous n'avons même pas besoin d'indiquer quel modèle dessiner, il dérive le chemin vers celui-ci selon une logique simple. Dans le cas du présentateur `Product` et de l'action `show`, il essaie de voir si l'un de ces fichiers modèles existe par rapport au répertoire où se trouve la classe `ProductPresenter`: +Il n'est même pas nécessaire de spécifier le modèle à rendre ; le framework déduira lui-même le chemin d'accès. Dans le cas de l'action `show`, il essaie simplement de charger le modèle `show.latte` dans le répertoire contenant la classe `ProductPresenter`. Il tente également de trouver la mise en page dans le fichier `@layout.latte` (plus d'informations sur la [recherche de modèles |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Il essaiera également de trouver la mise en page dans le fichier `@layout.latte`, puis il effectuera le rendu du modèle. La tâche du présentateur et de l'ensemble de l'application est maintenant terminée. Si le modèle n'existe pas, une page d'erreur 404 sera renvoyée. Vous pouvez en savoir plus sur les présentateurs sur la page [Présentateurs |Presenters]. +Ensuite, les modèles sont rendus. La tâche du présentateur et de l'ensemble de l'application est ainsi achevée et le travail est terminé. Si le modèle n'existait pas, une page d'erreur 404 serait renvoyée. Pour en savoir plus sur les présentateurs, consultez la page [Présentateurs |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Juste pour être sûr, essayons de récapituler l'ensemble du processus avec une 3) le routeur décode l'URL comme une paire `Home:default` 4) un objet `HomePresenter` est créé 5) la méthode `renderDefault()` est appelée (si elle existe) -6) un modèle `templates/Home/default.latte` avec une mise en page `templates/@layout.latte` est rendu +6) un modèle `default.latte` avec une mise en page `@layout.latte` est rendu Vous avez peut-être rencontré beaucoup de nouveaux concepts maintenant, mais nous pensons qu'ils ont un sens. Créer des applications dans Nette est un jeu d'enfant. diff --git a/application/fr/modules.texy b/application/fr/modules.texy index 754e97b5ad..7734341840 100644 --- a/application/fr/modules.texy +++ b/application/fr/modules.texy @@ -2,29 +2,31 @@ Modules ******* .[perex] -Dans Nette, les modules représentent les unités logiques qui composent une application. Ils comprennent des présentateurs, des modèles, éventuellement aussi des composants et des classes de modèles. +Les modules apportent de la clarté aux applications Nette en facilitant la division en unités logiques. -Un répertoire pour les présentateurs et un autre pour les modèles ne seraient pas suffisants pour les projets réels. Avoir des dizaines de fichiers dans un seul dossier est pour le moins inorganisé. Comment s'en sortir ? Il suffit de les répartir en sous-répertoires sur le disque et en espaces de noms dans le code. Et c'est exactement ce que font les modules Nette. - -Oublions donc le dossier unique pour les présentateurs et les modèles et créons plutôt des modules, par exemple `Admin` et `Front`. +À l'instar de l'organisation des fichiers en dossiers sur un disque dur, Nette permet de diviser les présentateurs, les modèles et les autres classes auxiliaires en modules. Comment cela fonctionne-t-il en pratique ? Simplement en incorporant de nouveaux sous-répertoires dans la structure. Voici un exemple de structure avec deux modules, Front et Admin : /--pre -app/ -├── Presenters/ -├── Modules/ ← répertoire avec les modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← ses présentateurs -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← ses présentateurs -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Cette structure de répertoire sera reflétée par les espaces de noms des classes, ainsi par exemple `DashboardPresenter` sera dans l'espace de noms `App\Modules\Admin\Presenters`: +Cette structure de répertoires se reflète dans les espaces de noms des classes. Ainsi, par exemple, `DashboardPresenter` est situé dans l'espace de noms `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Le présentateur `Dashboard` dans le module `Admin` est référencé dans l'application en utilisant la notation deux points comme `Admin:Dashboard`, et son action `default` comme `Admin:Dashboard:default`. -Et comment Nette proper sait-elle que `Admin:Dashboard` représente la classe `App\Modules\Admin\Presenters\DashboardPresenter`? Cela est déterminé par le [mappage |#mapping] dans la configuration. -Ainsi, la structure donnée n'est pas figée et vous pouvez la modifier en fonction de vos besoins. +Dans l'application, nous faisons référence au présentateur `Dashboard` dans le module `Admin` en utilisant la notation des deux points comme `Admin:Dashboard`. Pour son action `default`, nous l'appelons `Admin:Dashboard:default`. -Les modules peuvent bien sûr contenir tous les éléments autres que les présentateurs et les modèles, tels que les composants, les classes de modèles, etc. +La structure présentée n'est pas rigide ; vous pouvez [l'adapter entièrement à vos besoins |#mapping] dans la configuration. .[tip] + +Les modules peuvent inclure tous les autres fichiers, tels que les composants et les classes auxiliaires, en plus des présentateurs et des modèles. Si vous vous demandez où placer ces derniers, envisagez d'utiliser un dossier `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Modules imbriqués .[#toc-nested-modules] ---------------------------------------- -Les modules ne doivent pas uniquement former une structure plate, vous pouvez également créer des sous-modules, par exemple : +Les modules peuvent avoir plusieurs niveaux d'imbrication, comme la structure d'un répertoire sur un disque : /--pre -app/ -├── Modules/ ← répertoire avec les modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← sous-module Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← sous-module Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Ainsi, le module `Blog` est divisé en sous-modules `Admin` et `Front`. Là encore, cela se reflétera dans les espaces de noms, qui seront `App\Modules\Blog\Admin\Presenters` etc. Le présentateur `Dashboard` à l'intérieur du sous-module est désigné par `Blog:Admin:Dashboard`. +Le module `Blog` est divisé en sous-modules `Admin` et `Front`. Cela se reflète également dans les espaces de noms, qui apparaissent alors comme `App\UI\Blog\Admin` et similaires. Pour désigner le présentateur `Dashboard` au sein du sous-module `Admin`, nous l'appelons `Blog:Admin:Dashboard`. -L'imbrication peut aller aussi loin que vous le souhaitez, de sorte que des sous-sous-modules peuvent être créés. +L'imbrication peut être aussi poussée que nécessaire, ce qui permet de créer des sous-sous-modules. + +Par exemple, si dans l'administration vous avez de nombreux présentateurs liés à la gestion des commandes, tels que `OrderDetail`, `OrderEdit`, `OrderDispatch`, etc., vous pouvez créer un module `Order` dans lequel les présentateurs tels que `Detail`, `Edit`, `Dispatch`, et d'autres seront organisés. Création de liens .[#toc-creating-links] @@ -102,46 +118,66 @@ Voir le [chapitre sur le routage |routing#Modules]. Cartographie .[#toc-mapping] ---------------------------- -Définit les règles par lesquelles le nom de la classe est dérivé du nom du présentateur. On les inscrit dans la [configuration] sous la clé `application › mapping`. +Le mappage définit les règles permettant de dériver le nom de la classe à partir du nom du présentateur. Ces règles sont spécifiées dans la [configuration |configuration] sous la clé `application › mapping`. + +Les structures de répertoire mentionnées plus haut sur cette page sont basées sur la correspondance suivante : + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Commençons par un exemple qui n'utilise pas de modules. Nous voulons simplement que les classes du présentateur aient l'espace de nom `App\Presenters`. Cela signifie qu'un présentateur tel que `Home` doit correspondre à la classe `App\Presenters\HomePresenter`. Ceci peut être réalisé par la configuration suivante : +Comment fonctionne la cartographie ? Pour mieux comprendre, imaginons d'abord une application sans modules. Nous voulons que les classes de présentateurs relèvent de l'espace de noms `App\UI`, de sorte que le présentateur `Home` soit associé à la classe `App\UI\HomePresenter`. Cette configuration permet d'atteindre cet objectif : ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Le nom du présentateur est remplacé par l'astérisque dans le masque de classe et le résultat est le nom de la classe. Facile ! +Ce mappage fonctionne en remplaçant l'astérisque du masque `App\UI\*Presenter` par le nom du présentateur `Home`, ce qui donne le nom de classe final `App\UI\HomePresenter`. C'est simple ! + +Cependant, comme vous pouvez le voir dans les exemples de ce chapitre et d'autres chapitres, nous plaçons les classes de présentateurs dans des sous-répertoires éponymes, par exemple, le présentateur `Home` est associé à la classe `App\UI\Home\HomePresenter`. Pour ce faire, il suffit de doubler l'astérisque (Nette Application 3.2 requise) : + +```neon +application: + mapping: App\UI\**Presenter +``` -Si nous divisons les présentateurs en modules, nous pouvons avoir notre propre mappage pour chaque module : +Passons maintenant au mappage des présentateurs dans les modules. Nous pouvons définir des correspondances spécifiques pour chaque module : ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Maintenant, le présentateur `Front:Home` correspond à la classe `App\Modules\Front\Presenters\HomePresenter` et le présentateur `Admin:Dashboard` à la classe `App\Modules\Admin\Presenters\DashboardPresenter`. +Selon cette configuration, le présentateur `Front:Home` correspond à la classe `App\UI\Front\Home\HomePresenter`, tandis que le présentateur `Api:OAuth` correspond à la classe `App\Api\OAuthPresenter`. -Il est plus pratique de créer une règle générale (étoile) pour remplacer les deux premières. L'astérisque supplémentaire sera ajouté au masque de classe uniquement pour le module : +Étant donné que les modules `Front` et `Admin` ont une approche de mappage similaire et qu'il est probable qu'il y ait d'autres modules de ce type, il est possible de créer une règle générale qui les remplace. Un nouvel astérisque pour le module est ajouté au masque de classe : ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Mais qu'en est-il si nous utilisons des modules imbriqués et que nous avons un présentateur `Admin:User:Edit`? Dans ce cas, le segment avec un astérisque représentant le module pour chaque niveau est simplement répété et le résultat est la classe `App\Modules\Admin\User\Presenters\EditPresenter`. +Pour les modules imbriqués à plusieurs niveaux, tels que le présentateur `Admin:User:Edit`, le segment astérisque se répète pour chaque niveau, ce qui donne la classe `App\UI\Admin\User\Edit\EditPresenter`. -Une notation alternative consiste à utiliser un tableau composé de trois segments au lieu d'une chaîne de caractères. Cette notation est équivalente à la précédente : +Une autre notation consiste à utiliser un tableau composé de trois segments au lieu d'une chaîne. Cette notation est équivalente à la précédente : ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -La valeur par défaut est `*Module\*Presenter`. +Si nous n'avons qu'une seule règle dans la configuration, la règle générale, nous pouvons l'écrire brièvement : + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/fr/templates.texy b/application/fr/templates.texy index 8ecd733495..dc2ccff07f 100644 --- a/application/fr/templates.texy +++ b/application/fr/templates.texy @@ -34,35 +34,81 @@ Et ceci pourrait être le modèle d'action : Il définit le bloc `content`, qui est inséré à la place de `{include content}` dans la mise en page, et redéfinit également le bloc `title`, qui écrase `{block title}` dans la mise en page. Essayez d'imaginer le résultat. -Recherche de modèles .[#toc-search-for-templates] -------------------------------------------------- +Recherche de modèles .[#toc-template-lookup] +-------------------------------------------- -Le chemin vers les modèles est déduit selon une logique simple. Il essaie de voir si l'un de ces fichiers modèles existe par rapport au répertoire où se trouve la classe du présentateur, où `` est le nom du présentateur actuel et `` est le nom de l'action en cours : +Dans les présentateurs, vous n'avez pas besoin de spécifier quel modèle doit être rendu ; le cadre détermine automatiquement le chemin, ce qui facilite le codage. -- `templates//.latte` -- `templates/..latte` +Si vous utilisez une structure de répertoires dans laquelle chaque présentateur a son propre répertoire, placez simplement le modèle dans ce répertoire sous le nom de l'action (c'est-à-dire de la vue). Par exemple, pour l'action `default`, utilisez le modèle `default.latte`: -Si le modèle n'est pas trouvé, il essaiera de chercher dans le répertoire `templates` au niveau supérieur, c'est-à-dire au même niveau que le répertoire contenant la classe du présentateur. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Si le modèle n'y est pas trouvé non plus, la réponse est une [erreur 404 |presenters#Error 404 etc.]. +Si vous utilisez une structure dans laquelle les présentateurs sont regroupés dans un répertoire et les modèles dans un dossier `templates`, enregistrez-les dans un fichier `..latte` soit dans un fichier `/.latte`: -Vous pouvez également changer la vue en utilisant `$this->setView('otherView')`. Ou, au lieu de chercher, spécifiez directement le nom du fichier de modèle en utilisant `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +Le répertoire `templates` peut également être placé un niveau plus haut, au même niveau que le répertoire des classes de présentateurs. + +Si le modèle n'est pas trouvé, le présentateur répond par l'[erreur 404 - page non trouvée |presenters#Error 404 etc]. + +Vous pouvez changer la vue en utilisant `$this->setView('anotherView')`. Il est également possible de spécifier directement le fichier de modèle avec `$this->template->setFile('/path/to/template.latte')`. .[note] -Vous pouvez modifier les chemins dans lesquels les modèles sont recherchés en remplaçant la méthode [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], qui renvoie un tableau de chemins de fichiers possibles. +Les fichiers dans lesquels les modèles sont recherchés peuvent être modifiés en remplaçant la méthode [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], qui renvoie un tableau de noms de fichiers possibles. + + +Recherche de modèles de mise en page .[#toc-layout-template-lookup] +------------------------------------------------------------------- + +Nette recherche également automatiquement le fichier de mise en page. + +Si vous utilisez une structure de répertoires dans laquelle chaque présentateur a son propre répertoire, placez le modèle soit dans le dossier du présentateur, s'il lui est propre, soit à un niveau supérieur s'il est commun à plusieurs présentateurs : + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Si vous utilisez une structure dans laquelle les présentateurs sont regroupés dans un répertoire et les modèles dans un dossier `templates`, la mise en page sera attendue aux endroits suivants : -Le modèle est attendu dans les fichiers suivants : +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` mise en page commune à plusieurs présentateurs +Si le présentateur se trouve dans un [module |modules], il cherchera également plus haut dans l'arborescence du répertoire en fonction de l'imbrication du module. -`` est le nom du présentateur actuel et `` est le nom de la mise en page, qui est par défaut `'layout'`. Le nom peut être modifié avec `$this->setLayout('otherLayout')`, de sorte que les fichiers `@otherLayout.latte` seront essayés. +Le nom de la présentation peut être modifié à l'aide de `$this->setLayout('layoutAdmin')` et sera alors attendu dans le fichier `@layoutAdmin.latte`. Vous pouvez également spécifier directement le fichier de modèle de présentation en utilisant `$this->setLayout('/path/to/template.latte')`. -Vous pouvez également spécifier directement le nom du fichier du modèle de présentation en utilisant `$this->setLayout('/path/to/template.latte')`. L'utilisation de `$this->setLayout(false)` désactivera la recherche de la mise en page. +L'utilisation de `$this->setLayout(false)` ou de la balise `{layout none}` à l'intérieur du modèle désactive la recherche de modèle. .[note] -Vous pouvez modifier les chemins dans lesquels les modèles sont recherchés en remplaçant la méthode [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], qui renvoie un tableau de chemins de fichiers possibles. +Les fichiers dans lesquels les modèles de présentation sont recherchés peuvent être modifiés en remplaçant la méthode [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], qui renvoie un tableau de noms de fichiers possibles. Variables dans le modèle .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ L'annotation `@property-read` est pour les IDE et l'analyse statique, elle fera Vous pouvez aussi vous offrir le luxe de chuchoter dans les templates, il suffit d'installer le plugin Latte dans PhpStorm et de spécifier le nom de la classe au début du template, voir l'article "Latte : how to type system":https://blog.nette.org/fr/latte-comment-utiliser-le-systeme-de-type: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte version 3 propose un moyen plus avancé en créant une [extension |latte:creating-extension] pour chaque projet web. Voici un exemple approximatif d'une telle classe : ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Nous l'enregistrons en utilisant la [configuration |configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/hu/how-it-works.texy b/application/hu/how-it-works.texy index 5101363032..24d0e0cba1 100644 --- a/application/hu/how-it-works.texy +++ b/application/hu/how-it-works.texy @@ -22,13 +22,13 @@ A könyvtárszerkezet valahogy így néz ki: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← alapvető szükséges osztályok +│ │ └── RouterFactory.php ← URL címek konfigurálása +│ ├── UI/ ← prezenterek, sablonok és társai. +│ │ ├── @layout.latte ← a megosztott elrendezés sablonja +│ │ └── Home/ ← Főoldal bemutatókönyvtár +│ │ ├── HomePresenter.php ← Home prezenter osztály +│ │ └── default.latte ← cselekvési sablon default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ A Nette-ben írt alkalmazások sok úgynevezett prezenterre oszlanak (más keret Az alkalmazás azzal indul, hogy az ún. routertől kéri, hogy döntse el, hogy az aktuális kérést melyik prezenternek adja át feldolgozásra. A router dönti el, hogy kinek a felelőssége. Megnézi a bemeneti URL-t `https://example.com/product/123`, aki a `show` egy terméket `id: 123` művelettel akarja ellátni. Jó szokás a prezenter + akció párokat kettősponttal elválasztva `Product:show`-ként írni. -Tehát a router az URL-t átalakította `Presenter:action` + paraméterek párrá, esetünkben `Product:show` + `id: 123`. A `app/Router/RouterFactory.php` fájlban láthatjuk, hogyan néz ki egy útválasztó, és ezt részletesen az [Útválasztás |Routing] fejezetben fogjuk leírni. +Tehát a router az URL-t átalakította `Presenter:action` + paraméterek párrá, esetünkben `Product:show` + `id: 123`. A `app/Core/RouterFactory.php` fájlban láthatjuk, hogyan néz ki egy útválasztó, és ezt részletesen az [Útválasztás |Routing] fejezetben fogjuk leírni. Lépjünk tovább. Az alkalmazás már ismeri a bemutató nevét, és folytathatja. Egy `ProductPresenter` objektum létrehozásával, amely a `Product` bemutató kódja. Pontosabban megkéri a DI konténert a prezenter létrehozására, mert az objektumok előállítása az ő feladata. @@ -121,12 +121,9 @@ Tehát a `renderShow(123)` metódust hívtuk meg, amelynek kódja fiktív példa Ezt követően a prezenter visszaadja a választ. Ez lehet egy HTML oldal, egy kép, egy XML dokumentum, egy fájl elküldése a lemezről, JSON vagy egy másik oldalra való átirányítás. Fontos, hogy ha nem mondjuk meg kifejezetten, hogyan kell válaszolni (ami a `ProductPresenter` esetében a helyzet), akkor a válasz az lesz, hogy a sablon egy HTML-oldallal jeleníti meg a sablont. Hogy miért? Nos, mert az esetek 99%-ában egy sablont szeretnénk kirajzolni, így a prezentáló ezt a viselkedést veszi alapértelmezettnek, és a mi munkánkat akarja megkönnyíteni. Ez a Nette lényege. -Még csak meg sem kell adnunk, hogy melyik sablont rajzoljuk ki, egyszerű logika szerint levezeti az oda vezető utat. A presenter `Product` és az action `show` esetében megnézi, hogy létezik-e valamelyik sablonfájl a `ProductPresenter` osztály könyvtárához képest, ahol a osztály található: +Még azt sem kell megadnunk, hogy melyik sablont kell megjelenítenünk; a keretrendszer magától levonja az útvonalat. A `show` akció esetében egyszerűen megpróbálja betölteni a `show.latte` sablont a `ProductPresenter` osztályt tartalmazó könyvtárban. Megpróbálja megtalálni az elrendezést is a `@layout.latte` fájlban (a [sablonkeresésről |templates#Template Lookup] bővebben). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Megpróbálja megtalálni az elrendezést is a `@layout.latte` fájlban, majd rendereli a sablont. Ezzel a prezenter és az egész alkalmazás feladata befejeződött. Ha a sablon nem létezik, akkor egy 404-es hibaüzenetű oldal fog visszakerülni. A prezenterekről bővebben a [Prezenterek |Presenters] oldalon olvashat. +Ezt követően a sablonok megjelenítésre kerülnek. Ezzel a bemutató és az egész alkalmazás feladata befejeződik, és a munka elvégeztetett. Ha a sablon nem létezne, akkor egy 404-es hibaoldalt kapna vissza. A prezenterekről bővebben a [Prezenterek |presenters] oldalon olvashat. [* request-flow.svg *] @@ -137,7 +134,7 @@ A biztonság kedvéért próbáljuk meg az egész folyamatot egy kicsit más URL 3) a router dekódolja az URL-t, mint egy párat `Home:default` 4) létrejön egy `HomePresenter` objektum 5) a `renderDefault()` metódust meghívjuk (ha létezik) -6) egy `templates/Home/default.latte` sablon `templates/@layout.latte` elrendezéssel megjelenik. +6) egy `default.latte` sablon `@layout.latte` elrendezéssel megjelenik. Lehet, hogy most sok új fogalommal találkoztál, de úgy gondoljuk, hogy van értelme. Az alkalmazások létrehozása a Nette-ben gyerekjáték. diff --git a/application/hu/modules.texy b/application/hu/modules.texy index e4ec0d80aa..a44b6ec874 100644 --- a/application/hu/modules.texy +++ b/application/hu/modules.texy @@ -2,29 +2,31 @@ Modulok ******* .[perex] -A Nette-ben a modulok az alkalmazást alkotó logikai egységeket jelentik. Ide tartoznak a prezenterek, sablonok, esetleg komponensek és modellosztályok. +A modulok a Nette-alkalmazások áttekinthetőségét segítik elő azáltal, hogy megkönnyítik a logikai egységekre való egyszerű felosztást. -Egy könyvtár a bemutatóknak és egy a sablonoknak nem lenne elég a valódi projektekhez. Több tucat fájl egy mappában való elhelyezése legalábbis rendezetlen. Hogyan szabadulhatunk meg ettől? Egyszerűen felosztjuk őket alkönyvtárakra a lemezen és névterekre a kódban. És pontosan ezt teszik a Nette modulok. - -Felejtsük el tehát az egyetlen mappát az előadóknak és a sablonoknak, és helyette hozzunk létre modulokat, például a `Admin` és a `Front`. +Hasonlóan a fájlok mappákba rendezéséhez a merevlemezen, a Nette-ben modulokba oszthatjuk a prezentereket, sablonokat és más segédosztályokat. Hogyan működik ez a gyakorlatban? Egyszerűen úgy, hogy új alkönyvtárakat építünk be a struktúrába. Íme egy példa egy struktúrára két modullal, a Front és az Admin modulokkal: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Ezt a könyvtárszerkezetet az osztályok névterei is tükrözni fogják, így például a `DashboardPresenter` a `App\Modules\Admin\Presenters` névtérben lesz: +Ez a könyvtárszerkezet tükröződik az osztályok névterében, így például a `DashboardPresenter` a `App\UI\Admin\Dashboard` névtérben található: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -A `Dashboard` prezenterre a `Admin` modulon belül az alkalmazáson belül a kettőspont jelöléssel `Admin:Dashboard`, a `default` műveletre pedig `Admin:Dashboard:default` néven hivatkozunk. -És honnan tudja a Nette proper, hogy a `Admin:Dashboard` a `App\Modules\Admin\Presenters\DashboardPresenter` osztályt képviseli? Ezt a konfigurációban történő [leképezéssel |#mapping] határozzuk meg. -A megadott struktúra tehát nem keményen meghatározott, és Ön az igényeinek megfelelően módosíthatja. +Az alkalmazásban a `Dashboard` bemutatóra a `Admin` modulon belül a `Admin:Dashboard` kettőspont jelöléssel hivatkozunk a . A `default` műveletére `Admin:Dashboard:default` néven hivatkozunk. -A modulok természetesen a prezentereken és sablonokon kívül minden más elemet is tartalmazhatnak, például komponenseket, modellosztályokat stb. +A bemutatott struktúra nem merev; a konfigurációban [teljes mértékben az igényeihez igazíthatja |#mapping]. .[tip] + +A modulok a prezentereken és sablonokon kívül minden más fájlt, például komponenseket és segédosztályokat is tartalmazhatnak. Ha mérlegeli, hogy hol helyezze el ezeket, fontolja meg a `Accessory` mappa használatát: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Beágyazott modulok .[#toc-nested-modules] ----------------------------------------- -A moduloknak nem kell csak sima struktúrát alkotniuk, létrehozhatunk például almodulokat is: +A modulok több szinten is egymásba ágyazhatók, hasonlóan a lemezen lévő könyvtárstruktúrához: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Így a `Blog` modul `Admin` és `Front` almodulokra oszlik. Ez ismét tükröződik a névterekben, amelyek a `App\Modules\Blog\Admin\Presenters` stb. lesznek. Az almodulon belüli `Dashboard` bemutatót `Blog:Admin:Dashboard` néven említjük. +A `Blog` modul `Admin` és `Front` almodulokra oszlik. Ez tükröződik a névterekben is, amelyek aztán `App\UI\Blog\Admin` és hasonló módon jelennek meg. A `Dashboard` bemutatóra a `Admin` almodulon belül `Blog:Admin:Dashboard` néven hivatkozunk. -A beágyazás tetszőlegesen mélyre mehet, így al-almodulok hozhatók létre. +A beágyazás olyan mély lehet, amilyen mélyre csak szükséges, lehetővé téve al-almodulok létrehozását. + +Például, ha az adminisztrációban sok, a rendeléskezeléshez kapcsolódó prezenter van, mint például `OrderDetail`, `OrderEdit`, `OrderDispatch`, stb., létrehozhat egy `Order` modult, amelyben a `Detail`, `Edit`, `Dispatch`, stb. típusú prezentereket szervezi. Linkek létrehozása .[#toc-creating-links] @@ -99,49 +115,69 @@ Hogy megtudjuk, hogy egy adott modulban vagy annak almoduljában vagyunk-e, hasz Lásd [az útválasztásról szóló fejezetet |routing#Modules]. -Feltérképezés .[#toc-mapping] ------------------------------ +A feltérképezése .[#toc-mapping] +--------------------------------- + +A leképezés határozza meg az osztálynévnek a bemutató nevéből való származtatásának szabályait. Ezek a szabályok a [konfigurációban |configuration] a `application › mapping` kulcs alatt vannak megadva. + +Az ezen az oldalon korábban említett könyvtárszerkezetek a következő leképezésen alapulnak: -Meghatározza azokat a szabályokat, amelyek alapján az osztály neve az előadó nevéből származik. Ezeket a [konfigurációban |configuration] a `application › mapping` kulcs alatt írjuk le. +```neon +application: + mapping: App\UI\*\**Presenter +``` -Kezdjük egy olyan példával, amely nem használ modulokat. Csak azt akarjuk, hogy a prezenter osztályok a `App\Presenters` névtérrel rendelkezzenek. Ez azt jelenti, hogy egy olyan prezenternek, mint a `Home`, a `App\Presenters\HomePresenter` osztályhoz kell kapcsolódnia. Ezt a következő konfigurációval érhetjük el: +Hogyan működik a térképezés? A jobb megértés érdekében először képzeljünk el egy modulok nélküli alkalmazást. Szeretnénk, ha a prezenter osztályok a `App\UI` névtérbe tartoznának, így a `Home` prezenter a `App\UI\HomePresenter` osztályhoz tartozik. Ezt a következő konfigurációval érhetjük el: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Az osztálymaszkban a prezenter nevét csillaggal helyettesítjük, és az eredmény az osztály neve lesz. Easy! +Ez a leképezés úgy működik, hogy a `App\UI\*Presenter` maszkban a csillagot a `Home` prezenter névvel helyettesítjük, így kapjuk a `App\UI\HomePresenter` végső osztálynevet. Egyszerű! + +Azonban, ahogyan azt az ebben és más fejezetekben található példákban láthatjuk, a prezenter osztályokat névadó alkönyvtárakba helyezzük, például a `Home` prezenter a `App\UI\Home\HomePresenter` osztályra van leképezve. Ezt a csillag megduplázásával érjük el (Nette Application 3.2 szükséges): + +```neon +application: + mapping: App\UI\**Presenter +``` -Ha az előadókat modulokra osztjuk, akkor minden modulhoz saját leképezésünk lehet: +Most pedig térjünk rá az előadók modulokba való leképezésére. Minden egyes modulhoz sajátos hozzárendeléseket határozhatunk meg: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Most a `Front:Home` bemutatót a `App\Modules\Front\Presenters\HomePresenter` osztályra, a `Admin:Dashboard` bemutatót pedig a `App\Modules\Admin\Presenters\DashboardPresenter` osztályra képezzük le. +E konfiguráció szerint a `Front:Home` bemutató a `App\UI\Front\Home\HomePresenter` osztályhoz, míg a `Api:OAuth` bemutató a `App\Api\OAuthPresenter` osztályhoz tartozik. -Praktikusabb egy általános (csillag) szabályt létrehozni az első kettő helyett. Az extra csillagot csak a modul számára adjuk hozzá az osztálymaszkhoz: +Mivel a `Front` és a `Admin` modulok hasonló leképezési megközelítéssel rendelkeznek, és valószínűleg több ilyen modul is létezik, létrehozható egy általános szabály, amely ezeket helyettesíti. Az osztálymaszkhoz egy új csillagot adunk a modulhoz: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -De mi van akkor, ha egymásba ágyazott modulokat használunk, és van egy bemutató `Admin:User:Edit`? Ebben az esetben a modult jelképező csillaggal ellátott szegmens minden szinten egyszerűen megismétlődik, és az eredmény a `App\Modules\Admin\User\Presenters\EditPresenter` osztály lesz. +A többszintű, egymásba ágyazott modulok esetében, mint például a `Admin:User:Edit` bemutató, a csillagszegmens minden szinten megismétlődik, így a `App\UI\Admin\User\Edit\EditPresenter` osztály lesz az eredmény. -Egy alternatív jelölés az, hogy a karakterlánc helyett egy három szegmensből álló tömböt használunk. Ez a jelölés egyenértékű az előzővel: +Egy alternatív jelölés a karakterlánc helyett egy három szegmensből álló tömb használata. Ez a jelölés egyenértékű az előzővel: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Az alapértelmezett érték a `*Module\*Presenter`. +Ha csak egy szabály van a konfigurációban, az általános szabály, akkor röviden leírhatjuk: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/hu/templates.texy b/application/hu/templates.texy index 71b205b7d1..d51d03bbc6 100644 --- a/application/hu/templates.texy +++ b/application/hu/templates.texy @@ -34,35 +34,81 @@ Az a szokásos, hogy az oldal az elrendezési sablonból + az akció sablonból Meghatározza a `content` blokkot, amely az elrendezésben a `{include content}` helyére kerül, és újra definiálja a `title` blokkot is, amely felülírja az elrendezésben a `{block title}` blokkot. Próbálja meg elképzelni az eredményt. -Sablonok keresése .[#toc-search-for-templates] ----------------------------------------------- +Sablon keresés .[#toc-template-lookup] +-------------------------------------- -A sablonok elérési útvonalát egyszerű logika szerint vezetjük le. Megpróbálja megnézni, hogy létezik-e valamelyik sablonfájl ahhoz a könyvtárhoz képest, ahol a prezenter osztály található, ahol a `` az aktuális prezenter neve és `` az aktuális művelet neve: +A prezenterekben nem kell megadnia, hogy melyik sablont kell megjeleníteni; a keretrendszer automatikusan meghatározza az útvonalat, megkönnyítve ezzel a kódolást. -- `templates//.latte` -- `templates/..latte` +Ha olyan könyvtárstruktúrát használ, ahol minden prezenternek saját könyvtára van, egyszerűen helyezze el a sablont ebben a könyvtárban az akció (pl. nézet) neve alatt. Például a `default` művelethez használja a `default.latte` sablont: -Ha a sablon nem található, a program megpróbál a `templates` könyvtárban keresni egy szinttel feljebb, azaz ugyanazon a szinten, mint a bemutató osztályt tartalmazó könyvtár. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Ha a sablon ott sem található, a válasz [404-es hiba |presenters#Error 404 etc.]. +Ha olyan struktúrát használ, ahol az előadók együttesen egy könyvtárban vannak, a sablonok pedig a `templates` mappában, mentse el vagy egy fájlban `..latte` vagy a `/.latte`: -A nézetet a `$this->setView('otherView')` segítségével is megváltoztathatja. Vagy a keresés helyett közvetlenül megadhatja a sablonfájl nevét a `$this->template->setFile('/path/to/template.latte')` segítségével. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +A `templates` könyvtár egy szinttel feljebb is elhelyezhető, ugyanazon a szinten, mint az előadói osztályokat tartalmazó könyvtár. + +Ha a sablon nem található, a prezenter [404 - page not found hibával |presenters#Error 404 etc] válaszol. + +A nézetet a `$this->setView('anotherView')` segítségével lehet megváltoztatni. Lehetőség van a sablonfájl közvetlen megadására is a `$this->template->setFile('/path/to/template.latte')` segítségével. .[note] -A [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()] metódus felülbírálásával módosíthatja azokat az elérési utakat, ahol a sablonok keresése történik, amely a lehetséges fájl elérési utak tömbjét adja vissza. +A fájlokat, amelyekben a sablonok keresése történik, a [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()] metódus felülbírálásával lehet megváltoztatni, amely a lehetséges fájlnevek tömbjét adja vissza. + + +Layout sablon keresés .[#toc-layout-template-lookup] +---------------------------------------------------- + +A Nette automatikusan megkeresi az elrendezési fájlt is. + +Ha olyan könyvtárstruktúrát használ, ahol minden előadónak saját könyvtára van, akkor az elrendezést vagy az előadóval közös mappába helyezze el, ha csak rá jellemző, vagy egy szinttel feljebb, ha több előadó számára közös: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Ha olyan struktúrát használ, ahol az előadók egy könyvtárban vannak csoportosítva, a sablonok pedig a `templates` mappában találhatók, az elrendezés a következő helyeken várható: -Az elrendezés a következő fájlokban várható: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` több előadónál közös elrendezés +Ha a bemutató egy [modulban |modules] van, akkor a modul beágyazottságának megfelelően a könyvtárfában feljebb is keresni fog. -`` az aktuális előadó neve és `` az elrendezés neve, amely alapértelmezés szerint `'layout'`. A név megváltoztatható a `$this->setLayout('otherLayout')` segítségével, így a `@otherLayout.latte` fájlokat próbálja meg. +Az elrendezés nevét a `$this->setLayout('layoutAdmin')` segítségével lehet megváltoztatni, majd a `@layoutAdmin.latte` fájlban várjuk el. Az elrendezés sablonfájlt közvetlenül is megadhatja a `$this->setLayout('/path/to/template.latte')` segítségével. -Az elrendezéssablon fájlnevét közvetlenül is megadhatja a `$this->setLayout('/path/to/template.latte')` segítségével. A `$this->setLayout(false)` használata letiltja az elrendezés keresését. +A `$this->setLayout(false)` vagy a `{layout none}` címke használata a sablonon belül kikapcsolja az elrendezéskeresést. .[note] -A [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] metódus felülbírálásával módosíthatja a sablonok keresési útvonalait, amely a lehetséges fájlútvonalak tömbjét adja vissza. +A fájlok, amelyekben az elrendezési sablonok keresése történik, megváltoztathatók a [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] metódus felülbírálásával, amely a lehetséges fájlnevek tömbjét adja vissza. Változók a sablonban .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ A `@property-read` annotáció az IDE és a statikus elemzés számára készül A sablonokban is megengedheted magadnak a suttogás luxusát, csak telepítsd a Latte plugint a PhpStormban, és add meg az osztály nevét a sablon elején, lásd a "Latte: hogyan kell tipizálni a rendszert":https://blog.nette.org/hu/latte-hogyan-kell-hasznalni-a-tipusrendszert című cikket: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void A Latte 3. verziója egy fejlettebb módszert kínál, amely minden egyes webes projekthez egy [bővítményt |latte:creating-extension] hoz létre. Íme egy durva példa egy ilyen osztályra: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ A [configuration |configuration#Latte] segítségével regisztráljuk: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/it/how-it-works.texy b/application/it/how-it-works.texy index 91e4f4e5ef..3222b1f408 100644 --- a/application/it/how-it-works.texy +++ b/application/it/how-it-works.texy @@ -22,13 +22,13 @@ La struttura delle directory è simile a questa: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← classi di base necessarie +│ │ └── RouterFactory.php ← configurazione degli indirizzi URL +│ ├── UI/ ← presenter, template & co. +│ │ ├── @layout.latte ← modello di layout condiviso +│ │ └── Home/ ← cartella del presentatore Home +│ │ ├── HomePresenter.php ← Classe del presentatore della casa +│ │ └── default.latte ← template per l'azione default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ Le applicazioni scritte in Nette sono suddivise in molti cosiddetti presenter (i L'applicazione inizia chiedendo al cosiddetto router di decidere a quale dei presenter passare la richiesta corrente per l'elaborazione. Il router decide di chi è la responsabilità. Osserva l'URL di ingresso `https://example.com/product/123`, che vuole `show` un prodotto con `id: 123` come azione. È buona abitudine scrivere le coppie presentatore + azione separate da due punti come `Product:show`. -Quindi il router ha trasformato l'URL in una coppia `Presenter:action` + parametri, nel nostro caso `Product:show` + `id: 123`. Si può vedere l'aspetto di un router nel file `app/Router/RouterFactory.php` e lo descriveremo in dettaglio nel capitolo [Routing |Routing]. +Quindi il router ha trasformato l'URL in una coppia `Presenter:action` + parametri, nel nostro caso `Product:show` + `id: 123`. Si può vedere l'aspetto di un router nel file `app/Core/RouterFactory.php` e lo descriveremo in dettaglio nel capitolo [Routing |Routing]. Andiamo avanti. L'applicazione conosce già il nome del presentatore e può continuare. Creando un oggetto `ProductPresenter`, che è il codice del presentatore `Product`. Più precisamente, chiede al contenitore DI di creare il presentatore, perché produrre oggetti è il suo lavoro. @@ -121,12 +121,9 @@ Quindi, è stato chiamato il metodo `renderShow(123)`, il cui codice è un esemp Successivamente, il presentatore restituisce la risposta. Questa può essere una pagina HTML, un'immagine, un documento XML, l'invio di un file dal disco, JSON o il reindirizzamento a un'altra pagina. È importante notare che, se non si dice esplicitamente come rispondere (come nel caso di `ProductPresenter`), la risposta sarà il rendering del modello con una pagina HTML. Perché? Perché nel 99% dei casi vogliamo disegnare un modello, quindi il presentatore prende questo comportamento come predefinito e vuole semplificarci il lavoro. Questo è il punto di Nette. -Non dobbiamo nemmeno dichiarare quale modello disegnare, lui ricava il percorso per raggiungerlo secondo una semplice logica. Nel caso del presenter `Product` e dell'azione `show`, cerca di vedere se esiste uno di questi file di template relativi alla directory in cui si trova la classe `ProductPresenter`: +Non è nemmeno necessario specificare quale template rendere; il framework dedurrà da solo il percorso. Nel caso dell'azione `show`, cerca semplicemente di caricare il template `show.latte` nella cartella con la classe `ProductPresenter`. Cerca anche di trovare il layout nel file `@layout.latte` (maggiori informazioni sulla [ricerca dei template |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Cercherà anche di trovare il layout nel file `@layout.latte` e quindi eseguirà il rendering del modello. Ora il compito del presentatore e dell'intera applicazione è completato. Se il modello non esiste, verrà restituita una pagina con errore 404. Per saperne di più sui presentatori, consultare la pagina [Presentatori |Presenters]. +Successivamente, i modelli vengono renderizzati. Questo completa il compito del presentatore e dell'intera applicazione e il lavoro è terminato. Se il modello non esistesse, verrebbe restituita una pagina di errore 404. Per saperne di più sui presentatori, consultare la pagina [Presentatori |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Per sicurezza, proviamo a riepilogare l'intero processo con un URL leggermente d 3) il router decodifica l'URL come una coppia di oggetti `Home:default` 4) viene creato un oggetto `HomePresenter` 5) viene richiamato il metodo `renderDefault()` (se esiste) -6) viene reso un modello `templates/Home/default.latte` con un layout `templates/@layout.latte` +6) viene reso un modello `default.latte` con un layout `@layout.latte` Potreste esservi imbattuti in molti concetti nuovi, ma crediamo che abbiano un senso. Creare applicazioni in Nette è un gioco da ragazzi. diff --git a/application/it/modules.texy b/application/it/modules.texy index 76b8af4e23..4a4e9c1539 100644 --- a/application/it/modules.texy +++ b/application/it/modules.texy @@ -2,29 +2,31 @@ Moduli ****** .[perex] -In Nette, i moduli rappresentano le unità logiche che compongono un'applicazione. Comprendono presentatori, modelli, eventualmente anche componenti e classi di modelli. +I moduli conferiscono chiarezza alle applicazioni Nette, facilitando la suddivisione in unità logiche. -Una cartella per i presentatori e una per i modelli non sarebbe sufficiente per i progetti reali. Avere decine di file in una cartella è quantomeno disorganizzato. Come uscirne? Semplicemente dividendoli in sottodirectory su disco e in spazi dei nomi nel codice. E questo è esattamente ciò che fanno i moduli Nette. - -Dimentichiamo quindi un'unica cartella per i presentatori e i modelli e creiamo invece dei moduli, ad esempio `Admin` e `Front`. +Analogamente all'organizzazione dei file in cartelle su un disco rigido, in Nette possiamo dividere presentatori, modelli e altre classi ausiliarie in moduli. Come funziona in pratica? Semplicemente incorporando nuove sottodirectory nella struttura. Ecco un esempio di struttura con due moduli, Front e Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Questa struttura di cartelle si rifletterà negli spazi dei nomi delle classi, quindi ad esempio `DashboardPresenter` sarà nello spazio dei nomi `App\Modules\Admin\Presenters`: +Questa struttura di directory si riflette negli spazi dei nomi delle classi, per cui, ad esempio, `DashboardPresenter` si trova nello spazio dei nomi `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Il presentatore `Dashboard` all'interno del modulo `Admin` è referenziato all'interno dell'applicazione usando la notazione dei due punti come `Admin:Dashboard`, e la sua azione `default` come `Admin:Dashboard:default`. -E come fa Nette a sapere che `Admin:Dashboard` rappresenta la classe `App\Modules\Admin\Presenters\DashboardPresenter`? Questo è determinato dalla [mappatura |#mapping] nella configurazione. -Pertanto, la struttura data non è rigida e può essere modificata in base alle proprie esigenze. +Nell'applicazione, ci si riferisce al presentatore `Dashboard` all'interno del modulo `Admin` usando la notazione dei due punti come `Admin:Dashboard`. Per l'azione `default`, ci si riferisce ad essa come `Admin:Dashboard:default`. -I moduli possono naturalmente contenere tutti gli altri elementi oltre ai presentatori e ai modelli, come componenti, classi di modelli, ecc. +La struttura presentata non è rigida; è possibile [personalizzarla completamente in base alle proprie esigenze |#mapping] nella configurazione. .[tip] + +I moduli possono includere tutti gli altri file, come i componenti e le classi ausiliarie, oltre ai presentatori e ai modelli. Se si sta valutando dove collocare questi ultimi, si può prendere in considerazione l'uso di una cartella `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Moduli annidati .[#toc-nested-modules] -------------------------------------- -I moduli non devono formare solo una struttura piatta, ma si possono anche creare sottomoduli, ad esempio: +I moduli possono avere più livelli di annidamento, simili a una struttura di directory su disco: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Così, il modulo `Blog` è suddiviso nei sottomoduli `Admin` e `Front`. Anche in questo caso, ciò si rifletterà negli spazi dei nomi, che saranno `App\Modules\Blog\Admin\Presenters` e così via. Il presentatore `Dashboard` all'interno del sottomodulo viene chiamato `Blog:Admin:Dashboard`. +Il modulo `Blog` è diviso nei sottomoduli `Admin` e `Front`. Questo si riflette anche negli spazi dei nomi, che appaiono come `App\UI\Blog\Admin` e simili. Per riferirsi al presentatore `Dashboard` all'interno del sottomodulo `Admin`, ci si riferisce ad esso come `Blog:Admin:Dashboard`. -L'annidamento può andare in profondità quanto si vuole, quindi si possono creare dei sottomoduli. +L'annidamento può essere profondo quanto necessario, consentendo la creazione di sottomoduli. + +Ad esempio, se nell'amministrazione sono presenti molti presentatori relativi alla gestione degli ordini, come `OrderDetail`, `OrderEdit`, `OrderDispatch`, ecc. si può creare un modulo `Order` in cui saranno organizzati presentatori come `Detail`, `Edit`, `Dispatch`, e altri. Creazione di collegamenti .[#toc-creating-links] @@ -102,46 +118,66 @@ Vedere il [capitolo sull'instradamento |routing#Modules]. Mappatura .[#toc-mapping] ------------------------- -Definisce le regole con cui il nome della classe viene derivato dal nome del presentatore. Vengono scritte nella [configurazione |configuration] sotto la chiave `application › mapping`. +La mappatura definisce le regole per derivare il nome della classe dal nome del presentatore. Queste regole sono specificate nella [configurazione |configuration] sotto la chiave `application › mapping`. + +Le strutture di directory menzionate in precedenza in questa pagina si basano sulla seguente mappatura: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Cominciamo con un esempio che non usa moduli. Vogliamo solo che le classi del presentatore abbiano lo spazio dei nomi `App\Presenters`. Ciò significa che un presentatore come `Home` deve mappare alla classe `App\Presenters\HomePresenter`. Questo si può ottenere con la seguente configurazione: +Come funziona la mappatura? Per capire meglio, immaginiamo prima un'applicazione senza moduli. Vogliamo che le classi del presentatore rientrino nello spazio dei nomi `App\UI`, in modo che il presentatore `Home` sia mappato nella classe `App\UI\HomePresenter`. Ciò può essere ottenuto con questa configurazione: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Il nome del presentatore viene sostituito con l'asterisco nella maschera della classe e il risultato è il nome della classe. Facile! +Questa mappatura funziona sostituendo l'asterisco nella maschera `App\UI\*Presenter` con il nome del presenter `Home`, ottenendo il nome finale della classe `App\UI\HomePresenter`. Semplice! + +Tuttavia, come si può vedere negli esempi di questo e di altri capitoli, le classi dei presentatori sono collocate in sottodirectory eponime, ad esempio il presentatore `Home` è mappato nella classe `App\UI\Home\HomePresenter`. Questo si ottiene raddoppiando l'asterisco (richiede Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Se dividiamo i presentatori in moduli, possiamo avere la nostra mappatura per ogni modulo: +Passiamo ora alla mappatura dei presentatori nei moduli. Possiamo definire mappature specifiche per ogni modulo: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Ora il presentatore `Front:Home` mappa alla classe `App\Modules\Front\Presenters\HomePresenter` e il presentatore `Admin:Dashboard` alla classe `App\Modules\Admin\Presenters\DashboardPresenter`. +In base a questa configurazione, il presentatore `Front:Home` si riferisce alla classe `App\UI\Front\Home\HomePresenter`, mentre il presentatore `Api:OAuth` si riferisce alla classe `App\Api\OAuthPresenter`. -È più pratico creare una regola generale (asterisco) per sostituire le prime due. L'asterisco in più sarà aggiunto alla maschera di classe solo per il modulo: +Poiché i moduli `Front` e `Admin` hanno un approccio di mappatura simile e probabilmente ci saranno altri moduli di questo tipo, è possibile creare una regola generale che li sostituisca. Un nuovo asterisco per il modulo viene aggiunto alla maschera della classe: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Ma cosa succede se utilizziamo moduli annidati e abbiamo un presentatore `Admin:User:Edit`? In questo caso, il segmento con l'asterisco che rappresenta il modulo per ogni livello viene semplicemente ripetuto e il risultato è la classe `App\Modules\Admin\User\Presenters\EditPresenter`. +Per i moduli annidati a più livelli, come il presentatore `Admin:User:Edit`, il segmento dell'asterisco si ripete per ogni livello, dando luogo alla classe `App\UI\Admin\User\Edit\EditPresenter`. Una notazione alternativa consiste nell'utilizzare un array composto da tre segmenti invece di una stringa. Questa notazione è equivalente alla precedente: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Il valore predefinito è `*Module\*Presenter`. +Se abbiamo una sola regola nella configurazione, quella generale, possiamo scrivere brevemente: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/it/templates.texy b/application/it/templates.texy index bb704a88f2..2d3412da33 100644 --- a/application/it/templates.texy +++ b/application/it/templates.texy @@ -34,35 +34,81 @@ E questo potrebbe essere il modello di azione: Definisce il blocco `content`, che viene inserito al posto di `{include content}` nel layout, e ridefinisce anche il blocco `title`, che sovrascrive `{block title}` nel layout. Provate a immaginare il risultato. -Ricerca dei modelli .[#toc-search-for-templates] ------------------------------------------------- +Ricerca di modelli .[#toc-template-lookup] +------------------------------------------ + +Nei presentatori, non è necessario specificare quale template debba essere reso; il framework determinerà automaticamente il percorso, semplificando la codifica. + +Se si utilizza una struttura di cartelle in cui ogni presentatore ha una propria cartella, è sufficiente posizionare il template in questa cartella sotto il nome dell'azione (cioè della vista). Ad esempio, per l'azione `default`, utilizzare il modello `default.latte`: -Il percorso dei modelli viene dedotto secondo una semplice logica. Si cerca di vedere se uno di questi file di template esiste relativamente alla directory in cui si trova la classe del presentatore, dove `` è il nome del presentatore corrente e `` è il nome dell'azione corrente: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Se si utilizza una struttura in cui i presentatori sono riuniti in una directory e i modelli in una cartella `templates`, salvare il tutto in un file `..latte` oppure `/.latte`: -Se il modello non viene trovato, si cercherà nella cartella `templates` a un livello superiore, cioè allo stesso livello della cartella con la classe del presentatore. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Se il modello non viene trovato nemmeno lì, la risposta è un [errore 404 |presenters#Error 404 etc.]. +La directory `templates` può anche essere collocata un livello più in alto, allo stesso livello della directory con le classi dei presentatori. -Si può anche cambiare la vista usando `$this->setView('otherView')`. Oppure, invece di cercare, specificare direttamente il nome del file del template usando `$this->template->setFile('/path/to/template.latte')`. +Se il modello non viene trovato, il presentatore risponde con un [errore 404 - pagina non trovata |presenters#Error 404 etc]. + +È possibile modificare la vista utilizzando `$this->setView('anotherView')`. È anche possibile specificare direttamente il file del modello con `$this->template->setFile('/path/to/template.latte')`. .[note] -È possibile modificare i percorsi in cui vengono cercati i modelli sovrascrivendo il metodo [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], che restituisce un array di possibili percorsi di file. +I file in cui vengono cercati i modelli possono essere modificati sovrascrivendo il metodo [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], che restituisce un array di possibili nomi di file. + + +Ricerca dei modelli di layout .[#toc-layout-template-lookup] +------------------------------------------------------------ + +Nette cerca automaticamente anche il file di layout. + +Se si utilizza una struttura di directory in cui ogni presentatore ha una propria directory, collocare il layout nella cartella del presentatore, se è specifico solo per lui, oppure a un livello superiore se è comune a più presentatori: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Se si utilizza una struttura in cui i presentatori sono raggruppati in una directory e i modelli si trovano in una cartella `templates`, il layout sarà previsto nei seguenti punti: -Il layout è previsto nei seguenti file: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` layout comune a più presentatori +Se il presentatore si trova in un [modulo |modules], cercherà anche più in alto nell'albero della directory, in base alla nidificazione del modulo. -`` è il nome del presentatore corrente e `` è il nome del layout, che per impostazione predefinita è `'layout'`. Il nome può essere modificato con `$this->setLayout('otherLayout')`, in modo da provare i file `@otherLayout.latte`. +Il nome del layout può essere modificato con `$this->setLayout('layoutAdmin')` e sarà previsto nel file `@layoutAdmin.latte`. È anche possibile specificare direttamente il file del modello di layout usando `$this->setLayout('/path/to/template.latte')`. -È anche possibile specificare direttamente il nome del file del modello di layout con `$this->setLayout('/path/to/template.latte')`. L'uso di `$this->setLayout(false)` disabilita la ricerca dei layout. +L'uso di `$this->setLayout(false)` o del tag `{layout none}` all'interno del template disabilita la ricerca del layout. .[note] -È possibile modificare i percorsi in cui vengono cercati i modelli sovrascrivendo il metodo [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], che restituisce un array di possibili percorsi di file. +I file in cui vengono cercati i modelli di layout possono essere modificati sovrascrivendo il metodo [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], che restituisce un array di possibili nomi di file. Variabili nel modello .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ L'annotazione `@property-read` è per l'IDE e l'analisi statica, farà funzionar Ci si può concedere il lusso di sussurrare anche nei template, basta installare il plugin Latte in PhpStorm e specificare il nome della classe all'inizio del template, si veda l'articolo "Latte: come digitare il sistema":https://blog.nette.org/it/latte-come-usare-il-sistema-di-tipi: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void La versione 3 di Latte offre un metodo più avanzato, creando un'[estensione |latte:creating-extension] per ogni progetto web. Ecco un esempio approssimativo di una classe di questo tipo: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ La registriamo usando [configuration |configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/pl/how-it-works.texy b/application/pl/how-it-works.texy index 9cbbb61f69..a2b0c8b57c 100644 --- a/application/pl/how-it-works.texy +++ b/application/pl/how-it-works.texy @@ -22,13 +22,13 @@ Struktura katalogów wygląda mniej więcej tak: /--pre web-project/ ├── app/ ← adresář s aplikací -│ ├── Presenters/ ← presentery a šablony -│ │ ├── HomePresenter.php ← třída presenteru Home -│ │ └── templates/ ← adresář se šablonami -│ │ ├── @layout.latte ← šablona layoutu -│ │ └── Home/ ← šablony presenteru Home -│ │ └── default.latte ← šablona akce 'default' -│ ├── Router/ ← konfigurace URL adres +│ ├── Core/ ← podstawowe niezbędne klasy +│ │ └── RouterFactory.php ← konfiguracja adresów URL +│ ├── UI/ ← prezentery, szablony & co. +│ │ ├── @layout.latte ← szablon udostępnionego layoutu +│ │ └── Home/ ← Katalog główny prezentera +│ │ ├── HomePresenter.php ← Klasa prezentera strony głównej +│ │ └── default.latte ← szablon dla akcji default │ └── Bootstrap.php ← zaváděcí třída Bootstrap ├── bin/ ← skripty spouštěné z příkazové řádky ├── config/ ← konfigurační soubory @@ -91,7 +91,7 @@ Aplikacje napisane w Nette są podzielone na wiele prezenterów (w innych framew Aplikacja rozpoczyna się od zapytania tzw. routera o decyzję, do którego prezentera przekazać bieżące żądanie do przetworzenia. Router decyduje o tym, czyja to odpowiedzialność. Patrzy na wejściowy URL `https://example.com/product/123`, którego poprosi o wyświetlenie (`show`) produktu z `id: 123` jako **akcji** . Dobrą praktyką jest zapisanie pary prezenter + akcja oddzielonej dwukropkiem jako `Product:show`. -W ten sposób router przekształca adres URL w parę `Presenter:action` + parametry, w naszym przypadku `Product:show` + `id: 123`. Jak wygląda taki router, można zobaczyć w pliku `app/Router/RouterFactory.php`, a szczegółowo opisujemy go w rozdziale [Routing |Routing]. +W ten sposób router przekształca adres URL w parę `Presenter:action` + parametry, w naszym przypadku `Product:show` + `id: 123`. Jak wygląda taki router, można zobaczyć w pliku `app/Core/RouterFactory.php`, a szczegółowo opisujemy go w rozdziale [Routing |Routing]. Ruszajmy dalej. Aplikacja zna teraz nazwę prezentera i może przejść dalej. Produkując obiekt klasy `ProductPresenter`, który jest kodem prezentera `Product`. Dokładniej, prosi kontener DI o wyprodukowanie prezentera, ponieważ jest tam, aby go wyprodukować. @@ -121,12 +121,9 @@ Wywołana jest więc metoda `renderShow(123)`, której kod jest fikcyjnym przyk Następnie prezenter zwraca odpowiedź. Może to być strona HTML, obraz, dokument XML, wysłanie pliku z dysku, JSON, a nawet przekierowanie na inną stronę. Co ważne, o ile nie powiemy wprost prezenterowi, jak ma odpowiedzieć (co ma miejsce w przypadku `ProductPresenter`), odpowiedzią będzie renderowanie szablonu ze stroną HTML. Dlaczego? Ponieważ w 99% przypadków chcemy renderować szablon, więc prezenter przyjmuje to zachowanie jako domyślne i chce ułatwić nam pracę. O to właśnie chodzi w Nette. -Nie musimy nawet określać, jaki szablon ma być renderowany, sam wywnioskuje ścieżkę do niego za pomocą prostej logiki. W przypadku prezentera `Product` i akcji `show`, spróbuje sprawdzić, czy istnieje jeden z tych plików szablonów przechowywanych względnie z katalogu klasy `ProductPresenter`: +Nie musimy nawet określać, który szablon ma być renderowany; framework sam wydedukuje ścieżkę. W przypadku akcji `show`, po prostu próbuje załadować szablon `show.latte` w katalogu z klasą `ProductPresenter`. Próbuje również znaleźć układ w pliku `@layout.latte` (więcej o [wyszukiwaniu szablonów |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Spróbuje również prześledzić układ w pliku `@layout.latte`, a następnie wyrenderować szablon. W ten sposób kończy się zadanie prezentera i aplikacji, a praca zostaje zakończona. Jeśli szablon nie istnieje, zwrócona zostanie strona błędu 404. Więcej o prezenterach można przeczytać na stronie [Prezenterzy |presenters]. +Następnie szablony są renderowane. To kończy zadanie prezentera i całej aplikacji, a praca jest wykonywana. Jeśli szablon nie istnieje, zostanie zwrócona strona błędu 404. Więcej informacji na temat prezenterów można znaleźć na stronie [Prezenterzy |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Aby być bezpiecznym, spróbujmy podsumować cały proces z nieco innym adresem 3) router dekoduje adres URL jako parę `Home:default` 4) tworzony jest obiekt klasy `HomePresenter` 5) wywoływana jest metoda `renderDefault()` (jeśli istnieje) -6) wyrenderować szablon np. `templates/Home/default.latte` z układem np. `templates/@layout.latte` +6) wyrenderować szablon np. `default.latte` z układem np. `@layout.latte` Teraz być może spotkałeś się z wieloma nowymi pojęciami, ale wierzymy, że mają one sens. Tworzenie aplikacji w Nette to ogromna bułka z masłem. diff --git a/application/pl/modules.texy b/application/pl/modules.texy index 488d8f50a3..ecca26c3dc 100644 --- a/application/pl/modules.texy +++ b/application/pl/modules.texy @@ -2,29 +2,31 @@ Moduły ****** .[perex] -W Nette moduły reprezentują logiczne jednostki, które tworzą aplikację. Należą do nich prezentery, szablony, ewentualnie komponenty i klasy modeli. +Moduły zapewniają przejrzystość aplikacji Nette, ułatwiając podział na logiczne jednostki. -Jeden komponent dla prezenterów i jeden dla szablonów nie wystarczyłby dla prawdziwych projektów. Posiadanie kilkudziesięciu plików w jednym folderze jest co najmniej niezorganizowane. Jak się z niego wydostać? Po prostu dzielimy je na podkatalogi na dysku i na przestrzenie nazw w kodzie. I właśnie to robią moduły Nette. - -Zapomnijmy więc o jednym folderze dla prezenterów i szablonów, a zamiast tego stwórzmy moduły, na przykład `Admin` i `Front`. +Podobnie jak w przypadku organizowania plików w foldery na dysku twardym, w Nette możemy podzielić prezenterów, szablony i inne klasy pomocnicze na moduły. Jak to działa w praktyce? Po prostu poprzez włączenie nowych podkatalogów do struktury. Oto przykład struktury z dwoma modułami, Front i Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← adresář s moduly -│ ├── Admin/ ← modul Admin -│ │ ├── Presenters/ ← jeho presentery -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← modul Front -│ └── Presenters/ ← jeho presentery -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Ta struktura katalogów będzie odzwierciedlona w przestrzeni nazw klas, więc na przykład `DashboardPresenter` będzie w przestrzeni `App\Modules\Admin\Presenters`: +Ta struktura katalogów jest odzwierciedlona w przestrzeniach nazw klas, więc na przykład `DashboardPresenter` znajduje się w przestrzeni nazw `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Prezenter `Dashboard` wewnątrz modułu `Admin` jest określany w aplikacji za pomocą notacji z podwójną kropką jako `Admin:Dashboard`, a jego działanie `default` jest określane jako `Admin:Dashboard:default`. -A skąd Nette own wie, że `Admin:Dashboard` reprezentuje klasę `App\Modules\Admin\Presenters\DashboardPresenter`? Mówimy to za pomocą [mapowania |#Mappings] w konfiguracji. -Tak więc podana struktura nie jest stała i można ją modyfikować według potrzeb. +W aplikacji odnosimy się do prezentera `Dashboard` w module `Admin` używając notacji dwukropka jako `Admin:Dashboard`. W przypadku akcji `default` odnosimy się do niej jako `Admin:Dashboard:default`. -Moduły mogą oczywiście zawierać wszystkie inne części oprócz prezenterów i szablonów, jak komponenty, klasy modeli itp. +Przedstawiona struktura nie jest sztywna; można [ją w pełni dostosować do własnych potrzeb |#mapping] w konfiguracji. .[tip] + +Moduły mogą zawierać wszystkie inne pliki, takie jak komponenty i klasy pomocnicze, oprócz prezenterów i szablonów. Jeśli zastanawiasz się, gdzie je umieścić, rozważ użycie folderu `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Moduły zagnieżdżone .[#toc-nested-modules] ------------------------------------------ -Moduły nie muszą tworzyć tylko płaskiej struktury, można też tworzyć np. submoduły: +Moduły mogą mieć wiele poziomów zagnieżdżenia, podobnie jak struktura katalogów na dysku: /--pre -app/ -├── Modules/ ← adresář s moduly -│ ├── Blog/ ← modul Blog -│ │ ├── Admin/ ← submodul Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodul Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← modul Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Tak więc moduł `Blog` jest podzielony na podmoduły `Admin` i `Front`. I znowu będzie to odzwierciedlone w przestrzeni nazw, która będzie `App\Modules\Blog\Admin\Presenters` itd. Prezenter `Dashboard` wewnątrz submodułu jest określany jako `Blog:Admin:Dashboard`. +Moduł `Blog` jest podzielony na podmoduły `Admin` i `Front`. Jest to również odzwierciedlone w przestrzeniach nazw, które następnie pojawiają się jako `App\UI\Blog\Admin` i podobnie. Aby odnieść się do prezentera `Dashboard` w podmodule `Admin`, odnosimy się do niego jako `Blog:Admin:Dashboard`. -Rozgałęzienie może iść tak głęboko, jak chcesz, więc możesz tworzyć podmoduły. +Zagnieżdżanie może być tak głębokie, jak potrzeba, umożliwiając tworzenie podmodułów. + +Na przykład, jeśli w administracji masz wiele prezenterów związanych z zarządzaniem zamówieniami, takich jak `OrderDetail`, `OrderEdit`, `OrderDispatch`, itp., możesz utworzyć moduł `Order`, w którym będą zorganizowane prezentery takie jak `Detail`, `Edit`, `Dispatch`, i inne. Tworzenie linków .[#toc-creating-links] @@ -102,46 +118,66 @@ Patrz [rozdział dotyczący routingu |routing#Modules]. Mapowanie .[#toc-mapping] ------------------------- -Określa zasady, według których nazwa klasy jest wyprowadzana z nazwy prezentera. Zapisujemy je w [konfiguracji |configuration] pod kluczem `application › mapping`. +Mapowanie definiuje zasady wyprowadzania nazwy klasy z nazwy prezentera. Reguły te są określone w [konfiguracji |configuration] pod kluczem `application › mapping`. + +Struktury katalogów wspomniane wcześniej na tej stronie są oparte na następującym mapowaniu: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Zacznijmy od próbki, która nie korzysta z modułów. Będziemy chcieli, aby klasy prezentera miały przestrzeń nazw `App\Presenters`. To znaczy, będziemy chcieli, aby prezenter, na przykład, `Home` mapował do klasy `App\Presenters\HomePresenter`. Można to osiągnąć dzięki następującej konfiguracji: +Jak działa mapowanie? Dla lepszego zrozumienia, wyobraźmy sobie najpierw aplikację bez modułów. Chcemy, aby klasy prezenterów należały do przestrzeni nazw `App\UI`, tak aby prezenter `Home` był mapowany na klasę `App\UI\HomePresenter`. Można to osiągnąć za pomocą tej konfiguracji: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Zastąp nazwę prezentera gwiazdką w masce klasy, a wynikiem będzie nazwa klasy. Spokojnie! +Mapowanie to polega na zastąpieniu gwiazdki w masce `App\UI\*Presenter` nazwą prezentera `Home`, co daje końcową nazwę klasy `App\UI\HomePresenter`. Proste! + +Jednakże, jak widać w przykładach w tym i innych rozdziałach, umieszczamy klasy prezenterów w podkatalogach o tej samej nazwie, np. prezenter `Home` jest mapowany na klasę `App\UI\Home\HomePresenter`. Osiąga się to poprzez podwojenie gwiazdki (wymaga Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Jeśli złamiemy prezenterów na moduły, możemy mieć niestandardowe mapowanie dla każdego modułu: +Przejdźmy teraz do mapowania prezenterów na moduły. Możemy zdefiniować konkretne mapowania dla każdego modułu: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Teraz prezenter `Front:Home` mapuje do klasy `App\Modules\Front\Presenters\HomePresenter`, a prezenter `Admin:Dashboard` mapuje do klasy `App\Modules\Admin\Presenters\DashboardPresenter`. +Zgodnie z tą konfiguracją, prezenter `Front:Home` mapuje się do klasy `App\UI\Front\Home\HomePresenter`, podczas gdy prezenter `Api:OAuth` mapuje się do klasy `App\Api\OAuthPresenter`. -Bardziej praktyczne będzie stworzenie ogólnej (gwiazdkowej) reguły, która zastąpi pierwsze dwie. W masce klasy zostanie dodana dodatkowa gwiazdka tylko dla tego modułu: +Ponieważ moduły `Front` i `Admin` mają podobne podejście do mapowania i prawdopodobnie będzie więcej takich modułów, możliwe jest utworzenie ogólnej reguły, która je zastąpi. Nowa gwiazdka dla modułu jest dodawana do maski klasy: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Ale co w przypadku, gdy korzystamy z wielu zagnieżdżonych modułów i mamy np. prezentera `Admin:User:Edit`? W takim przypadku segment z gwiazdką reprezentujący moduł dla każdego poziomu zostanie po prostu powtórzony, a wynikiem będzie klasa `App\Modules\Admin\User\Presenters\EditPresenter`. +W przypadku wielopoziomowych zagnieżdżonych modułów, takich jak prezenter `Admin:User:Edit`, segment gwiazdki powtarza się dla każdego poziomu, dając w rezultacie klasę `App\UI\Admin\User\Edit\EditPresenter`. -Alternatywną notacją jest użycie tablicy składającej się z trzech segmentów zamiast ciągu. Ta notacja jest równoważna z poprzednią: +Alternatywnym zapisem jest użycie tablicy złożonej z trzech segmentów zamiast łańcucha. Ta notacja jest równoważna poprzedniej: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Wartość domyślna to `*Module\*Presenter`. +Jeśli mamy tylko jedną regułę w konfiguracji, tę ogólną, możemy napisać krótko: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/pl/templates.texy b/application/pl/templates.texy index a7dd044914..cb89c8cf68 100644 --- a/application/pl/templates.texy +++ b/application/pl/templates.texy @@ -34,35 +34,81 @@ I to będzie szablon akcji: Definiuje blok `content`, który zostanie wstawiony w miejsce `{include content}` w układzie, a także redefiniuje blok `title`, który zastąpi `{block title}` w układzie. Spróbujcie sobie wyobrazić ten rezultat. -Wyszukiwanie szablonów .[#toc-search-for-templates] ---------------------------------------------------- +Wyszukiwanie szablonów .[#toc-template-lookup] +---------------------------------------------- -Ścieżka do szablonów jest wyprowadzana przez prezentera za pomocą prostej logiki. Spróbuje sprawdzić, czy jeden z tych plików znajduje się relatywnie od katalogu klasy prezentera, gdzie `` to nazwa aktualnego prezentera, a `` jest nazwą bieżącego zdarzenia: +W prezenterach nie trzeba określać, który szablon ma być renderowany; framework automatycznie określi ścieżkę, ułatwiając kodowanie. -- `templates//.latte` -- `templates/..latte` +Jeśli używasz struktury katalogów, w której każdy prezenter ma swój własny katalog, po prostu umieść szablon w tym katalogu pod nazwą akcji (tj. widoku). Na przykład dla akcji `default` należy użyć szablonu `default.latte`: -Jeśli szablon nie zostanie znaleziony, spróbuje poszukać w katalogu `templates` o jeden poziom wyżej, czyli na tym samym poziomie co katalog z klasą prezentera. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Jeśli tam również nie zostanie znaleziony szablon, odpowiedzią będzie [błąd 404 |presenters#Error 404 etc.]. +Jeśli używasz struktury, w której prezenterzy znajdują się w jednym katalogu, a szablony w folderze `templates`, zapisz je w pliku `..latte` lub `/.latte`: -Widok można również zmienić za pomocą strony `$this->setView('jineView')`. Lub, zamiast szukać bezpośrednio, określ nazwę pliku szablonu za pomocą `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +Katalog `templates` może być również umieszczony o jeden poziom wyżej, na tym samym poziomie co katalog z klasami prezenterów. + +Jeśli szablon nie zostanie znaleziony, prezenter odpowie [błędem 404 - nie znaleziono strony |presenters#Error 404 etc]. + +Widok można zmienić za pomocą `$this->setView('anotherView')`. Możliwe jest również bezpośrednie określenie pliku szablonu za pomocą `$this->template->setFile('/path/to/template.latte')`. .[note] -Pliki, w których wyszukiwane są szablony można zmienić nakładając na metodę [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], która zwraca tablicę możliwych nazw plików. +Pliki, w których wyszukiwane są szablony, można zmienić, nadpisując metodę [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], która zwraca tablicę możliwych nazw plików. + + +Wyszukiwanie szablonu układu .[#toc-layout-template-lookup] +----------------------------------------------------------- + +Nette automatycznie wyszukuje również plik układu. + +Jeśli używasz struktury katalogów, w której każdy prezenter ma swój własny katalog, umieść układ w folderze z prezenterem, jeśli jest on specyficzny tylko dla niego, lub poziom wyżej, jeśli jest wspólny dla wielu prezenterów: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Jeśli używasz struktury, w której prezenterzy są zgrupowani w jednym katalogu, a szablony znajdują się w folderze `templates`, layout będzie oczekiwany w następujących miejscach: -W tych plikach spodziewany jest układ: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` układ wspólny dla wielu prezenterów +Jeśli prezenter znajduje się w [module |modules], będzie on również wyszukiwany dalej w drzewie katalogów zgodnie z zagnieżdżeniem modułu. -Gdzie `` to nazwa aktualnego prezentera, a `` jest nazwą układu, którą domyślnie jest `'layout'`. Nazwę można zmienić za pomocą `$this->setLayout('jinyLayout')`, więc wypróbowane zostaną pliki `@jinyLayout.latte`. +Nazwę layoutu można zmienić za pomocą `$this->setLayout('layoutAdmin')`, a następnie będzie ona oczekiwana w pliku `@layoutAdmin.latte`. Można również bezpośrednio określić plik szablonu układu za pomocą `$this->setLayout('/path/to/template.latte')`. -Możesz również bezpośrednio określić nazwę pliku szablonu układu, używając `$this->setLayout('/path/to/template.latte')`. Użycie `$this->setLayout(false)` wyłączy śledzenie układu. +Użycie `$this->setLayout(false)` lub znacznika `{layout none}` wewnątrz szablonu wyłącza wyszukiwanie układu. .[note] -Pliki, w których wyszukiwane są szablony układów można zmienić nakładając na metodę [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], która zwraca tablicę możliwych nazw plików. +Pliki, w których przeszukiwane są szablony układu, można zmienić, nadpisując metodę [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], która zwraca tablicę możliwych nazw plików. Zmienne w szablonie .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ Adnotacja `@property-read` jest dla IDE i analizy statycznej, sprawi, że szepta Możesz również mieć luksus szeptania w szablonach, wystarczy zainstalować wtyczkę Latte w PhpStorm i umieścić nazwę klasy na początku szablonu, zobacz artykuł "Latte: jak wpisać system":https://blog.nette.org/pl/latte-jak-korzystac-z-systemu-typow, aby uzyskać więcej informacji: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte w wersji 3 oferuje bardziej zaawansowany sposób tworzenia [rozszerzenia |latte:creating-extension] dla każdego projektu internetowego. Oto krótki przykład takiej klasy: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Rejestrujemy go za pomocą [konfiguracji |configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/pt/how-it-works.texy b/application/pt/how-it-works.texy index a73637f71e..c55012ce62 100644 --- a/application/pt/how-it-works.texy +++ b/application/pt/how-it-works.texy @@ -22,13 +22,13 @@ A estrutura do diretório é algo parecido com isto: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← classes básicas necessárias +│ │ └── RouterFactory.php ← configuração de endereços URL +│ ├── UI/ ← apresentadores, modelos e outros +│ │ ├── @layout.latte ← modelo de layout compartilhado +│ │ └── Home/ ← Diretório do apresentador Home +│ │ ├── HomePresenter.php ← Classe do apresentador da página inicial +│ │ └── default.latte ← template for action default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ As aplicações escritas em Nette são divididas em muitos dos chamados apresent A aplicação começa pedindo ao chamado roteador que decida qual dos apresentadores deve passar o atual pedido de processamento. O roteador decide de quem é a responsabilidade. Ele analisa a URL de entrada `https://example.com/product/123`, que quer `show` um produto com `id: 123` como uma ação. É um bom hábito escrever um par de apresentador + ação separado por dois pontos como `Product:show`. -Assim, o roteador transformou a URL em um par `Presenter:action` + parâmetros, em nosso caso `Product:show` + `id: 123`. Você pode ver como é um roteador no arquivo `app/Router/RouterFactory.php` e nós o descreveremos em detalhes no capítulo [Roteamento |Routing]. +Assim, o roteador transformou a URL em um par `Presenter:action` + parâmetros, em nosso caso `Product:show` + `id: 123`. Você pode ver como é um roteador no arquivo `app/Core/RouterFactory.php` e nós o descreveremos em detalhes no capítulo [Roteamento |Routing]. Vamos em frente. O pedido já conhece o nome do apresentador e pode continuar. Ao criar um objeto `ProductPresenter`, que é o código do apresentador `Product`. Mais precisamente, pede ao contêiner DI para criar o apresentador, pois a produção de objetos é sua função. @@ -121,12 +121,9 @@ Então, o método `renderShow(123)` foi chamado, cujo código é um exemplo fict Posteriormente, o apresentador retorna a resposta. Pode ser uma página HTML, uma imagem, um documento XML, o envio de um arquivo do disco, JSON ou o redirecionamento para outra página. É importante ressaltar que se não dissermos explicitamente como responder (que é o caso de `ProductPresenter`), a resposta será renderizar o template com uma página HTML. Por quê? Bem, porque em 99% dos casos queremos desenhar um template, então o apresentador toma este comportamento como padrão e quer tornar nosso trabalho mais fácil. Esse é o ponto de vista da Nette. -Não temos nem mesmo que declarar qual modelo desenhar, ele deriva o caminho para ele de acordo com uma lógica simples. No caso do apresentador `Product` e da ação `show`, ele tenta ver se um destes arquivos de modelo existe em relação ao diretório onde se encontra a classe `ProductPresenter`: +Não precisamos nem mesmo especificar o modelo a ser renderizado; a estrutura deduzirá o caminho por si só. No caso da ação `show`, ele simplesmente tenta carregar o modelo `show.latte` no diretório com a classe `ProductPresenter`. Ele também tenta encontrar o layout no arquivo `@layout.latte` (mais informações sobre a [pesquisa de modelos |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Ele também tentará encontrar o layout no arquivo `@layout.latte` e depois renderiza o modelo. Agora a tarefa do apresentador e de todo o pedido está concluída. Se o modelo não existir, uma página com erro 404 será devolvida. Você pode ler mais sobre os apresentadores na página [Apresentadores |Presenters]. +Em seguida, os modelos são renderizados. Isso conclui a tarefa do apresentador e de todo o aplicativo, e o trabalho está concluído. Se o modelo não existir, será retornada uma página de erro 404. Você pode ler mais sobre apresentadores na página [Apresentadores |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Só para ter certeza, vamos tentar recapitular todo o processo com uma URL ligei 3) o roteador decodifica a URL como um par `Home:default` 4) um objeto `HomePresenter` é criado 5) método `renderDefault()` é chamado (se existir) -6) um modelo `templates/Home/default.latte` com um layout `templates/@layout.latte` é apresentado +6) um modelo `default.latte` com um layout `@layout.latte` é apresentado Você pode ter se deparado com muitos conceitos novos agora, mas acreditamos que eles fazem sentido. Criar aplicações em Nette é uma brisa. diff --git a/application/pt/modules.texy b/application/pt/modules.texy index 372dd0e467..a2e02d0257 100644 --- a/application/pt/modules.texy +++ b/application/pt/modules.texy @@ -2,29 +2,31 @@ Módulos ******* .[perex] -Em Nette, os módulos representam as unidades lógicas que compõem uma aplicação. Eles incluem apresentadores, gabaritos, possivelmente também componentes e classes de modelos. +Os módulos dão clareza aos aplicativos Nette, facilitando a divisão em unidades lógicas. -Um diretório para apresentadores e um para modelos não seria suficiente para projetos reais. Ter dezenas de arquivos em uma pasta é pelo menos desorganizado. Como sair dela? Nós simplesmente os dividimos em subdiretórios em disco e em namespaces no código. E é exatamente isso que os módulos Nette fazem. - -Portanto, vamos esquecer uma única pasta para apresentadores e modelos e, em vez disso, criar módulos, por exemplo `Admin` e `Front`. +Da mesma forma que organizamos os arquivos em pastas em um disco rígido, na Nette podemos dividir apresentadores, modelos e outras classes auxiliares em módulos. Como isso funciona na prática? Simplesmente incorporando novos subdiretórios à estrutura. Aqui está um exemplo de uma estrutura com dois módulos, Front e Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Esta estrutura de diretório será refletida pelos namespaces de classe, portanto, por exemplo `DashboardPresenter` estará no namespace `App\Modules\Admin\Presenters`: +Essa estrutura de diretórios é refletida nos namespaces das classes, portanto, por exemplo, `DashboardPresenter` está localizado no namespace `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -O `Dashboard` apresentador dentro do módulo `Admin` é referenciado dentro da aplicação usando a notação de cólon como `Admin:Dashboard`, e sua ação `default` como `Admin:Dashboard:default`. -E como a Nette propriamente dita sabe que `Admin:Dashboard` representa a classe `App\Modules\Admin\Presenters\DashboardPresenter`? Isto é determinado pelo [mapeamento |#mapping] na configuração. -Assim, a estrutura dada não é difícil de definir e você pode modificá-la de acordo com suas necessidades. +No aplicativo, nos referimos ao apresentador `Dashboard` dentro do módulo `Admin` usando a notação de dois pontos como `Admin:Dashboard`. Para sua ação `default`, nos referimos a ela como `Admin:Dashboard:default`. -Os módulos podem naturalmente conter todos os outros itens além de apresentadores e modelos, tais como componentes, classes de modelos, etc. +A estrutura apresentada não é rígida; você pode [personalizá-la totalmente de acordo com suas necessidades |#mapping] na configuração. .[tip] + +Os módulos podem incluir todos os outros arquivos, como componentes e classes auxiliares, além de apresentadores e modelos. Se estiver pensando em onde colocá-los, considere o uso de uma pasta `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Módulos aninhados .[#toc-nested-modules] ---------------------------------------- -Os módulos não precisam formar apenas uma estrutura plana, você também pode criar submódulos, por exemplo: +Os módulos podem ter vários níveis de aninhamento, semelhante a uma estrutura de diretórios em um disco: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Assim, o módulo `Blog` está dividido em `Admin` e `Front` submódulos. Mais uma vez, isto se refletirá nos namespaces, que serão `App\Modules\Blog\Admin\Presenters` etc. O apresentador `Dashboard` dentro do submódulo é referido como `Blog:Admin:Dashboard`. +O módulo `Blog` é dividido em submódulos `Admin` e `Front`. Isso também se reflete nos namespaces, que aparecem como `App\UI\Blog\Admin` e similares. Para nos referirmos ao apresentador `Dashboard` dentro do submódulo `Admin`, nos referimos a ele como `Blog:Admin:Dashboard`. -O ninho pode ir tão fundo quanto você desejar, de modo que sub-submódulos podem ser criados. +O aninhamento pode ser tão profundo quanto necessário, permitindo a criação de sub-submódulos. + +Por exemplo, se na administração você tem muitos apresentadores relacionados ao gerenciamento de pedidos, como `OrderDetail`, `OrderEdit`, `OrderDispatch`, etc., você pode criar um módulo `Order` no qual apresentadores como `Detail`, `Edit`, `Dispatch` e outros serão organizados. Criação de links .[#toc-creating-links] @@ -102,46 +118,66 @@ Ver [capítulo sobre roteamento |routing#Modules]. Mapeamento .[#toc-mapping] -------------------------- -Define as regras pelas quais o nome da classe é derivado do nome do apresentador. Nós as escrevemos na [configuração |configuration] sob a chave `application › mapping`. +O mapeamento define as regras para derivar o nome da classe do nome do apresentador. Essas regras são especificadas na [configuração |configuration] sob a chave `application › mapping`. + +As estruturas de diretório mencionadas anteriormente nesta página são baseadas no seguinte mapeamento: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Vamos começar com uma amostra que não utiliza módulos. Queremos apenas que as classes de apresentadores tenham o namespace `App\Presenters`. Isso significa que um apresentador como o `Home` deve mapear para a classe `App\Presenters\HomePresenter`. Isto pode ser conseguido através da seguinte configuração: +Como funciona o mapeamento? Para entender melhor, vamos primeiro imaginar um aplicativo sem módulos. Queremos que as classes do apresentador se enquadrem no namespace `App\UI`, de modo que o apresentador `Home` mapeie para a classe `App\UI\HomePresenter`. Isso pode ser obtido com esta configuração: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -O nome do apresentador é substituído pelo asterisco na máscara da classe e o resultado é o nome da classe. Fácil! +Esse mapeamento funciona substituindo o asterisco na máscara `App\UI\*Presenter` pelo nome do apresentador `Home`, resultando no nome final da classe `App\UI\HomePresenter`. Simples! + +Entretanto, como você pode ver nos exemplos deste e de outros capítulos, colocamos as classes de apresentador em subdiretórios homônimos, por exemplo, o apresentador `Home` é mapeado para a classe `App\UI\Home\HomePresenter`. Isso é feito duplicando-se o asterisco (requer o Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Se dividirmos os apresentadores em módulos, podemos ter nosso próprio mapeamento para cada módulo: +Agora, vamos passar a mapear os apresentadores em módulos. Podemos definir mapeamentos específicos para cada módulo: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Agora o apresentador `Front:Home` mapeia para a classe `App\Modules\Front\Presenters\HomePresenter` e o apresentador `Admin:Dashboard` para a classe `App\Modules\Admin\Presenters\DashboardPresenter`. +De acordo com essa configuração, o apresentador `Front:Home` mapeia para a classe `App\UI\Front\Home\HomePresenter`, enquanto o apresentador `Api:OAuth` mapeia para a classe `App\Api\OAuthPresenter`. -É mais prático criar uma regra geral (estrela) para substituir as duas primeiras. O asterisco extra será adicionado à máscara de classe apenas para o módulo: +Como os módulos `Front` e `Admin` têm uma abordagem de mapeamento semelhante e é provável que haja mais módulos desse tipo, é possível criar uma regra geral que os substitua. Um novo asterisco para o módulo é adicionado à máscara de classe: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Mas e se usarmos módulos aninhados e tivermos um apresentador `Admin:User:Edit`? Neste caso, o segmento com um asterisco representando o módulo para cada nível é simplesmente repetido e o resultado é a classe `App\Modules\Admin\User\Presenters\EditPresenter`. +Para módulos aninhados em vários níveis, como o apresentador `Admin:User:Edit`, o segmento de asterisco se repete para cada nível, resultando na classe `App\UI\Admin\User\Edit\EditPresenter`. -Uma notação alternativa é utilizar um conjunto composto de três segmentos em vez de um fio. Esta notação é equivalente à anterior: +Uma notação alternativa é usar uma matriz composta de três segmentos em vez de uma cadeia de caracteres. Essa notação é equivalente à anterior: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -O valor padrão é `*Module\*Presenter`. +Se tivermos apenas uma regra na configuração, a geral, podemos escrever de forma resumida: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/pt/templates.texy b/application/pt/templates.texy index 059e35178e..75e73e1d98 100644 --- a/application/pt/templates.texy +++ b/application/pt/templates.texy @@ -34,35 +34,81 @@ E este poderia ser o modelo de ação: Ele define o bloco `content`, que é inserido no lugar de `{include content}` no layout, e também redefine o bloco `title`, que sobrescreve `{block title}` no layout. Tente imaginar o resultado. -Busca de modelos .[#toc-search-for-templates] ---------------------------------------------- +Pesquisa de modelos .[#toc-template-lookup] +------------------------------------------- -O caminho para os modelos é deduzido de acordo com uma lógica simples. Ele tenta ver se um destes arquivos de gabaritos existe em relação ao diretório onde se encontra a classe apresentadora, onde `` é o nome do atual apresentador e `` é o nome da ação atual: +Nos apresentadores, você não precisa especificar qual modelo deve ser renderizado; a estrutura determinará automaticamente o caminho, facilitando a codificação para você. -- `templates//.latte` -- `templates/..latte` +Se você usar uma estrutura de diretórios em que cada apresentador tenha seu próprio diretório, basta colocar o modelo nesse diretório com o nome da ação (ou seja, visualização). Por exemplo, para a ação `default`, use o modelo `default.latte`: -Se o modelo não for encontrado, ele tentará procurar no diretório `templates` um nível acima, ou seja, no mesmo nível que o diretório com a classe apresentadora. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Se o modelo também não for encontrado lá, a resposta é um [erro 404 |presenters#Error 404 etc.]. +Se você usar uma estrutura em que os apresentadores estejam juntos em um diretório e os modelos em uma pasta `templates`, salve-os em um arquivo `..latte` ou `/.latte`: -Você também pode mudar a visão usando `$this->setView('otherView')`. Ou, em vez de procurar, especifique diretamente o nome do arquivo modelo usando `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +O diretório `templates` também pode ser colocado um nível acima, no mesmo nível do diretório com as classes de apresentador. + +Se o modelo não for encontrado, o apresentador responderá com o [erro 404 - página não encontrada |presenters#Error 404 etc]. + +Você pode alterar a visualização usando `$this->setView('anotherView')`. Também é possível especificar diretamente o arquivo de modelo com `$this->template->setFile('/path/to/template.latte')`. .[note] -Você pode alterar os caminhos onde os modelos são pesquisados substituindo o método de [formataçãoTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], que retorna um conjunto de possíveis caminhos de arquivos. +Os arquivos onde os modelos são pesquisados podem ser alterados substituindo o método [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], que retorna uma matriz de possíveis nomes de arquivos. + + +Pesquisa de modelos de layout .[#toc-layout-template-lookup] +------------------------------------------------------------ + +O Nette também procura automaticamente o arquivo de layout. + +Se você usar uma estrutura de diretórios em que cada apresentador tenha seu próprio diretório, coloque o layout na pasta com o apresentador, se for específico apenas para ele, ou em um nível superior, se for comum a vários apresentadores: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Se você usar uma estrutura em que os apresentadores estejam agrupados em um diretório e os modelos estejam em uma pasta `templates`, o layout será esperado nos seguintes locais: -O layout é esperado nos seguintes arquivos: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` layout comum a vários apresentadores +Se o apresentador estiver em um [módulo |modules], ele também pesquisará mais acima na árvore de diretórios, de acordo com o aninhamento do módulo. -`` é o nome do atual apresentador e `` é o nome do layout, que é, por padrão, `'layout'`. O nome pode ser alterado com `$this->setLayout('otherLayout')`, para que os arquivos `@otherLayout.latte` sejam experimentados. +O nome do layout pode ser alterado usando `$this->setLayout('layoutAdmin')` e, em seguida, ele será esperado no arquivo `@layoutAdmin.latte`. Você também pode especificar diretamente o arquivo de modelo de layout usando `$this->setLayout('/path/to/template.latte')`. -Você também pode especificar diretamente o nome do arquivo do modelo de layout usando `$this->setLayout('/path/to/template.latte')`. O uso do `$this->setLayout(false)` desabilitará a busca do layout. +O uso de `$this->setLayout(false)` ou da tag `{layout none}` dentro do modelo desativa a pesquisa de layout. .[note] -Você pode alterar os caminhos onde os modelos são pesquisados, substituindo o método [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], que retorna uma série de possíveis caminhos de arquivos. +Os arquivos em que os modelos de layout são pesquisados podem ser alterados substituindo o método [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], que retorna uma matriz de possíveis nomes de arquivos. Variáveis no modelo .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ A anotação `@property-read` é para IDE e análise estática, fará com que o Você também pode se dar ao luxo de sussurrar nos modelos, basta instalar o plugin Latte no PhpStorm e especificar o nome da classe no início do modelo, veja o artigo "Latte: como digitar sistema":https://blog.nette.org/pt/latte-como-usar-o-sistema-de-tipo: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void A versão 3 do Latte oferece uma maneira mais avançada, criando uma [extensão |latte:creating-extension] para cada projeto web. Aqui está um exemplo rudimentar de tal classe: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Registramos usando [a configuração#Latte |configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/ro/how-it-works.texy b/application/ro/how-it-works.texy index 75291693ee..c1cfda33f3 100644 --- a/application/ro/how-it-works.texy +++ b/application/ro/how-it-works.texy @@ -22,13 +22,13 @@ Structura directoarelor arată cam așa: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← cursuri de bază necesare +│ │ └── RouterFactory.php ← configurare adrese URL +│ ├── UI/ ← prezentări, șabloane & co. +│ │ ├── @layout.latte ← șablon de prezentare partajată +│ │ └── Home/ ← Directorul de prezentatori de acasă +│ │ ├── HomePresenter.php ← Clasa de prezentator de acasă +│ │ └── default.latte ← șablon pentru acțiune default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ Aplicațiile scrise în Nette sunt împărțite în mai multe așa-numite prezen Aplicația începe prin a cere așa-numitului router să decidă care dintre prezentatori să transmită cererea curentă pentru procesare. Routerul decide a cui este responsabilitatea. Acesta se uită la URL-ul de intrare `https://example.com/product/123`, care dorește să `show` un produs cu `id: 123` ca acțiune. Este un bun obicei să se scrie perechile prezentator + acțiune separate de două puncte ca `Product:show`. -Astfel, routerul a transformat URL-ul într-o pereche `Presenter:action` + parametri, în cazul nostru `Product:show` + `id: 123`. Puteți vedea cum arată un router în fișierul `app/Router/RouterFactory.php` și îl vom descrie în detaliu în capitolul [Routing |Routing]. +Astfel, routerul a transformat URL-ul într-o pereche `Presenter:action` + parametri, în cazul nostru `Product:show` + `id: 123`. Puteți vedea cum arată un router în fișierul `app/Core/RouterFactory.php` și îl vom descrie în detaliu în capitolul [Routing |Routing]. Să mergem mai departe. Aplicația cunoaște deja numele prezentatorului și poate continua. Prin crearea unui obiect `ProductPresenter`, care este codul prezentatorului `Product`. Mai exact, solicită containerului DI crearea prezentatorului, deoarece producerea de obiecte este sarcina acestuia. @@ -121,12 +121,9 @@ Așadar, a fost apelată metoda `renderShow(123)`, al cărei cod este un exemplu Ulterior, prezentatorul returnează răspunsul. Acesta poate fi o pagină HTML, o imagine, un document XML, trimiterea unui fișier de pe disc, JSON sau redirecționarea către o altă pagină. Este important de reținut că, dacă nu spunem în mod explicit cum să răspundem (ceea ce este cazul `ProductPresenter`), răspunsul va fi redarea șablonului cu o pagină HTML. De ce? Ei bine, pentru că în 99% din cazuri dorim să desenăm un șablon, așa că prezentatorul ia acest comportament ca fiind implicit și dorește să ne ușureze munca. Acesta este punctul de vedere al lui Nette. -Nici măcar nu trebuie să precizăm ce șablon să desenăm, el derivă calea către acesta conform unei logici simple. În cazul prezentatorului `Product` și al acțiunii `show`, el încearcă să vadă dacă unul dintre aceste fișiere șablon există în raport cu directorul în care se află clasa `ProductPresenter`: +Nici măcar nu trebuie să specificăm ce șablon să redăm; cadrul va deduce singur calea. În cazul acțiunii `show`, acesta încearcă pur și simplu să încarce șablonul `show.latte` din directorul cu clasa `ProductPresenter`. De asemenea, încearcă să găsească aspectul în fișierul `@layout.latte` (mai multe informații despre [căutarea șabloanelor |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -De asemenea, va încerca să găsească aspectul în fișierul `@layout.latte` și apoi va reda șablonul. Acum sarcina prezentatorului și a întregii aplicații este finalizată. În cazul în care șablonul nu există, va fi returnată o pagină cu eroarea 404. Puteți citi mai multe despre prezentatori pe pagina [Prezentatori |Presenters]. +Ulterior, șabloanele sunt redate. Acest lucru încheie sarcina prezentatorului și a întregii aplicații, iar activitatea este finalizată. În cazul în care șablonul nu există, ar fi returnată o pagină de eroare 404. Puteți citi mai multe despre prezentatori pe pagina [Prezentatori |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Doar pentru a fi siguri, să încercăm să recapitulăm întregul proces cu un 3) routerul decodifică URL-ul ca o pereche `Home:default` 4) este creat un obiect `HomePresenter` 5) se apelează metoda `renderDefault()` (dacă există) -6) este redat un șablon `templates/Home/default.latte` cu un layout `templates/@layout.latte` +6) este redat un șablon `default.latte` cu un layout `@layout.latte` Este posibil să fi întâlnit acum o mulțime de concepte noi, dar noi credem că acestea au sens. Crearea de aplicații în Nette este o joacă de copii. diff --git a/application/ro/modules.texy b/application/ro/modules.texy index 1e7cd0fee4..300b63f579 100644 --- a/application/ro/modules.texy +++ b/application/ro/modules.texy @@ -2,29 +2,31 @@ Module ****** .[perex] -În Nette, modulele reprezintă unitățile logice care alcătuiesc o aplicație. Acestea includ prezentatori, șabloane, eventual și componente și clase de model. +Modulele aduc claritate aplicațiilor Nette, facilitând divizarea ușoară în unități logice. -Un singur director pentru prezentatori și unul pentru șabloane nu ar fi suficient pentru proiectele reale. A avea zeci de fișiere într-un singur dosar este cel puțin neorganizat. Cum se poate ieși din asta? Pur și simplu le împărțim în subdirectoare pe disc și în spații de nume în cod. Și asta este exact ceea ce fac modulele Nette. - -Așadar, să uităm de un singur dosar pentru prezentatori și șabloane și să creăm în schimb module, de exemplu `Admin` și `Front`. +Similar cu organizarea fișierelor în foldere pe un hard disk, în Nette putem împărți în module prezentatorii, șabloanele și alte clase auxiliare. Cum funcționează acest lucru în practică? Pur și simplu prin încorporarea de noi subdirectoare în structură. Iată un exemplu de structură cu două module, Front și Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Această structură de directoare va fi reflectată de spațiile de nume ale claselor, astfel încât, de exemplu, `DashboardPresenter` va fi în spațiul de nume `App\Modules\Admin\Presenters`: +Această structură de directoare se reflectă în spațiile de nume ale claselor, astfel încât, de exemplu, `DashboardPresenter` se află în spațiul de nume `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Prezentatorul `Dashboard` din cadrul modulului `Admin` este referit în cadrul aplicației folosind notația de două puncte ca `Admin:Dashboard`, iar acțiunea `default` ca `Admin:Dashboard:default`. -Și de unde știe Nette proper că `Admin:Dashboard` reprezintă clasa `App\Modules\Admin\Presenters\DashboardPresenter`? Acest lucru este determinat de [cartografierea |#mapping] din configurație. -Așadar, structura dată nu este prestabilită și o puteți modifica în funcție de nevoile dumneavoastră. +În aplicație, ne referim la prezentatorul `Dashboard` din cadrul modulului `Admin` folosind notația două puncte ca `Admin:Dashboard`. Pentru acțiunea `default`, ne referim la acesta ca `Admin:Dashboard:default`. -Modulele pot conține, bineînțeles, toate celelalte elemente în afară de prezentatori și șabloane, cum ar fi componente, clase de modele etc. +Structura prezentată nu este rigidă; [o |#mapping] puteți [personaliza complet |#mapping] în funcție [de nevoile dumneavoastră |#mapping] în cadrul configurației. .[tip] + +Modulele pot include toate celelalte fișiere, cum ar fi componentele și clasele auxiliare, pe lângă prezentatori și șabloane. Dacă vă gândiți unde să le plasați pe acestea, luați în considerare utilizarea unui dosar `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Module imbricate .[#toc-nested-modules] --------------------------------------- -Modulele nu trebuie să formeze doar o structură plată, ci puteți crea și submodule, de exemplu: +Modulele pot avea mai multe niveluri de anvelopare, similar cu o structură de directoare pe un disc: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Astfel, modulul `Blog` este împărțit în submodulele `Admin` și `Front`. Din nou, acest lucru se va reflecta în spațiile de nume, care vor fi `App\Modules\Blog\Admin\Presenters` etc. Prezentatorul `Dashboard` din interiorul submodulului este denumit `Blog:Admin:Dashboard`. +Modulul `Blog` este împărțit în submodulele `Admin` și `Front`. Acest lucru se reflectă și în spațiile de nume, care apar apoi ca `App\UI\Blog\Admin` și similar. Pentru a ne referi la prezentatorul `Dashboard` din cadrul submodulului `Admin`, ne referim la acesta ca `Blog:Admin:Dashboard`. -Anveloparea poate merge cât de adânc doriți, astfel încât pot fi create sub-submodule. +Nesting-ul poate fi atât de adânc cât este necesar, permițând crearea de sub-submodule. + +De exemplu, dacă în administrație aveți mulți prezentatori legați de gestionarea comenzilor, cum ar fi `OrderDetail`, `OrderEdit`, , `OrderDispatch`, etc., puteți crea un modul `Order` în care vor fi organizați prezentatori precum `Detail`, `Edit`, `Dispatch`, și alții. Crearea de legături .[#toc-creating-links] @@ -102,46 +118,66 @@ A se vedea [capitolul privind rutarea |routing#Modules]. Cartografiere .[#toc-mapping] ----------------------------- -Definește regulile prin care numele clasei este derivat din numele prezentatorului. Le scriem în [configurație |configuration] sub cheia `application › mapping`. +Cartografierea definește regulile de derivare a numelui clasei din numele prezentatorului. Aceste reguli sunt specificate în [configurație |configuration] la cheia `application › mapping`. + +Structurile de directoare menționate anterior pe această pagină se bazează pe următoarea cartografiere: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Să începem cu un exemplu care nu folosește module. Vom dori doar ca clasele de prezentator să aibă spațiul de nume `App\Presenters`. Aceasta înseamnă că un prezentator precum `Home` ar trebui să se mapeze la clasa `App\Presenters\HomePresenter`. Acest lucru poate fi realizat prin următoarea configurație: +Cum funcționează cartografierea? Pentru o mai bună înțelegere, să ne imaginăm mai întâi o aplicație fără module. Dorim ca clasele de prezentatori să se încadreze în spațiul de nume `App\UI`, astfel încât prezentatorul `Home` să fie asociat cu clasa `App\UI\HomePresenter`. Acest lucru poate fi realizat cu această configurație: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Numele prezentatorului este înlocuit cu un asterisc în masca clasei, iar rezultatul este numele clasei. Ușor! +Această cartografiere funcționează prin înlocuirea asteriscului din masca `App\UI\*Presenter` cu numele prezentatorului `Home`, rezultând numele final al clasei `App\UI\HomePresenter`. Simplu! + +Cu toate acestea, după cum puteți vedea în exemplele din acest capitol și din alte capitole, plasăm clasele de prezentatori în subdirectoare eponime, de exemplu, prezentatorul `Home` este mapat în clasa `App\UI\Home\HomePresenter`. Acest lucru se realizează prin dublarea asteriscului (necesită Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Dacă împărțim prezentatorii în module, putem avea propria mapare pentru fiecare modul: +Acum, să trecem la maparea prezentatorilor în module. Putem defini mape specifice pentru fiecare modul: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Acum, prezentatorul `Front:Home` se referă la clasa `App\Modules\Front\Presenters\HomePresenter` și prezentatorul `Admin:Dashboard` la clasa `App\Modules\Admin\Presenters\DashboardPresenter`. +În conformitate cu această configurație, prezentatorul `Front:Home` se mapează la clasa `App\UI\Front\Home\HomePresenter`, în timp ce prezentatorul `Api:OAuth` se mapează la clasa `App\Api\OAuthPresenter`. -Este mai practic să creăm o regulă generală (stea) care să le înlocuiască pe primele două. Asteriscul suplimentar va fi adăugat la masca clasei doar pentru modul: +Deoarece modulele `Front` și `Admin` au o abordare similară de cartografiere și este posibil să existe mai multe astfel de module, este posibil să se creeze o regulă generală care să le înlocuiască. Un nou asterisc pentru modul este adăugat la masca clasei: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Dar ce se întâmplă dacă folosim module imbricate și avem un prezentator `Admin:User:Edit`? În acest caz, segmentul cu un asterisc care reprezintă modulul pentru fiecare nivel se repetă pur și simplu, iar rezultatul este clasa `App\Modules\Admin\User\Presenters\EditPresenter`. +Pentru modulele imbricate pe mai multe niveluri, cum ar fi prezentatorul `Admin:User:Edit`, segmentul de asterisc se repetă pentru fiecare nivel, rezultând clasa `App\UI\Admin\User\Edit\EditPresenter`. -O notație alternativă este utilizarea unui array format din trei segmente în loc de un șir de caractere. Această notație este echivalentă cu cea anterioară: +O notație alternativă constă în utilizarea unei matrice compuse din trei segmente în locul unui șir de caractere. Această notație este echivalentă cu cea anterioară: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Valoarea implicită este `*Module\*Presenter`. +Dacă avem doar o singură regulă în configurație, cea generală, putem scrie pe scurt: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/ro/templates.texy b/application/ro/templates.texy index abcead647e..a12657b6f9 100644 --- a/application/ro/templates.texy +++ b/application/ro/templates.texy @@ -34,35 +34,81 @@ Iar acesta ar putea fi șablonul de acțiune: Acesta definește blocul `content`, care este inserat în locul lui `{include content}` în machetă și, de asemenea, redefinește blocul `title`, care suprascrie `{block title}` în machetă. Încercați să vă imaginați rezultatul. -Căutați șabloane .[#toc-search-for-templates] ---------------------------------------------- +Căutarea șablonului .[#toc-template-lookup] +------------------------------------------- + +În prezentări, nu trebuie să specificați ce șablon trebuie redat; cadrul va determina automat calea, ceea ce vă ușurează codificarea. + +Dacă utilizați o structură de directoare în care fiecare prezentator are propriul director, plasați pur și simplu șablonul în acest director sub numele acțiunii (de exemplu, view). De exemplu, pentru acțiunea `default`, utilizați șablonul `default.latte`: -Calea către șabloane este dedusă conform unei logici simple. Se încearcă să se vadă dacă unul dintre aceste fișiere șablon există în raport cu directorul în care se află clasa presenter, unde `` este numele prezentatorului curent și `` este numele acțiunii curente: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Dacă utilizați o structură în care prezentatorii sunt împreună într-un singur director, iar șabloanele într-un dosar `templates`, salvați-l fie într-un fișier `..latte` sau `/.latte`: -Dacă șablonul nu este găsit, se va încerca căutarea în directorul `templates` cu un nivel mai sus, adică la același nivel cu directorul cu clasa de prezentator. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Dacă șablonul nu este găsit nici acolo, răspunsul este o [eroare 404 |presenters#Error 404 etc.]. +Directorul `templates` poate fi, de asemenea, plasat un nivel mai sus, la același nivel cu directorul cu clasele de prezentatori. -De asemenea, puteți schimba vizualizarea folosind `$this->setView('otherView')`. Sau, în loc să căutați, specificați direct numele fișierului șablon folosind `$this->template->setFile('/path/to/template.latte')`. +În cazul în care șablonul nu este găsit, prezentatorul răspunde cu [eroarea 404 - page not found |presenters#Error 404 etc]. + +Puteți schimba vizualizarea folosind `$this->setView('anotherView')`. De asemenea, este posibilă specificarea directă a fișierului șablon cu `$this->template->setFile('/path/to/template.latte')`. .[note] -Puteți modifica căile în care sunt căutate șabloanele prin suprascrierea metodei [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], care returnează o matrice de posibile căi de acces la fișiere. +Fișierele în care sunt căutate șabloanele pot fi modificate prin suprascrierea metodei [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], care returnează o matrice de nume de fișiere posibile. + + +Căutarea șabloanelor de prezentare .[#toc-layout-template-lookup] +----------------------------------------------------------------- + +De asemenea, Nette caută automat fișierul de machetare. + +Dacă folosiți o structură de directoare în care fiecare prezentator are propriul director, plasați macheta fie în folderul cu prezentatorul, dacă este specifică doar acestuia, fie la un nivel superior, dacă este comună mai multor prezentatori: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Dacă utilizați o structură în care prezentatorii sunt grupați într-un singur director, iar șabloanele se află într-un dosar `templates`, macheta va fi așteptată în următoarele locuri: -Prezentarea este așteptată în următoarele fișiere: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` aspect comun pentru mai mulți prezentatori +Dacă prezentatorul se află într-un [modul |modules], se va căuta și mai sus în arborele de directoare, în funcție de structura de anvelopare a modulului. -`` este numele prezentatorului curent și `` este numele structurii, care este în mod implicit `'layout'`. Numele poate fi schimbat cu `$this->setLayout('otherLayout')`, astfel încât să se încerce să se utilizeze fișierele `@otherLayout.latte`. +Numele prezentării poate fi schimbat folosind `$this->setLayout('layoutAdmin')` și apoi va fi așteptat în fișierul `@layoutAdmin.latte`. De asemenea, puteți specifica direct fișierul șablon de prezentare folosind `$this->setLayout('/path/to/template.latte')`. -De asemenea, puteți specifica direct numele de fișier al șablonului de machetă cu `$this->setLayout('/path/to/template.latte')`. Utilizarea `$this->setLayout(false)` va dezactiva căutarea de machete. +Utilizarea `$this->setLayout(false)` sau a etichetei `{layout none}` în interiorul șablonului dezactivează căutarea de layout. .[note] -Puteți modifica căile de căutare a șabloanelor prin suprascrierea metodei [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], care returnează o matrice de posibile căi de acces la fișiere. +Fișierele în care sunt căutate șabloanele de prezentare pot fi modificate prin suprascrierea metodei [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], care returnează o matrice de nume de fișiere posibile. Variabilele din șablon .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ Adnotarea `@property-read` este pentru IDE și analiza statică, va face ca auto Vă puteți permite și luxul de a șopti în șabloane, trebuie doar să instalați pluginul în PhpStorm și să specificați numele clasei la începutul șablonului, consultați articolul "Latte: cum se tastează sistemul":https://blog.nette.org/ro/latte-cum-se-utilizeaza-sistemul-de-tipuri: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte versiunea 3 oferă o metodă mai avansată prin crearea unei [extensii |latte:creating-extension] pentru fiecare proiect web. Iată un exemplu aproximativ al unei astfel de clase: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ O înregistrăm folosind [configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/ru/how-it-works.texy b/application/ru/how-it-works.texy index 39b20c686c..6e3908f7e0 100644 --- a/application/ru/how-it-works.texy +++ b/application/ru/how-it-works.texy @@ -22,13 +22,13 @@ /--pre web-project/ ├── app/ ← каталог с приложением -│ ├── Presenters/ ← классы презентеров -│ │ ├── HomePresenter.php ← Класс презентера главной страницы -│ │ └── templates/ ← директория шаблонов -│ │ ├── @layout.latte ← шаблон общего макета -│ │ └── Home/ ← шаблоны презентера главной страницы -│ │ └── default.latte ← шаблон действия `default` -│ ├── Router/ ← конфигурация URL-адресов +│ ├── Core/ ← основные необходимые классы +│ │ └── RouterFactory.php ← настройка URL-адресов +│ ├── UI/ ← презентаторы, шаблоны и др. +│ │ ├── @layout.latte ← шаблон общего макета +│ │ └── Home/ ← Главная директория ведущих +│ │ ├── HomePresenter.php ← Класс презентера дома +│ │ └── default.latte ← шаблон для действий default │ └── Bootstrap.php ← загрузочный класс Bootstrap ├── bin/ ← скрипты командной строки ├── config/ ← файлы конфигурации @@ -91,7 +91,7 @@ Nette — это наставник, который направляет вас Приложение начинает работу с того, что просит так называемый маршрутизатор решить, какому из презентеров передать текущий запрос на обработку. Маршрутизатор решает, чья это ответственность. Он просматривает входной URL `https://example.com/product/123` и, основываясь на том, как он настроен, решает, что это задание, например, для **презентера** `Product`, который хочет `показать` продукт с `id: 123` как действие. Хорошей привычкой является написание пар презентер + действие, разделенных двоеточием: `Продукт:показать`. -Поэтому маршрутизатор преобразовал URL в пару `Presenter:action` + параметры, в нашем случае `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Router/RouterFactory.php`, и мы подробно опишем его в главе [Маршрутизация |routing]. +Поэтому маршрутизатор преобразовал URL в пару `Presenter:action` + параметры, в нашем случае `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Core/RouterFactory.php`, и мы подробно опишем его в главе [Маршрутизация |routing]. Давайте двигаться дальше. Приложение уже знает имя презентера и может продолжить работу. Путем создания объекта `ProductPresenter`, который является кодом презентера `Product`. Точнее, он просит контейнер DI создать презентера, потому что создание объектов — это его работа. @@ -121,12 +121,9 @@ class ProductPresenter extends Nette\Application\UI\Presenter После этого презентер возвращает ответ. Это может быть HTML-страница, изображение, XML-документ, отправка файла с диска, JSON или перенаправление на другую страницу. Важно отметить, что если мы явно не указываем, как реагировать (что имеет место в случае с `ProductPresenter`), ответом будет отображение шаблона с HTML-страницей. Почему? Ну, потому что в 99% случаев мы хотим отобразить шаблон, поэтому презентер принимает такое поведение по умолчанию и хочет облегчить нашу работу. Это точка зрения Nette. -Нам даже не нужно указывать, какой шаблон нужно вывести, он сам выводит путь к нему в соответствии с простой логикой. В случае с презентером `Product` и действием `show`, он пытается проверить, существует ли один из этих файлов шаблонов относительно каталога, в котором находится класс `ProductPresenter`: +Нам даже не нужно указывать, какой шаблон рендерить, фреймворк сам определит путь. В случае с действием `show` он просто попытается загрузить шаблон `show.latte` в директории с классом `ProductPresenter`. Он также попытается найти макет в файле `@layout.latte` (подробнее о [поиске шаблонов |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -И затем он отображает шаблон. Теперь задача презентера и всего приложения выполнена. Если шаблон не существует, будет возвращена страница с ошибкой 404. Подробнее о презентерах вы можете прочитать на странице [Презентеры |presenters]. +Затем происходит рендеринг шаблонов. На этом задача ведущего и всего приложения завершена, и работа закончена. Если шаблон не существует, будет возвращена страница с ошибкой 404. Подробнее о презентерах можно прочитать на странице [Презентеры |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ class ProductPresenter extends Nette\Application\UI\Presenter 3) маршрутизатор декодирует URL как пару `Home:default` 4) создается объект `HomePresenter` 5) вызывается метод `renderDefault()` (если существует) -6) шаблон `templates/Home/default.latte` с макетом `templates/@layout.latte` отрисован +6) шаблон `default.latte` с макетом `@layout.latte` отрисован Возможно, сейчас вы столкнулись с множеством новых понятий, но мы считаем, что они имеют смысл. Создавать приложения в Nette — проще простого. diff --git a/application/ru/modules.texy b/application/ru/modules.texy index e7a6b8b277..8159f0a30d 100644 --- a/application/ru/modules.texy +++ b/application/ru/modules.texy @@ -2,29 +2,31 @@ ****** .[perex] -В Nette модули представляют собой логические единицы, из которых состоит приложение. Они включают ведущие, шаблоны, возможно, компоненты и классы моделей. +Модули вносят ясность в приложения Nette, облегчая разделение на логические блоки. -Одного компонента для презентаторов и одного для шаблонов будет недостаточно для реальных проектов. Наличие десятков файлов в одной папке по меньшей мере неорганизованно. Как выйти из этого положения? Мы просто разделяем их на подкаталоги на диске и на пространства имен в коде. И это именно то, что делают модули Nette. - -Поэтому давайте забудем о единой папке для ведущих и шаблонов и вместо этого создадим модули, например, `Admin` и `Front`. +Подобно организации файлов в папки на жестком диске, в Nette мы можем разделить презентаторы, шаблоны и другие вспомогательные классы на модули. Как это работает на практике? Просто путем включения в структуру новых подкаталогов. Вот пример структуры с двумя модулями - Front и Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← директория с модулями -│ ├── Admin/ ← модуль Admin -│ │ ├── Presenters/ ← его презентеры -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← модуль Front -│ └── Presenters/ ← его презентеры -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Эта структура каталогов будет отражена в пространствах имен классов, так, например, `DashboardPresenter` будет находиться в пространстве `App\Modules\Admin\Presenters`: +Эта структура каталогов отражается в пространствах имен классов, так, например, `DashboardPresenter` находится в пространстве имен `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Ведущий `Dashboard` внутри модуля `Admin` обозначается в приложении с помощью двойной точечной нотации как `Admin:Dashboard`, а его действие `default` обозначается как `Admin:Dashboard:default`. -А откуда Nette знает, что `Admin:Dashboard` представляет класс `App\Modules\Admin\Presenters\DashboardPresenter`? Мы говорим об этом, используя [отображение |#Mapping] в конфигурации. -Таким образом, приведенная структура не является фиксированной, и вы можете изменять ее по своему усмотрению. +В приложении мы ссылаемся на ведущего `Dashboard` в модуле `Admin` через двоеточие как `Admin:Dashboard`. Для его действия `default` мы ссылаемся на него как на `Admin:Dashboard:default`. -Модули, конечно, могут содержать все другие части, помимо презентаторов и шаблонов, такие как компоненты, классы моделей и т.д. +Представленная структура не является жесткой; вы можете [полностью настроить ее под свои нужды |#mapping] в конфигурации. .[tip] + +Модули могут включать в себя все остальные файлы, такие как компоненты и вспомогательные классы, в дополнение к ведущим и шаблонам. Если вы раздумываете над тем, где их разместить, рассмотрите возможность использования папки `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Вложенные модули .[#toc-nested-modules] --------------------------------------- -Модули не обязательно должны формировать только плоскую структуру, вы также можете создавать, например, подмодули: +Модули могут иметь несколько уровней вложенности, подобно структуре каталогов на диске: /--pre -app/ -├── Modules/ ← директория с модулями -│ ├── Blog/ ← модуль Blog -│ │ ├── Admin/ ← подмодуль Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← подмодуль Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← модуль Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Таким образом, модуль `Blog` разбивается на подмодули `Admin` и `Front`. И опять же это будет отражено в пространствах имен, которые будут `App\Modules\Blog\Admin\Presenters` и т.д. Ведущий `Dashboard` внутри подмодуля называется `Blog:Admin:Dashboard`. +Модуль `Blog` делится на подмодули `Admin` и `Front`. Это также отражено в пространствах имен, которые отображаются как `App\UI\Blog\Admin` и аналогично. Для обозначения ведущего `Dashboard` в подмодуле `Admin` мы обозначаем его как `Blog:Admin:Dashboard`. -Ветвление может быть настолько глубоким, насколько вы захотите, поэтому вы можете создавать подмодули. +Вложенность может быть настолько глубокой, насколько это необходимо, что позволяет создавать подмодули. + +Например, если в администрировании есть много ведущих, связанных с управлением заказами, таких как `OrderDetail`, `OrderEdit`, `OrderDispatch`, и т. д., можно создать модуль `Order`, в котором будут организованы ведущие `Detail`, `Edit`, `Dispatch`, и другие. Создание ссылок .[#toc-creating-links] @@ -102,46 +118,66 @@ class DashboardPresenter extends Nette\Application\UI\Presenter Составление карты .[#toc-mapping] --------------------------------- -Определяет правила, по которым имя класса выводится из имени ведущего. Мы записываем их в [конфигурацию |configuration] под ключом `application › mapping`. +Mapping определяет правила получения имени класса из имени ведущего. Эти правила задаются в [конфигурации |configuration] под ключом `application › mapping`. + +Структуры каталогов, упомянутые ранее на этой странице, основаны на следующем отображении: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Начнем с примера, в котором не используются модули. Мы просто хотим, чтобы классы ведущего имели пространство имен `App\Presenters`. То есть мы хотим, чтобы ведущий, например, `Home` отображался на класс `App\Presenters\HomePresenter`. Этого можно достичь с помощью следующей конфигурации: +Как работает отображение? Для лучшего понимания давайте сначала представим себе приложение без модулей. Мы хотим, чтобы классы ведущих относились к пространству имен `App\UI`, так что ведущий `Home` отображается на класс `App\UI\HomePresenter`. Этого можно добиться с помощью следующей конфигурации: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Имя презентера заменяется звездочкой, и в результате получается название класса. Легко! +Это сопоставление работает путем замены звездочки в маске `App\UI\*Presenter` на имя ведущего `Home`, в результате чего мы получаем конечное имя класса `App\UI\HomePresenter`. Просто! + +Однако, как вы можете видеть в примерах этой и других глав, мы размещаем классы ведущих в одноименных подкаталогах, например, ведущий `Home` отображается на класс `App\UI\Home\HomePresenter`. Это достигается удвоением звездочки (требуется Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Если мы разделим докладчиков на модули, то для каждого модуля у нас может быть свой маппинг: +Теперь перейдем к сопоставлению ведущих с модулями. Для каждого модуля мы можем определить конкретное сопоставление: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Теперь презентер `Front:Home` определяется классом `App\Modules\Front\HomePresenter`, а презентер `Admin:Dashboard` — `App\AdminModule\DashboardPresenter`. +Согласно этой конфигурации, ведущий `Front:Home` соотносится с классом `App\UI\Front\Home\HomePresenter`, а ведущий `Api:OAuth` - с классом `App\Api\OAuthPresenter`. -Удобнее будет создать общее правило (звездочка), которое заменит первые два правила и добавит дополнительную звездочку только для модуля: +Поскольку модули `Front` и `Admin` имеют схожий подход к отображению и, скорее всего, таких модулей будет больше, можно создать общее правило, которое заменит их. В маску класса добавляется новая звездочка для модуля: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Но что если мы используем несколько вложенных модулей и у нас есть, например, ведущий `Admin:User:Edit`? В этом случае сегмент со звездочкой, представляющий модуль для каждого уровня, будет просто повторяться, и результатом будет класс `App\Modules\Admin\User\Presenters\EditPresenter`. +Для многоуровневых вложенных модулей, таких как ведущий `Admin:User:Edit`, сегмент звездочки повторяется для каждого уровня, в результате чего получается класс `App\UI\Admin\User\Edit\EditPresenter`. Альтернативной нотацией является использование массива, состоящего из трех сегментов, вместо строки. Эта нотация эквивалентна предыдущей: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Значение по умолчанию - `*Module\*Presenter`. +Если у нас в конфигурации только одно правило, общее, то можно написать коротко: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/ru/templates.texy b/application/ru/templates.texy index 75f2c784d0..f506d32046 100644 --- a/application/ru/templates.texy +++ b/application/ru/templates.texy @@ -34,35 +34,81 @@ Nette использует систему шаблонов [Latte |latte:]. Latt Он определяет блок `content`, который вставляется вместо `{include content}` в макете, а также переопределяет блок `title`, который перезаписывает `{block title}` в макете. Попытайтесь представить себе результат. -Поиск шаблонов .[#toc-search-for-templates] -------------------------------------------- +Поиск шаблонов .[#toc-template-lookup] +-------------------------------------- + +В презентаторах вам не нужно указывать, какой шаблон должен быть отображен; фреймворк автоматически определит путь, облегчая вам кодирование. + +Если вы используете структуру каталогов, в которой у каждого ведущего есть своя директория, просто поместите шаблон в эту директорию под именем действия (т. е. представления). Например, для действия `default` используйте шаблон `default.latte`: -Путь к шаблонам определяется ведущим с помощью простой логики. Он попытается проверить, есть ли один из этих файлов, расположенный относительно каталога класса ведущего, где `` это имя текущего ведущего, а `` это имя текущего события: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Если вы используете структуру, в которой ведущие находятся в одном каталоге, а шаблоны - в папке `templates`, сохраните их либо в файле `..latte` или `/.latte`: -Если шаблон не найден, он попытается выполнить поиск в каталоге `templates` на один уровень выше, т.е. на том же уровне, что и каталог с классом ведущего. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Если шаблон не найден и там, ответом будет [ошибка 404 |presenters#Error 404 etc.]. +Каталог `templates` можно также разместить на один уровень выше, на том же уровне, что и каталог с классами ведущих. -Вы также можете изменить вид с помощью `$this->setView('jineView')`. Или, вместо прямого поиска, укажите имя файла шаблона с помощью `$this->template->setFile('/path/to/template.latte')`. +Если шаблон не найден, ведущий отвечает [ошибкой 404 - страница не найдена |presenters#Error 404 etc]. + +Изменить вид можно с помощью `$this->setView('anotherView')`. Также можно напрямую указать файл шаблона с помощью `$this->template->setFile('/path/to/template.latte')`. .[note] -Файлы, в которых производится поиск шаблонов, можно изменить, наложив метод [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], который возвращает массив возможных имен файлов. +Файлы, в которых производится поиск шаблонов, можно изменить, переопределив метод [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], который возвращает массив возможных имен файлов. + + +Поиск шаблонов макета .[#toc-layout-template-lookup] +---------------------------------------------------- + +Nette также автоматически ищет файл макета. + +Если вы используете структуру каталогов, в которой у каждого ведущего есть своя директория, поместите макет либо в папку с ведущим, если он предназначен только для него, либо на уровень выше, если он общий для нескольких ведущих: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Если вы используете структуру, в которой ведущие сгруппированы в одном каталоге, а шаблоны находятся в папке `templates`, макет будет находиться в следующих местах: -В этих файлах ожидается компоновка: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` макет, общий для нескольких докладчиков +Если ведущий находится в [модуле |modules], он также будет искать дальше по дереву каталогов в соответствии с вложенностью модуля. -Где `` это имя текущего ведущего и `` это имя макета, которое по умолчанию равно `'layout'`. Имя может быть изменено с помощью `$this->setLayout('jinyLayout')`, поэтому будут опробованы файлы `@jinyLayout.latte`. +Имя макета можно изменить с помощью `$this->setLayout('layoutAdmin')`, и тогда оно будет ожидаться в файле `@layoutAdmin.latte`. Вы также можете напрямую указать файл шаблона макета с помощью `$this->setLayout('/path/to/template.latte')`. -Вы также можете напрямую указать имя файла шаблона макета с помощью `$this->setLayout('/path/to/template.latte')`. Использование `$this->setLayout(false)` отключает отслеживание макета. +Использование тега `$this->setLayout(false)` или `{layout none}` внутри шаблона отключает поиск макета. .[note] -Файлы, в которых производится поиск шаблонов макета, можно изменить, наложив метод [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], который возвращает массив возможных имен файлов. +Файлы, в которых производится поиск шаблонов макетов, можно изменить, переопределив метод [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], который возвращает массив возможных имен файлов. Переменные в шаблоне .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template Вы также можете позволить себе роскошь шептать в шаблонах, просто установите плагин Latte в PhpStorm и поместите имя класса в начало шаблона, более подробную информацию смотрите в статье "Latte: как набирать систему":https://blog.nette.org/ru/latte-kak-ispol-zovat-sistemu-tipov: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte версии 3 предлагает более продвинутый способ создания [расширения |latte:creating-extension] для каждого веб-проекта. Вот краткий пример такого класса: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ final class LatteExtension extends Latte\Extension ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/sl/how-it-works.texy b/application/sl/how-it-works.texy index 0149fdc95f..53d08d145d 100644 --- a/application/sl/how-it-works.texy +++ b/application/sl/how-it-works.texy @@ -22,13 +22,13 @@ Struktura imenikov je videti nekako takole: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← osnovni potrebni razredi +│ │ └── RouterFactory.php ← konfiguracija naslovov URL +│ ├── UI/ ← predstavitev, predloge in podobno. +│ │ ├── @layout.latte ← predloga skupne postavitve +│ │ └── Home/ ← Domači imenik predstavnikov +│ │ ├── HomePresenter.php ← Razred HomePresenter +│ │ └── default.latte ← predloga za akcijo default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ Aplikacije, napisane v okolju Nette, so razdeljene na številne tako imenovane p Aplikacija se začne tako, da zahteva od tako imenovanega usmerjevalnika, da se odloči, kateremu od predstavnikov bo posredoval trenutno zahtevo v obdelavo. Usmerjevalnik se odloči, čigava je to odgovornost. Pregleda vhodni naslov URL `https://example.com/product/123`, ki želi `show` izdelek z `id: 123` kot dejanjem. Dobra navada je, da se pari predstavnik + akcija, ločeni z dvopičjem, zapišejo kot `Product:show`. -Usmerjevalnik je torej pretvoril naslov URL v par `Presenter:action` + parametri, v našem primeru `Product:show` + `id: 123`. Kako je videti usmerjevalnik, si lahko ogledate v datoteki `app/Router/RouterFactory.php`, podrobno pa ga bomo opisali v poglavju [Usmerjanje |Routing]. +Usmerjevalnik je torej pretvoril naslov URL v par `Presenter:action` + parametri, v našem primeru `Product:show` + `id: 123`. Kako je videti usmerjevalnik, si lahko ogledate v datoteki `app/Core/RouterFactory.php`, podrobno pa ga bomo opisali v poglavju [Usmerjanje |Routing]. Pojdimo naprej. Aplikacija že pozna ime predavatelja in lahko nadaljuje. Z ustvarjanjem predmeta `ProductPresenter`, ki je koda predstavnika `Product`. Natančneje, za ustvarjanje predstavnika zaprosi vsebnik DI, saj je izdelovanje objektov njegova naloga. @@ -121,12 +121,9 @@ Tako je bila klicana metoda `renderShow(123)`, katere koda je izmišljen primer, Nato predstavnik vrne odgovor. To je lahko stran HTML, slika, dokument XML, pošiljanje datoteke z diska, JSON ali preusmeritev na drugo stran. Pomembno je, da če izrecno ne navedemo, kako odgovoriti (kar je primer `ProductPresenter`), bo odgovor prikaz predloge s stranjo HTML. Zakaj? No, ker v 99 % primerov želimo izrisati predlogo, zato predstavnik to vedenje sprejme kot privzeto in nam želi olajšati delo. To je Nettejeva poanta. -Ni nam treba niti navesti, katero predlogo želimo narisati, on pot do nje izpelje po preprosti logiki. V primeru predstavnika `Product` in akcije `show`, poskuša preveriti, ali obstaja ena od teh datotek s predlogami glede na imenik, v katerem se nahaja razred `ProductPresenter`: +Sploh nam ni treba navesti, katero predlogo je treba prikazati; ogrodje bo pot določilo samo. V primeru akcije `show` preprosto poskuša naložiti predlogo `show.latte` v imeniku z razredom `ProductPresenter`. Prav tako poskuša najti postavitev v datoteki `@layout.latte` (več o [iskanju predlog |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Prav tako poskuša poiskati postavitev v datoteki `@layout.latte` in nato upodobi predlogo. Zdaj je naloga predstavnika in celotne aplikacije končana. Če predloga ne obstaja, se vrne stran z napako 404. Več o predstavitvah si lahko preberete na strani [Predstavitve |Presenters]. +Nato se predloge izrišejo. S tem je naloga predstavnika in celotne aplikacije končana in delo je opravljeno. Če predloga ne bi obstajala, bi se vrnila stran z napako 404. Več o predstavnikih si lahko preberete na strani [Predstavniki |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ Da bi se prepričali, poskusite celoten postopek ponoviti z nekoliko drugačnim 3) usmerjevalnik dekodira naslov URL kot par `Home:default` 4) ustvari se objekt `HomePresenter` 5) kličemo metodo `renderDefault()` (če obstaja) -6) prikaže se predloga `templates/Home/default.latte` z razporeditvijo `templates/@layout.latte` +6) prikaže se predloga `default.latte` z razporeditvijo `@layout.latte` Morda ste zdaj naleteli na veliko novih konceptov, vendar verjamemo, da so smiselni. Ustvarjanje aplikacij v programu Nette je zelo enostavno. diff --git a/application/sl/modules.texy b/application/sl/modules.texy index c0c01ae28d..bda3fd5943 100644 --- a/application/sl/modules.texy +++ b/application/sl/modules.texy @@ -2,29 +2,31 @@ Moduli ****** .[perex] -V Nette moduli predstavljajo logične enote, ki sestavljajo aplikacijo. Vključujejo predstavnike, predloge, lahko tudi komponente in razrede modelov. +Moduli vnašajo jasnost v aplikacije Nette, saj omogočajo enostavno razdelitev na logične enote. -En imenik za predstavnike in en imenik za predloge za prave projekte ne bi bil dovolj. Če je v eni mapi na desetine datotek, je to vsaj neorganizirano. Kako to odpraviti? Preprosto jih razdelimo v podimenike na disku in v imenske prostore v kodi. In točno to naredijo moduli Nette. - -Pozabimo torej na eno mapo za predstavnike in predloge in namesto tega ustvarimo module, na primer `Admin` in `Front`. +Podobno kot pri urejanju datotek v mape na trdem disku, lahko v Nette predstavnike, predloge in druge pomožne razrede razdelimo v module. Kako to deluje v praksi? Preprosto z vključevanjem novih podimenikov v strukturo. Tukaj je primer strukture z dvema moduloma, Front in Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Ta struktura imenikov se bo odražala v imenskih prostorih razredov, tako da bo na primer `DashboardPresenter` v imenskem prostoru `App\Modules\Admin\Presenters`: +Ta imeniška struktura se odraža v imenskih prostorih razredov, tako da se na primer `DashboardPresenter` nahaja v imenskem prostoru `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Na predvajalnik `Dashboard` znotraj modula `Admin` se v aplikaciji sklicujemo z uporabo zapisa v dvopičju kot na `Admin:Dashboard`, na njegovo akcijo `default` pa kot na `Admin:Dashboard:default`. -In kako Nette pravilno ve, da `Admin:Dashboard` predstavlja razred `App\Modules\Admin\Presenters\DashboardPresenter`? To je določeno s [preslikavo |#mapping] v konfiguraciji. -Podana struktura torej ni trdno določena in jo lahko spreminjate glede na svoje potrebe. +V aplikaciji se na predstavnik `Dashboard` znotraj modula `Admin` sklicujemo z uporabo zapisa v dvopičju kot `Admin:Dashboard`. Za njegovo akcijo `default` se sklicujemo na `Admin:Dashboard:default`. -Moduli seveda lahko poleg predstavnikov in predlog vsebujejo tudi vse druge elemente, kot so komponente, razredi modelov itd. +Predstavljena struktura ni toga; v konfiguraciji [jo |#mapping] lahko v [celoti prilagodite svojim potrebam |#mapping]. .[tip] + +Moduli lahko poleg predstavnikov in predlog vključujejo tudi vse druge datoteke, kot so komponente in pomožni razredi. Če razmišljate, kam jih umestiti, razmislite o uporabi mape `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Vgnezdeni moduli .[#toc-nested-modules] --------------------------------------- -Ni nujno, da moduli tvorijo le ravno strukturo, ustvarite lahko tudi podmodule, na primer: +Moduli so lahko vgrajeni na več ravneh, podobno kot struktura imenikov na disku: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Tako je modul `Blog` razdeljen na podmodula `Admin` in `Front`. Tudi to se bo odražalo v imenskih prostorih, ki bodo `App\Modules\Blog\Admin\Presenters` itd. Predstavnik `Dashboard` znotraj podmodula se imenuje `Blog:Admin:Dashboard`. +Modul `Blog` je razdeljen na podmodula `Admin` in `Front`. To se odraža tudi v imenskih prostorih, ki so nato prikazani kot `App\UI\Blog\Admin` in podobno. Če se želimo sklicevati na predstavnik `Dashboard` znotraj podmodula `Admin`, ga imenujemo `Blog:Admin:Dashboard`. -Gnezdenje je lahko tako globoko, kot želite, zato lahko ustvarite podmodule. +Gnezdenje je lahko tako globoko, kot je potrebno, kar omogoča ustvarjanje podmodulov. + +Če imate na primer v administraciji veliko predstavnikov, povezanih z upravljanjem naročil, kot so `OrderDetail`, `OrderEdit`, `OrderDispatch` itd., lahko ustvarite modul `Order`, v katerem bodo organizirani predstavniki, kot so `Detail`, `Edit`, `Dispatch` in drugi. Ustvarjanje povezav .[#toc-creating-links] @@ -102,46 +118,66 @@ Glejte [poglavje o usmerjanju |routing#Modules]. Kartiranje .[#toc-mapping] -------------------------- -Določa pravila, po katerih se ime razreda izpelje iz imena predstavnika. Zapišemo jih v [konfiguracijo |configuration] pod ključ `application › mapping`. +Mapiranje določa pravila za izpeljavo imena razreda iz imena predstavnika. Ta pravila so določena v [konfiguraciji |configuration] pod ključem `application › mapping`. + +Strukture imenikov, omenjene prej na tej strani, temeljijo na naslednjem preslikavanju: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Začnimo z vzorcem, ki ne uporablja modulov. Želeli bomo le, da imajo razredi predstavnikov imenski prostor `App\Presenters`. To pomeni, da mora biti predstavnik, kot je `Home`, preslikan v razred `App\Presenters\HomePresenter`. To lahko dosežemo z naslednjo konfiguracijo: +Kako deluje kartiranje? Za boljše razumevanje si najprej predstavljajmo aplikacijo brez modulov. Želimo, da razredi predstavnikov spadajo v imenski prostor `App\UI`, tako da se predstavnik `Home` preslika v razred `App\UI\HomePresenter`. To lahko dosežemo s to konfiguracijo: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -V maski razreda se ime predvajalnika nadomesti z zvezdico, rezultat pa je ime razreda. Enostavno! +Ta preslikava deluje tako, da zvezdico v maski `App\UI\*Presenter` nadomestimo z imenom predstavnika `Home`, s čimer dobimo končno ime razreda `App\UI\HomePresenter`. Preprosto! + +Vendar, kot lahko vidite v primerih v tem in drugih poglavjih, umeščamo predstavitvene razrede v istoimenske podimenike, npr. predstavitveni razred `Home` je preslikan v razred `App\UI\Home\HomePresenter`. To dosežemo s podvojitvijo zvezdice (zahteva program Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Če voditelje razdelimo na module, lahko za vsak modul pripravimo lastno preslikavo: +Sedaj se lotimo preslikave predstavnikov v module. Za vsak modul lahko opredelimo posebna preslikavanja: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Sedaj je predstavnik `Front:Home` preslikan v razred `App\Modules\Front\Presenters\HomePresenter`, predstavnik `Admin:Dashboard` pa v razred `App\Modules\Admin\Presenters\DashboardPresenter`. +V skladu s to konfiguracijo se predstavnik `Front:Home` prikaže v razred `App\UI\Front\Home\HomePresenter`, predstavnik `Api:OAuth` pa v razred `App\Api\OAuthPresenter`. -Bolj praktično je ustvariti splošno (zvezdno) pravilo, ki bo nadomestilo prvi dve. Dodatna zvezdica bo dodana maski razreda samo za ta modul: +Ker imata modula `Front` in `Admin` podoben pristop k preslikavi in ker bo takih modulov verjetno več, je mogoče ustvariti splošno pravilo, ki ju nadomesti. V masko razreda se doda nova zvezdica za modul: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Kaj pa, če uporabljamo vgnezdene module in imamo predvajalnik `Admin:User:Edit`? V tem primeru se segment z zvezdico, ki predstavlja modul za vsako raven, preprosto ponovi in rezultat je razred `App\Modules\Admin\User\Presenters\EditPresenter`. +Za večnivojske vgnezdene module, kot je predstavnik `Admin:User:Edit`, se segment z zvezdico ponovi za vsako raven, tako da nastane razred `App\UI\Admin\User\Edit\EditPresenter`. Alternativni zapis je, da namesto niza uporabimo polje, sestavljeno iz treh segmentov. Ta zapis je enakovreden prejšnjemu: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Privzeta vrednost je `*Module\*Presenter`. +Če imamo v konfiguraciji samo eno pravilo, splošno, lahko zapišemo na kratko: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/sl/templates.texy b/application/sl/templates.texy index 66005783a9..966b1524a2 100644 --- a/application/sl/templates.texy +++ b/application/sl/templates.texy @@ -34,35 +34,81 @@ To pa je lahko predloga za dejanja: V njej je opredeljen blok `content`, ki se v postavitev vstavi namesto bloka `{include content}`, prav tako pa je na novo opredeljen blok `title`, ki v postavitvi prepiše blok `{block title}`. Poskusite si predstavljati rezultat. -Iskanje predlog .[#toc-search-for-templates] --------------------------------------------- +Iskanje predloge .[#toc-template-lookup] +---------------------------------------- -Pot do predlog se določi po preprosti logiki. Poskusi preveriti, ali obstaja ena od teh datotek s predlogami glede na imenik, v katerem se nahaja razred presenter, kjer `` je ime trenutnega predstavnika in `` je ime trenutnega dejanja: +V predstavitvenih programih vam ni treba določiti, katera predloga naj se prikaže; ogrodje samodejno določi pot, kar vam olajša kodiranje. -- `templates//.latte` -- `templates/..latte` +Če uporabljate imeniško strukturo, v kateri ima vsak predstavnik svoj imenik, preprosto postavite predlogo v ta imenik pod ime dejanja (npr. pogleda). Na primer, za dejanje `default` uporabite predlogo `default.latte`: -Če predloge ne najde, jo poskuša poiskati v imeniku `templates` eno raven višje, tj. na isti ravni kot imenik z razredom predstavnika. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Če predloge ne najde niti tam, se kot odgovor prikaže [napaka 404 |presenters#Error 404 etc.]. +Če uporabljate strukturo, v kateri so predstavniki skupaj v enem imeniku, predloge pa v mapi `templates`, jo shranite bodisi v datoteko `..latte` ali . `/.latte`: -Pogled lahko spremenite tudi z uporabo `$this->setView('otherView')`. Lahko pa namesto iskanja neposredno določite ime datoteke s predlogo z uporabo `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +Imenik `templates` lahko postavite tudi eno raven višje, na isto raven kot imenik z razredi predavateljev. + +Če predloge ni mogoče najti, se predstavitveni program odzove z [napako 404 - stran ni najdena |presenters#Error 404 etc]. + +Prikaz lahko spremenite z uporabo spletne strani `$this->setView('anotherView')`. Datoteko s predlogo lahko določite tudi neposredno z uporabo `$this->template->setFile('/path/to/template.latte')`. .[note] -Poti, po katerih se iščejo predloge, lahko spremenite tako, da nadgradite metodo [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()], ki vrne polje možnih poti do datotek. +Datoteke, v katerih se iščejo predloge, lahko spremenite tako, da nadgradite metodo [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], ki vrne polje možnih imen datotek. + + +Iskanje predlog za postavitev .[#toc-layout-template-lookup] +------------------------------------------------------------ + +Nette samodejno poišče tudi datoteko z maketo. + +Če uporabljate imeniško strukturo, v kateri ima vsak predavatelj svoj imenik, postavite postavitev bodisi v mapo s predavateljem, če je namenjena samo njemu, bodisi za stopnjo višje, če je skupna več predavateljem: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Če uporabljate strukturo, v kateri so predstavniki združeni v enem imeniku, predloge pa so v mapi `templates`, bo postavitev pričakovana na naslednjih mestih: -Postavitev se pričakuje v naslednjih datotekah: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` postavitev, ki je skupna več predstavnikom +Če je predstavnik v [modulu |modules], se bo poiskal tudi naprej po drevesu imenika v skladu z gnezdenjem modula. -`` je ime trenutnega predavatelja in `` je ime postavitve, ki je privzeto `'layout'`. Ime lahko spremenite s `$this->setLayout('otherLayout')`, tako da se bodo poskušale uporabiti datoteke `@otherLayout.latte`. +Ime postavitve lahko spremenite z uporabo spletne strani `$this->setLayout('layoutAdmin')`, nato pa jo boste pričakali v datoteki `@layoutAdmin.latte`. Datoteko s predlogo postavitve lahko določite tudi neposredno z uporabo `$this->setLayout('/path/to/template.latte')`. -Ime datoteke za predlogo postavitve lahko določite tudi neposredno z uporabo `$this->setLayout('/path/to/template.latte')`. Z uporabo spletne strani `$this->setLayout(false)` bo iskanje postavitve onemogočeno. +Uporaba `$this->setLayout(false)` ali oznake `{layout none}` znotraj predloge onemogoči iskanje postavitve. .[note] -Poti, po katerih se iščejo predloge, lahko spremenite tako, da nadgradite metodo [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], ki vrne polje možnih poti do datotek. +Datoteke, v katerih se iščejo predloge postavitve, lahko spremenite tako, da nadgradite metodo [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], ki vrne polje možnih imen datotek. Spremenljivke v predlogi .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ Opomba `@property-read` je namenjena IDE in statični analizi, zaradi nje bo del Privoščite si lahko tudi razkošje šepetanja v predlogah, samo namestite vtičnik Latte v PhpStorm in na začetku predloge navedite ime razreda, glejte članek "Latte: kako vtipkati sistem":https://blog.nette.org/sl/latte-kako-uporabljati-sistem-tipov: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Različica Latte 3 ponuja naprednejši način z ustvarjanjem [razširitve |latte:creating-extension] za vsak spletni projekt. Tukaj je približni primer takega razreda: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ Registriramo ga z uporabo [konfiguracije|configuration#Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/tr/how-it-works.texy b/application/tr/how-it-works.texy index 78f72c450c..50e09beecc 100644 --- a/application/tr/how-it-works.texy +++ b/application/tr/how-it-works.texy @@ -22,13 +22,13 @@ Dizin yapısı şuna benzer: /--pre web-project/ ├── app/ ← directory with application -│ ├── Presenters/ ← presenter classes -│ │ ├── HomePresenter.php ← Home presenter class -│ │ └── templates/ ← templates directory -│ │ ├── @layout.latte ← template of shared layout -│ │ └── Home/ ← templates for Home presenter -│ │ └── default.latte ← template for action `default` -│ ├── Router/ ← configuration of URL addresses +│ ├── Core/ ← temel gerekli sınıflar +│ │ └── RouterFactory.php ← URL adreslerinin yapılandırılması +│ ├── UI/ ← presenters, templates & co. +│ │ ├── @layout.latte ← paylaşılan düzen şablonu +│ │ └── Home/ ← Ana Sayfa sunucu dizini +│ │ ├── HomePresenter.php ← Ev sunucusu sınıfı +│ │ └── default.latte ← eylem için şablon default │ └── Bootstrap.php ← booting class Bootstrap ├── bin/ ← scripts for the command line ├── config/ ← configuration files @@ -91,7 +91,7 @@ Nette'de yazılan uygulamalar, belirli bir web sitesi sayfasını temsil eden s Uygulama, yönlendirici olarak adlandırılan kişiden mevcut talebin işlenmek üzere hangi sunuculara iletileceğine karar vermesini isteyerek başlar. Yönlendirici bunun kimin sorumluluğunda olduğuna karar verir. `https://example.com/product/123` ile bir ürünü `id: 123` eylem olarak isteyen **sunucu** `Product` için bir iş olduğuna karar verir. Sunucu + eylem çiftlerini iki nokta üst üste ile ayırarak `Product:show` şeklinde yazmak iyi bir alışkanlıktır. -Böylece yönlendirici URL'yi bir `Presenter:action` + parametreler çiftine dönüştürdü, bizim durumumuzda `Product:show` + `id: 123`. Bir yönlendiricinin nasıl göründüğünü `app/Router/RouterFactory.php` dosyasında görebilirsiniz ve bunu [Yönlendirme |Routing] bölümünde ayrıntılı olarak açıklayacağız. +Böylece yönlendirici URL'yi bir `Presenter:action` + parametreler çiftine dönüştürdü, bizim durumumuzda `Product:show` + `id: 123`. Bir yönlendiricinin nasıl göründüğünü `app/Core/RouterFactory.php` dosyasında görebilirsiniz ve bunu [Yönlendirme |Routing] bölümünde ayrıntılı olarak açıklayacağız. Devam edelim. Uygulama zaten sunucunun adını biliyor ve devam edebilir. Sunum yapan kişinin kodu olan `ProductPresenter` nesnesini oluşturarak `Product`. Daha doğrusu, DI konteynerinden sunucuyu yaratmasını ister, çünkü nesneleri üretmek onun işidir. @@ -121,12 +121,9 @@ Böylece, kodu kurgusal bir örnek olan `renderShow(123)` yöntemi çağrıldı, Daha sonra, sunum yapan kişi yanıtı döndürür. Bu bir HTML sayfası, bir resim, bir XML belgesi, diskten bir dosya gönderme, JSON veya başka bir sayfaya yönlendirme olabilir. Daha da önemlisi, nasıl yanıt verileceğini açıkça belirtmezsek ( `ProductPresenter` adresinde olduğu gibi), yanıt şablonu bir HTML sayfası ile işlemek olacaktır. Neden mi? Çünkü vakaların %99'unda bir şablon çizmek isteriz, dolayısıyla sunum yapan kişi bu davranışı varsayılan olarak kabul eder ve işimizi kolaylaştırmak ister. Nette'in amacı da bu. -Hangi şablonun çizileceğini belirtmemize bile gerek yok, basit bir mantıkla o şablona giden yolu türetiyor. Sunucu `Product` ve eylem `show` durumunda, bu şablon dosyalarından birinin `ProductPresenter` sınıfının bulunduğu dizine göre var olup olmadığını görmeye çalışır: +Hangi şablonun işleneceğini belirtmemize bile gerek yoktur; framework yolu kendisi çıkaracaktır. `show` eylemi söz konusu olduğunda, basitçe `ProductPresenter` sınıfının bulunduğu dizindeki `show.latte` şablonunu yüklemeye çalışır. Ayrıca `@layout.latte` dosyasındaki düzeni bulmaya çalışır ( [şablon arama |templates#Template Lookup] hakkında daha fazla bilgi). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -Ayrıca `@layout.latte` dosyasında düzeni bulmaya çalışacak ve ardından şablonu oluşturacaktır. Artık sunucunun ve tüm uygulamanın görevi tamamlanmıştır. Şablon mevcut değilse, 404 hatalı bir sayfa döndürülecektir. Sunumcular hakkında daha fazla bilgiyi [Sunumcular |Presenters] sayfasında bulabilirsiniz. +Daha sonra şablonlar işlenir. Bu, sunucunun ve tüm uygulamanın görevini tamamlar ve iş biter. Eğer şablon mevcut değilse, 404 hata sayfası döndürülür. Sunucular hakkında daha fazla bilgi için [Sunucular |presenters] sayfasına bakabilirsiniz. [* request-flow.svg *] @@ -137,7 +134,7 @@ Sadece emin olmak için, tüm süreci biraz farklı bir URL ile özetlemeye çal 3) yönlendirici URL'yi bir çift olarak çözer `Home:default` 4) bir `HomePresenter` nesnesi oluşturulur 5) `renderDefault()` yöntemi çağrılır (eğer varsa) -6) `templates/@layout.latte` düzenine sahip bir `templates/Home/default.latte` şablonu oluşturulur +6) `@layout.latte` düzenine sahip bir `default.latte` şablonu oluşturulur Şu anda birçok yeni kavramla karşılaşmış olabilirsiniz, ancak bunların anlamlı olduğuna inanıyoruz. Nette'de uygulama oluşturmak çocuk oyuncağı. diff --git a/application/tr/modules.texy b/application/tr/modules.texy index 63da6e9e48..2fb05dde40 100644 --- a/application/tr/modules.texy +++ b/application/tr/modules.texy @@ -2,29 +2,31 @@ Modüller ******** .[perex] -Nette'de modüller bir uygulamayı oluşturan mantıksal birimleri temsil eder. Sunucuları, şablonları, muhtemelen bileşenleri ve model sınıflarını içerirler. +Modüller, mantıksal birimlere kolayca bölünmeyi kolaylaştırarak Nette uygulamalarına netlik kazandırır. -Sunucular için bir dizin ve şablonlar için bir dizin gerçek projeler için yeterli olmayacaktır. Bir klasörde düzinelerce dosya olması en azından düzensizdir. Bundan nasıl kurtulabiliriz? Basitçe onları diskteki alt dizinlere ve koddaki ad alanlarına böleriz. Nette modüllerinin yaptığı da tam olarak budur. - -Sunucular ve şablonlar için tek bir klasör oluşturmayı unutalım ve bunun yerine örneğin `Admin` ve `Front` gibi modüller oluşturalım. +Dosyaları sabit diskte klasörler halinde düzenlemeye benzer şekilde, Nette'de sunum yapan kişileri, şablonları ve diğer yardımcı sınıfları modüllere bölebiliriz. Bu pratikte nasıl çalışır? Basitçe yapıya yeni alt dizinler ekleyerek. İşte Front ve Admin olmak üzere iki modüllü bir yapı örneği: /--pre -app/ -├── Presenters/ -├── Modules/ ← directory with modules -│ ├── Admin/ ← module Admin -│ │ ├── Presenters/ ← its presenters -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← module Front -│ └── Presenters/ ← its presenters -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Bu dizin yapısı sınıf ad alanları tarafından yansıtılacaktır, bu nedenle örneğin `DashboardPresenter` `App\Modules\Admin\Presenters` ad alanında olacaktır: +Bu dizin yapısı sınıfların isim alanlarına da yansıtılır; örneğin `DashboardPresenter`, `App\UI\Admin\Dashboard` isim alanında yer alır: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -`Admin` modülü içindeki `Dashboard` sunumcusuna uygulama içinde iki nokta üst üste gösterimi kullanılarak `Admin:Dashboard` şeklinde ve `default` eylemine `Admin:Dashboard:default` şeklinde referans verilir. -Peki Nette proper `Admin:Dashboard` 'un `App\Modules\Admin\Presenters\DashboardPresenter` sınıfını temsil ettiğini nasıl biliyor? Bu, yapılandırmadaki [eşleme |#mapping] ile belirlenir. -Bu nedenle, verilen yapı sabit değildir ve ihtiyaçlarınıza göre değiştirebilirsiniz. +Uygulamada, `Admin` modülü içindeki `Dashboard` sunumcusuna iki nokta üst üste gösterimini kullanarak `Admin:Dashboard` olarak atıfta bulunuyoruz. `default` eylemi için `Admin:Dashboard:default` olarak adlandırıyoruz. -Modüller elbette sunum yapanların ve şablonların yanı sıra bileşenler, model sınıfları vb. gibi diğer tüm öğeleri de içerebilir. +Sunulan yapı katı değildir; yapılandırmada [ihtiyaçlarınıza göre tamamen özelleştirebilirsiniz |#mapping]. .[tip] + +Modüller, sunucular ve şablonların yanı sıra bileşenler ve yardımcı sınıflar gibi diğer tüm dosyaları da içerebilir. Bunları nereye yerleştireceğinizi düşünüyorsanız, bir `Accessory` klasörü kullanmayı düşünün: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- İç İçe Modüller .[#toc-nested-modules] -------------------------------------- -Modüller sadece düz bir yapı oluşturmak zorunda değildir, örneğin alt modüller de oluşturabilirsiniz: +Modüller, diskteki bir dizin yapısına benzer şekilde birden fazla iç içe geçme seviyesine sahip olabilir: /--pre -app/ -├── Modules/ ← directory with modules -│ ├── Blog/ ← module Blog -│ │ ├── Admin/ ← submodule Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← submodule Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← module Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Böylece, `Blog` modülü `Admin` ve `Front` alt modüllerine bölünmüştür. Yine, bu durum `App\Modules\Blog\Admin\Presenters` vb. isim alanlarına da yansıyacaktır. Alt modülün içindeki `Dashboard` sunucusu `Blog:Admin:Dashboard` olarak adlandırılır. + `Blog` modülü `Admin` ve `Front` alt modüllerine ayrılmıştır. Bu aynı zamanda `App\UI\Blog\Admin` ve benzer şekilde görünen isim alanlarına da yansıtılır. `Admin` alt modülü içindeki `Dashboard` sunucusuna atıfta bulunmak için, bunu `Blog:Admin:Dashboard` olarak adlandırıyoruz. -İç içe geçme istediğiniz kadar derin olabilir, böylece alt alt modüller oluşturulabilir. +Yerleştirme, alt alt modüllerin oluşturulmasına izin vererek gerektiği kadar derin olabilir. + +Örneğin, yönetimde `OrderDetail`, `OrderEdit`, `OrderDispatch`, vb. gibi sipariş yönetimiyle ilgili birçok sunucunuz varsa, `Detail`, `Edit`, `Dispatch` ve diğerleri gibi sunucuların düzenleneceği bir `Order` modülü oluşturabilirsiniz. Bağlantı Oluşturma .[#toc-creating-links] @@ -102,46 +118,66 @@ Yönlendirme .[#toc-routing] Haritalama .[#toc-mapping] -------------------------- -Sınıf adının sunum yapan kişinin adından türetildiği kuralları tanımlar. Bunları [yapılandırmada |configuration] `application › mapping` anahtarının altına yazıyoruz. +Eşleme, sınıf adının sunum yapan kişinin adından türetilmesine ilişkin kuralları tanımlar. Bu kurallar [yapılandırmada |configuration] `application › mapping` anahtarı altında belirtilir. + +Bu sayfada daha önce bahsedilen dizin yapıları aşağıdaki eşleştirmeye dayanmaktadır: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Modül kullanmayan bir örnekle başlayalım. Sadece sunum yapan sınıfların `App\Presenters` ad alanına sahip olmasını isteyeceğiz. Bu, `Home` gibi bir sunucunun `App\Presenters\HomePresenter` sınıfıyla eşleşmesi gerektiği anlamına gelir. Bu, aşağıdaki yapılandırma ile gerçekleştirilebilir: +Eşleme nasıl çalışır? Daha iyi anlamak için öncelikle modülsüz bir uygulama hayal edelim. Sunucu sınıflarının `App\UI` ad alanı altında olmasını istiyoruz, böylece `Home` sunucusu `App\UI\HomePresenter` sınıfıyla eşleşir. Bu, şu yapılandırma ile gerçekleştirilebilir: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Sunum yapan kişinin adı sınıf maskesindeki yıldız işaretiyle değiştirilir ve sonuç sınıf adı olur. Kolay! +Bu eşleme, `App\UI\*Presenter` maskesindeki yıldız işaretini `Home` sunum yapan kişi adıyla değiştirerek çalışır ve sonuçta `App\UI\HomePresenter` nihai sınıf adı elde edilir. Çok basit! + +Ancak, bu ve diğer bölümlerdeki örneklerde görebileceğiniz gibi, sunum yapan sınıfları isimsiz alt dizinlere yerleştiriyoruz, örneğin, `Home` sunum yapan `App\UI\Home\HomePresenter` sınıfıyla eşleştirilmiştir. Bu, yıldız işaretinin iki katına çıkarılmasıyla elde edilir (Nette Application 3.2 gerektirir): + +```neon +application: + mapping: App\UI\**Presenter +``` -Sunum yapanları modüllere ayırırsak, her modül için kendi eşlememizi yapabiliriz: +Şimdi, sunum yapan kişileri modüllerle eşleştirmeye geçelim. Her modül için özel eşlemeler tanımlayabiliriz: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Şimdi `Front:Home` sunucusu `App\Modules\Front\Presenters\HomePresenter` sınıfıyla ve `Admin:Dashboard` sunucusu `App\Modules\Admin\Presenters\DashboardPresenter` sınıfıyla eşleşir. +Bu yapılandırmaya göre, `Front:Home` sunucusu `App\UI\Front\Home\HomePresenter` sınıfıyla eşleşirken, `Api:OAuth` sunucusu `App\Api\OAuthPresenter` sınıfıyla eşleşir. -İlk ikisini değiştirmek için genel bir (yıldız) kural oluşturmak daha pratiktir. Ekstra yıldız işareti sadece modül için sınıf maskesine eklenecektir: + `Front` ve `Admin` modülleri benzer bir eşleme yaklaşımına sahip olduğundan ve bu türden daha fazla modül olması muhtemel olduğundan, bunların yerini alan genel bir kural oluşturmak mümkündür. Sınıf maskesine modül için yeni bir yıldız işareti eklenir: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Peki ya iç içe modüller kullanıyorsak ve bir sunumcumuz varsa `Admin:User:Edit`? Bu durumda, her seviye için modülü temsil eden yıldız işaretli bölüm basitçe tekrarlanır ve sonuç `App\Modules\Admin\User\Presenters\EditPresenter` sınıfı olur. +Sunum yapan kişi `Admin:User:Edit` gibi çok seviyeli iç içe modüller için yıldız işareti segmenti her seviye için tekrarlanır ve `App\UI\Admin\User\Edit\EditPresenter` sınıfı ortaya çıkar. -Alternatif bir gösterim, bir dize yerine üç segmentten oluşan bir dizi kullanmaktır. Bu gösterim bir öncekine eşdeğerdir: +Alternatif bir gösterim, dize yerine üç segmentten oluşan bir dizi kullanmaktır. Bu gösterim bir öncekine eşdeğerdir: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Varsayılan değer `*Module\*Presenter`'dur. +Konfigürasyonda sadece bir kuralımız varsa, genel olanı, kısaca yazabiliriz: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/tr/templates.texy b/application/tr/templates.texy index d817bc2d45..ca42448aad 100644 --- a/application/tr/templates.texy +++ b/application/tr/templates.texy @@ -34,35 +34,81 @@ Bu da eylem şablonu olabilir: Düzende `{include content}` yerine eklenen `content` bloğunu tanımlar ve ayrıca düzende `{block title}` 'un üzerine yazılan `title` bloğunu yeniden tanımlar. Sonucu hayal etmeye çalışın. -Şablon Arama .[#toc-search-for-templates] ------------------------------------------ +Şablon Arama .[#toc-template-lookup] +------------------------------------ + +Sunucularda, hangi şablonun işleneceğini belirtmenize gerek yoktur; çerçeve yolu otomatik olarak belirleyerek kodlamayı sizin için kolaylaştıracaktır. + +Her sunucunun kendi dizinine sahip olduğu bir dizin yapısı kullanıyorsanız, şablonu bu dizine eylemin adı (yani görünüm) altında yerleştirmeniz yeterlidir. Örneğin, `default` eylemi için `default.latte` şablonunu kullanın: -Şablonların yolu basit bir mantığa göre çıkarılır. Sunucu sınıfının bulunduğu dizine göre bu şablon dosyalarından birinin var olup olmadığına bakılır, burada `` geçerli sunum yapan kişinin adı ve `` geçerli eylemin adıdır: +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -- `templates//.latte` -- `templates/..latte` +Sunucuların tek bir dizinde ve şablonların `templates` klasöründe bir arada olduğu bir yapı kullanıyorsanız, bunu bir dosyaya kaydedin `..latte` veya `/.latte`: -Şablon bulunamazsa, `templates` dizininde bir seviye yukarıda, yani sunum yapan sınıfın bulunduğu dizinle aynı seviyede arama yapmaya çalışacaktır. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- -Şablon orada da bulunamazsa, yanıt [404 hatası |presenters#Error 404 etc.] olur. + `templates` dizini, sunum yapan sınıfların bulunduğu dizinle aynı seviyede, bir seviye daha yükseğe de yerleştirilebilir. -Ayrıca `$this->setView('otherView')` adresini kullanarak görünümü değiştirebilirsiniz. Ya da arama yapmak yerine `$this->template->setFile('/path/to/template.latte')` adresini kullanarak şablon dosyasının adını doğrudan belirtin. +Şablon bulunamazsa, sunum yapan kişi [404 - sayfa bulunamadı hatası |presenters#Error 404 etc] ile yanıt verir. + +Görünümü `$this->setView('anotherView')` adresini kullanarak değiştirebilirsiniz. Şablon dosyasını `$this->template->setFile('/path/to/template.latte')` ile doğrudan belirtmek de mümkündür. .[note] -Olası dosya yollarından oluşan bir dizi döndüren [formatTemplateFiles |api:Nette\Application\UI\Presenter::formatTemplateFiles()] yöntemini geçersiz kılarak şablonların arandığı yolları değiştirebilirsiniz. +Şablonların arandığı dosyalar, olası dosya adlarından oluşan bir dizi döndüren [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()] yöntemi geçersiz kılınarak değiştirilebilir. + + +Düzen Şablonu Arama .[#toc-layout-template-lookup] +-------------------------------------------------- + +Nette ayrıca otomatik olarak yerleşim dosyasını arar. + +Her sunum yapan kişinin kendi dizinine sahip olduğu bir dizin yapısı kullanıyorsanız, düzeni ya sadece sunum yapan kişiye özelse sunum yapan kişinin bulunduğu klasöre ya da birden fazla sunum yapan kişi için ortaksa bir üst seviyeye yerleştirin: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Sunum yapanların tek bir dizinde gruplandığı ve şablonların `templates` klasöründe bulunduğu bir yapı kullanıyorsanız, düzen aşağıdaki yerlerde beklenecektir: -Düzen aşağıdaki dosyalarda beklenmektedir: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` birden fazla sunumcu için ortak düzen +Sunucu bir [modüldeyse |modules], modülün iç içe geçmesine göre dizin ağacının daha yukarısında da arama yapacaktır. -`` geçerli sunum yapan kişinin adı ve `` varsayılan olarak `'layout'` olan düzenin adıdır. İsim `$this->setLayout('otherLayout')` ile değiştirilebilir, böylece `@otherLayout.latte` dosyaları denenecektir. +Düzenin adı `$this->setLayout('layoutAdmin')` kullanılarak değiştirilebilir ve ardından `@layoutAdmin.latte` dosyasında beklenir. Düzen şablon dosyasını `$this->setLayout('/path/to/template.latte')` adresini kullanarak doğrudan da belirtebilirsiniz. -Düzen şablonunun dosya adını `$this->setLayout('/path/to/template.latte')` adresini kullanarak doğrudan da belirtebilirsiniz. `$this->setLayout(false)` adresini kullanmak düzen aramayı devre dışı bırakacaktır. +Şablon içinde `$this->setLayout(false)` veya `{layout none}` etiketinin kullanılması düzen aramayı devre dışı bırakır. .[note] -Olası dosya yollarından oluşan bir dizi döndüren [formatLayoutTemplateFiles |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] yöntemini geçersiz kılarak şablonların arandığı yolları değiştirebilirsiniz. +Düzen şablonlarının arandığı dosyalar, olası dosya adlarından oluşan bir dizi döndüren [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()] yöntemi geçersiz kılınarak değiştirilebilir. Şablondaki Değişkenler .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ Sunucudaki `$this->template` nesnesi artık `ArticleTemplate` sınıfının bir Şablonlarda da fısıldama lüksünün tadını çıkarabilirsiniz, sadece PhpStorm'da Latte eklentisini kurun ve şablonun başında sınıf adını belirtin, "Latte: sistem nasıl yazılır":https://blog.nette.org/tr/latte-tip-sistemi-nasil-kullanilir makalesine bakın: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte sürüm 3, her web projesi için bir [uzantı |latte:creating-extension] oluşturarak daha gelişmiş bir yol sunar. İşte böyle bir sınıfın kabaca bir örneği: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ final class LatteExtension extends Latte\Extension ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` diff --git a/application/uk/how-it-works.texy b/application/uk/how-it-works.texy index be1f7ce5aa..12f465f683 100644 --- a/application/uk/how-it-works.texy +++ b/application/uk/how-it-works.texy @@ -22,13 +22,13 @@ /--pre web-project/ ├── app/ ← каталог с приложением -│ ├── Presenters/ ← классы презентеров -│ │ ├── HomePresenter.php ← Класс презентера главной страницы -│ │ └── templates/ ← директория шаблонов -│ │ ├── @layout.latte ← шаблон общего макета -│ │ └── Home/ ← шаблоны презентера главной страницы -│ │ └── default.latte ← шаблон действия `default` -│ ├── Router/ ← конфигурация URL-адресов +│ ├── Core/ ← основні необхідні класи +│ │ └── RouterFactory.php ← конфігурація URL-адрес +│ ├── UI/ ← презентатори, шаблони та інше +│ │ ├── @layout.latte ← шаблон спільного макета +│ │ └── Home/ ← домашній каталог доповідачів +│ │ ├── HomePresenter.php ← клас головного доповідача +│ │ └── default.latte ← шаблон дії default │ └── Bootstrap.php ← загрузочный класс Bootstrap ├── bin/ ← скрипты командной строки ├── config/ ← файлы конфигурации @@ -91,7 +91,7 @@ Nette - це наставник, який спрямовує вас до нап Додаток починає роботу з того, що просить так званий маршрутизатор вирішити, якому з презентерів передати поточний запит на обробку. Маршрутизатор вирішує, чия це відповідальність. Він переглядає вхідний URL `https://example.com/product/123`, який хоче `показать` продукт із `id: 123` як дію. Доброю звичкою є написання пар презентер + дія, розділених двокрапкою: `Продукт:показать`. -Тому маршрутизатор перетворив URL у пару `Presenter:action` + параметри, у нашому випадку `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Router/RouterFactory.php`, і ми детально опишемо його в розділі [Маршрутизація |routing]. +Тому маршрутизатор перетворив URL у пару `Presenter:action` + параметри, у нашому випадку `Product:show` + `id`: 123`. Вы можете увидеть, как выглядит маршрутизатор в файле `app/Core/RouterFactory.php`, і ми детально опишемо його в розділі [Маршрутизація |routing]. Давайте рухатися далі. Додаток уже знає ім'я презентера і може продовжити роботу. Шляхом створення об'єкта `ProductPresenter`, який є кодом презентера `Product`. Точніше, він просить контейнер DI створити презентера, тому що створення об'єктів - це його робота. @@ -121,12 +121,9 @@ class ProductPresenter extends Nette\Application\UI\Presenter Після цього презентер повертає відповідь. Це може бути HTML-сторінка, зображення, XML-документ, надсилання файлу з диска, JSON або перенаправлення на іншу сторінку. Важливо зазначити, що якщо ми явно не вказуємо, як реагувати (що має місце у випадку з `ProductPresenter`), відповіддю буде відображення шаблону з HTML-сторінкою. Чому? Ну, тому що в 99% випадків ми хочемо відобразити шаблон, тому презентер приймає таку поведінку за замовчуванням і хоче полегшити нашу роботу. Це точка зору Nette. -Нам навіть не потрібно вказувати, який шаблон потрібно вивести, він сам виводить шлях до нього відповідно до простої логіки. У випадку з презентером `Product` і дією `show`, він намагається перевірити, чи існує один із цих файлів шаблонів відносно каталогу, в якому знаходиться клас `ProductPresenter`: +Нам навіть не потрібно вказувати, який шаблон рендерити; фреймворк сам визначить шлях. У випадку дії `show` він просто намагається завантажити шаблон `show.latte` з каталогу з класом `ProductPresenter`. Він також намагається знайти макет у файлі `@layout.latte` (докладніше про [пошук шаблонів |templates#Template Lookup]). -- `templates/Product/show.latte` -- `templates/Product.show.latte` - -І потім він відображає шаблон. Тепер завдання презентера і всієї програми виконано. Якщо шаблону не існує, буде повернуто сторінку з помилкою 404. Детальніше про презентери ви можете прочитати на сторінці [Презентери |presenters]. +Згодом шаблони візуалізуються. На цьому завдання доповідача і всієї програми завершується, і робота завершується. Якщо шаблон не існує, буде повернута сторінка помилки 404. Ви можете прочитати більше про доповідачів на сторінці [Доповідачі |presenters]. [* request-flow.svg *] @@ -137,7 +134,7 @@ class ProductPresenter extends Nette\Application\UI\Presenter 3) маршрутизатор декодує URL як пару `Home:default` 4) створюється об'єкт `HomePresenter` 5) викликається метод `renderDefault()` (якщо існує) -6) шаблон `templates/Home/default.latte` з макетом `templates/@layout.latte` відмальований +6) шаблон `default.latte` з макетом `@layout.latte` відмальований Можливо, зараз ви зіткнулися з безліччю нових понять, але ми вважаємо, що вони мають сенс. Створювати додатки в Nette - простіше простого. diff --git a/application/uk/modules.texy b/application/uk/modules.texy index e660553440..a9b28a35c7 100644 --- a/application/uk/modules.texy +++ b/application/uk/modules.texy @@ -2,29 +2,31 @@ ****** .[perex] -У Nette модулі являють собою логічні одиниці, з яких складається додаток. Вони включають ведучі, шаблони, можливо, компоненти та класи моделей. +Модулі вносять ясність у додатки Nette, полегшуючи поділ на логічні блоки. -Одного компонента для презентаторів і одного для шаблонів буде недостатньо для реальних проектів. Наявність десятків файлів в одній папці щонайменше неорганізована. Як вийти з цього становища? Ми просто розділяємо їх на підкаталоги на диску і на простори імен у коді. І це саме те, що роблять модулі Nette. - -Тому давайте забудемо про єдину папку для ведучих і шаблонів і натомість створимо модулі, наприклад, `Admin` і `Front`. +Подібно до організації файлів у папки на жорсткому диску, в Nette ми можемо розділити презентатори, шаблони та інші допоміжні класи на модулі. Як це працює на практиці? Просто додаванням нових підкаталогів до структури. Ось приклад структури з двома модулями, Front і Admin: /--pre -app/ -├── Presenters/ -├── Modules/ ← директория с модулями -│ ├── Admin/ ← модуль Admin -│ │ ├── Presenters/ ← его презентеры -│ │ │ ├── DashboardPresenter.php -│ │ │ └── templates/ -│ └── Front/ ← модуль Front -│ └── Presenters/ ← его презентеры -│ └── ... +app/ +├── UI/ +│ ├── Admin/ ← Admin module +│ │ ├── @layout.latte +│ │ ├── Dashboard/ +│ │ │ ├── DashboardPresenter.php +│ │ │ └── default.latte +│ │ └── ... +│ ├── Front/ ← Front module +│ │ ├── @layout.latte +│ │ ├── Home/ +│ │ │ ├── HomePresenter.php +│ │ │ └── default.latte +│ │ └── ... \-- -Ця структура каталогів буде відображена в просторах імен класів, так, наприклад, `DashboardPresenter` буде знаходитися в просторі `App\Modules\Admin\Presenters`: +Ця структура каталогів відображається в просторах імен класів, тому, наприклад, `DashboardPresenter` знаходиться в просторі імен `App\UI\Admin\Dashboard`: ```php -namespace App\Modules\Admin\Presenters; +namespace App\UI\Admin\Dashboard; class DashboardPresenter extends Nette\Application\UI\Presenter { @@ -32,35 +34,49 @@ class DashboardPresenter extends Nette\Application\UI\Presenter } ``` -Ведучий `Dashboard` усередині модуля `Admin` позначається в додатку за допомогою подвійної точкової нотації як `Admin:Dashboard`, а його дія `default` позначається як `Admin:Dashboard:default`. -А звідки Nette знає, що `Admin:Dashboard` представляє клас `App\Modules\Admin\Presenters\DashboardPresenter`? Ми говоримо про це, використовуючи [відображення |#Mapping] в конфігурації. -Таким чином, наведена структура не є фіксованою, і ви можете змінювати її на свій розсуд. +У програмі ми звертаємось до доповідача `Dashboard` у модулі `Admin`, використовуючи двокрапку, як `Admin:Dashboard`. Для його дії `default` ми звертаємось до нього як `Admin:Dashboard:default`. -Модулі, звісно, можуть містити всі інші частини, крім презентаторів і шаблонів, такі як компоненти, класи моделей тощо. +Представлена структура не є жорсткою; ви можете [повністю налаштувати її відповідно до ваших потреб |#mapping] у конфігурації. .[tip] + +Модулі можуть включати всі інші файли, такі як компоненти і допоміжні класи, на додаток до презентаторів і шаблонів. Якщо ви обмірковуєте, де їх розмістити, розгляньте можливість використання папки `Accessory`: + +/--pre +app/ +├── UI/ +│ ├── Admin/ +│ │ ├── Accessory/ +│ │ │ ├── FormFactory.php +│ │ │ └── AdminLayout.php +│ │ ├── Dashboard/ +│ │ └── ... +\-- Вкладені модулі .[#toc-nested-modules] -------------------------------------- -Модулі не обов'язково повинні формувати тільки плоску структуру, ви також можете створювати, наприклад, підмодулі: +Модулі можуть мати кілька рівнів вкладеності, подібно до структури каталогів на диску: /--pre -app/ -├── Modules/ ← директория с модулями -│ ├── Blog/ ← модуль Blog -│ │ ├── Admin/ ← подмодуль Admin -│ │ │ ├── Presenters/ +app/ +├── UI/ +│ ├── Blog/ ← Blog module +│ │ ├── Admin/ ← Admin submodule +│ │ │ ├── Dashboard/ +│ │ │ └── ... +│ │ ├── Front/ ← Front submodule +│ │ │ ├── @layout.latte +│ │ │ ├── Home/ │ │ │ └── ... -│ │ └── Front/ ← подмодуль Front -│ │ ├── Presenters/ -│ │ └── ... -│ ├── Forum/ ← модуль Forum +│ ├── Forum/ ← Forum module │ │ └── ... \-- -Таким чином, модуль `Blog` розбивається на підмодулі `Admin` і `Front`. І знову ж таки це буде відображено в просторах імен, які будуть `App\Modules\Blog\Admin\Presenters` тощо. Ведучий `Dashboard` всередині підмодуля називається `Blog:Admin:Dashboard`. +Модуль `Blog` поділяється на підмодулі `Admin` і `Front`. Це також відображається у просторах імен, які потім з'являються як `App\UI\Blog\Admin` і подібним чином. Щоб звернутися до доповідача `Dashboard` у підмодулі `Admin`, ми посилаємося на нього як `Blog:Admin:Dashboard`. -Розгалуження може бути настільки глибоким, наскільки ви захочете, тому ви можете створювати підмодулі. +Вкладеність може бути настільки глибокою, наскільки це необхідно, що дозволяє створювати підмодулі. + +Наприклад, якщо в адмініструванні ви маєте багато доповідачів, пов'язаних з управлінням замовленнями, таких як `OrderDetail`, `OrderEdit`, `OrderDispatch` і т.д., ви можете створити модуль `Order`, в якому будуть організовані доповідачі `Detail`, `Edit`, `Dispatch` та інші. Створення посилань .[#toc-creating-links] @@ -99,49 +115,69 @@ class DashboardPresenter extends Nette\Application\UI\Presenter Див. [розділ про маршрутизацію |routing#modules]. -Складання карти .[#toc-mapping] +Картографування .[#toc-mapping] ------------------------------- -Визначає правила, за якими ім'я класу виводиться з імені ведучого. Ми записуємо їх у [конфігурацію |configuration] під ключем `application › mapping`. +Відображення визначає правила отримання імені класу з імені доповідача. Ці правила задаються у [конфігурації |configuration] під ключем `application › mapping`. + +Структури каталогів, згадані раніше на цій сторінці, базуються на наступному відображенні: + +```neon +application: + mapping: App\UI\*\**Presenter +``` -Почнемо з прикладу, в якому не використовуються модулі. Ми просто хочемо, щоб класи ведучого мали простір імен `App\Presenters`. Тобто ми хочемо, щоб ведучий, наприклад, `Home` відображався на клас `App\Presenters\HomePresenter`. Цього можна досягти за допомогою такої конфігурації: +Як працює мапування? Для кращого розуміння, давайте спочатку уявимо додаток без модулів. Ми хочемо, щоб класи доповідача потрапляли до простору імен `App\UI`, щоб доповідач `Home` відображався у клас `App\UI\HomePresenter`. Цього можна досягти за допомогою такої конфігурації: ```neon application: - mapping: App\Presenters\*Presenter + mapping: App\UI\*Presenter ``` -Ім'я презентера замінюється зірочкою, і в результаті виходить назва класу. Легко! +Це відображення працює шляхом заміни зірочки у масці `App\UI\*Presenter` на ім'я доповідача `Home`, в результаті чого ми отримаємо кінцеве ім'я класу `App\UI\HomePresenter`. Все просто! + +Однак, як ви можете бачити у прикладах у цій та інших главах, ми розміщуємо класи доповідачів у однойменних підкаталогах, наприклад, доповідач `Home` зіставляється з класом `App\UI\Home\HomePresenter`. Це досягається за допомогою подвоєння зірочки (потрібно Nette Application 3.2): + +```neon +application: + mapping: App\UI\**Presenter +``` -Якщо ми розділимо доповідачів на модулі, то для кожного модуля в нас може бути свій маппінг: +Тепер перейдемо до зіставлення доповідачів з модулями. Для кожного модуля ми можемо визначити специфічні відображення: ```neon application: mapping: - Front: App\Modules\Front\Presenters\*Presenter - Admin: App\Modules\Admin\Presenters\*Presenter + Front: App\UI\Front\**Presenter + Admin: App\UI\Admin\**Presenter Api: App\Api\*Presenter ``` -Тепер презентер `Front:Home` визначається класом `App\Modules\Front\HomePresenter`, а презентер `Admin:Dashboard` ` - `App\AdminModule\DashboardPresenter`. +Згідно з цією конфігурацією, доповідач `Front:Home` зіставляється з класом `App\UI\Front\Home\HomePresenter`, а доповідач `Api:OAuth` зіставляється з класом `App\Api\OAuthPresenter`. -Зручніше буде створити загальне правило (зірочка), яке замінить перші два правила і додасть додаткову зірочку тільки для модуля: +Оскільки модулі `Front` і `Admin` мають подібний підхід до зіставлення і таких модулів, ймовірно, буде більше, можна створити загальне правило, яке замінить їх. До маски класу буде додано нову зірочку для модуля: ```neon application: mapping: - *: App\Modules\*\Presenters\*Presenter + *: App\UI\*\**Presenter Api: App\Api\*Presenter ``` -Але що якщо ми використовуємо кілька вкладених модулів і в нас є, наприклад, провідний `Admin:User:Edit`? У цьому випадку сегмент із зірочкою, що представляє модуль для кожного рівня, буде просто повторюватися, і результатом буде клас `App\Modules\Admin\User\Presenters\EditPresenter`. +Для багаторівневих вкладених модулів, таких як доповідач `Admin:User:Edit`, сегмент зірочки повторюється для кожного рівня, в результаті чого утворюється клас `App\UI\Admin\User\Edit\EditPresenter`. -Альтернативною нотацією є використання масиву, що складається з трьох сегментів, замість рядка. Ця нотація еквівалентна попередній: +Альтернативним варіантом запису є використання масиву, що складається з трьох сегментів, замість рядка. Цей запис еквівалентний попередньому: ```neon application: mapping: - *: [App\Modules, *, Presenters\*Presenter] + *: [App\UI, *, **Presenter] + Api: [App\Api, '', *Presenter] ``` -Значення за замовчуванням - `*Module\*Presenter`. +Якщо в конфігурації є лише одне правило, загальне, ми можемо написати його коротко: + +```neon +application: + mapping: App\UI\*\**Presenter +``` diff --git a/application/uk/templates.texy b/application/uk/templates.texy index 2dc5f8f053..4b2fda15f0 100644 --- a/application/uk/templates.texy +++ b/application/uk/templates.texy @@ -34,35 +34,81 @@ Nette використовує систему шаблонів [Latte |latte:]. Він визначає блок `content`, який вставляється замість `{include content}` у макеті, а також перевизначає блок `title`, який перезаписує `{block title}` у макеті. Спробуйте уявити собі результат. -Пошук шаблонів .[#toc-search-for-templates] -------------------------------------------- +Пошук шаблонів .[#toc-template-lookup] +-------------------------------------- -Шлях до шаблонів визначається ведучим за допомогою простої логіки. Він спробує перевірити, чи є один із цих файлів, розташований відносно каталогу класу ведучого, де `` це ім'я поточного ведучого, а `` це ім'я поточної події: +У презентаторах вам не потрібно вказувати, який шаблон має бути відрендерений; фреймворк автоматично визначить шлях, полегшуючи вам кодування. -- `templates//.latte` -- `templates/..latte` +Якщо ви використовуєте структуру каталогів, де кожен презентер має власний каталог, просто розмістіть шаблон у цьому каталозі під назвою дії (тобто подання). Наприклад, для дії `default` використовуйте шаблон `default.latte`: -Якщо шаблон не буде знайдено, він спробує виконати пошук у каталозі `templates` на один рівень вище, тобто на тому ж рівні, що і каталог з класом presenter. +/--pre +app/ +└── UI/ + └── Home/ + ├── HomePresenter.php + └── default.latte +\-- -Якщо шаблон не буде знайдено і там, у відповідь буде видано [помилку 404 |presenters#Error 404 etc.]. +Якщо ви використовуєте структуру, де доповідачі знаходяться разом в одному каталозі, а шаблони - в папці `templates`, збережіть її або у файлі `..latte` або `/.latte`: -Ви також можете змінити вигляд за допомогою `$this->setView('jineView')`. Або, замість прямого пошуку, вкажіть ім'я файлу шаблону за допомогою `$this->template->setFile('/path/to/template.latte')`. +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── Home.default.latte ← 1st variant + └── Home/ + └── default.latte ← 2nd variant +\-- + +Директорію `templates` також можна розмістити на один рівень вище, на тому ж рівні, що і директорію з класами ведучого. + +Якщо шаблон не знайдено, доповідач видає [помилку 404 - сторінка не знайдена |presenters#Error 404 etc]. + +Ви можете змінити вигляд за допомогою `$this->setView('anotherView')`. Також можна безпосередньо вказати файл шаблону за допомогою `$this->template->setFile('/path/to/template.latte')`. .[note] -Файли, в яких здійснюється пошук шаблонів, можна змінити, наклавши метод [formatTemplateFiles() |api:Nette\Application\UI\Presenter::formatTemplateFiles()], який повертає масив можливих імен файлів. +Файли, в яких шукаються шаблони, можна змінити, перевизначивши метод [formatTemplateFiles( |api:Nette\Application\UI\Presenter::formatTemplateFiles()]), який повертає масив можливих імен файлів. + + +Пошук шаблонів макетів .[#toc-layout-template-lookup] +----------------------------------------------------- + +Nette також автоматично шукає файл макета. + +Якщо ви використовуєте структуру каталогів, де кожен доповідач має власний каталог, розмістіть макет або в папці доповідача, якщо він стосується лише його, або на рівень вище, якщо він є спільним для кількох доповідачів: + +/--pre +app/ +└── UI/ + ├── @layout.latte ← common layout + └── Home/ + ├── @layout.latte ← only for Home presenter + ├── HomePresenter.php + └── default.latte +\-- + +Якщо ви використовуєте структуру, в якій ведучі згруповані в одному каталозі, а шаблони знаходяться в папці `templates`, макет буде знаходитися в наступних місцях: -У цих файлах очікується компонування: +/--pre +app/ +└── Presenters/ + ├── HomePresenter.php + └── templates/ + ├── @layout.latte ← common layout + ├── Home.@layout.latte ← only for Home, 1st variant + └── Home/ + └── @layout.latte ← only for Home, 2nd variant +\-- -- `templates//@.latte` -- `templates/.@.latte` -- `templates/@.latte` макет, спільний для кількох доповідачів +Якщо доповідач знаходиться в [модулі |modules], він також буде шукати далі по дереву каталогів відповідно до вкладеності модуля. -Де `` це ім'я поточного ведучого і `` це ім'я макета, яке за замовчуванням дорівнює `'layout'`. Ім'я може бути змінено за допомогою `$this->setLayout('jinyLayout')`, тому будуть випробувані файли `@jinyLayout.latte`. +Назву шаблону можна змінити за допомогою `$this->setLayout('layoutAdmin')` і тоді вона буде очікуватися у файлі `@layoutAdmin.latte`. Ви також можете безпосередньо вказати файл шаблону розкладки за допомогою `$this->setLayout('/path/to/template.latte')`. -Ви також можете безпосередньо вказати ім'я файлу шаблону макета за допомогою `$this->setLayout('/path/to/template.latte')`. Використання `$this->setLayout(false)` відключає відстеження макета. +Використання `$this->setLayout(false)` або тегу `{layout none}` всередині шаблону вимикає пошук макетів. .[note] -Файли, в яких здійснюється пошук шаблонів макета, можна змінити, наклавши метод [formatLayoutTemplateFiles() |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()], який повертає масив можливих імен файлів. +Файли, в яких шукаються шаблони макетів, можна змінити, перевизначивши метод [formatLayoutTemplateFiles( |api:Nette\Application\UI\Presenter::formatLayoutTemplateFiles()]), який повертає масив можливих імен файлів. Змінні в шаблоні .[#toc-variables-in-the-template] @@ -104,7 +150,7 @@ class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template Ви також можете дозволити собі розкіш шепотіти в шаблонах, просто встановіть плагін Latte в PhpStorm і помістіть ім'я класу на початок шаблону, докладнішу інформацію дивіться в статті "Latte: як набирати систему":https://blog.nette.org/uk/latte-yak-koristuvatisya-sistemoyu-tipiv: ```latte -{templateType App\Presenters\ArticleTemplate} +{templateType App\UI\Article\ArticleTemplate} ... ``` @@ -176,7 +222,7 @@ public function beforeRender(): void Latte версії 3 пропонує більш просунутий спосіб створення [розширення |latte:creating-extension] для кожного веб-проекту. Ось короткий приклад такого класу: ```php -namespace App\Templating; +namespace App\UI\Accessory; final class LatteExtension extends Latte\Extension { @@ -214,7 +260,7 @@ final class LatteExtension extends Latte\Extension ```neon latte: extensions: - - App\Templating\LatteExtension + - App\UI\Accessory\LatteExtension ``` From 5a8ec70d52fde324f51b2afa370da907a770a260 Mon Sep 17 00:00:00 2001 From: David Grudl Date: Thu, 18 Apr 2024 18:04:12 +0200 Subject: [PATCH 02/47] new directory structure throughout documentation --- application/bg/routing.texy | 10 +++---- application/cs/routing.texy | 10 +++---- application/de/routing.texy | 10 +++---- application/el/routing.texy | 10 +++---- application/en/routing.texy | 10 +++---- application/es/routing.texy | 10 +++---- application/fr/routing.texy | 10 +++---- application/hu/routing.texy | 10 +++---- application/it/routing.texy | 10 +++---- application/pl/routing.texy | 10 +++---- application/pt/routing.texy | 10 +++---- application/ro/routing.texy | 10 +++---- application/ru/routing.texy | 10 +++---- application/sl/routing.texy | 10 +++---- application/tr/routing.texy | 10 +++---- application/uk/routing.texy | 10 +++---- best-practices/bg/composer.texy | 2 +- .../bg/lets-create-contact-form.texy | 2 +- best-practices/bg/pagination.texy | 10 +++---- best-practices/cs/composer.texy | 2 +- .../cs/lets-create-contact-form.texy | 2 +- best-practices/cs/pagination.texy | 10 +++---- best-practices/de/composer.texy | 2 +- .../de/lets-create-contact-form.texy | 2 +- best-practices/de/pagination.texy | 10 +++---- best-practices/el/composer.texy | 2 +- .../el/lets-create-contact-form.texy | 2 +- best-practices/el/pagination.texy | 10 +++---- best-practices/en/composer.texy | 2 +- .../en/lets-create-contact-form.texy | 2 +- best-practices/en/pagination.texy | 10 +++---- best-practices/es/composer.texy | 2 +- .../es/lets-create-contact-form.texy | 2 +- best-practices/es/pagination.texy | 10 +++---- best-practices/fr/composer.texy | 2 +- .../fr/lets-create-contact-form.texy | 2 +- best-practices/fr/pagination.texy | 10 +++---- best-practices/hu/composer.texy | 2 +- .../hu/lets-create-contact-form.texy | 2 +- best-practices/hu/pagination.texy | 10 +++---- best-practices/it/composer.texy | 2 +- .../it/lets-create-contact-form.texy | 2 +- best-practices/it/pagination.texy | 10 +++---- best-practices/pl/composer.texy | 2 +- .../pl/lets-create-contact-form.texy | 2 +- best-practices/pl/pagination.texy | 10 +++---- best-practices/pt/composer.texy | 2 +- .../pt/lets-create-contact-form.texy | 2 +- best-practices/pt/pagination.texy | 10 +++---- best-practices/ro/composer.texy | 2 +- .../ro/lets-create-contact-form.texy | 2 +- best-practices/ro/pagination.texy | 10 +++---- best-practices/ru/composer.texy | 2 +- .../ru/lets-create-contact-form.texy | 2 +- best-practices/ru/pagination.texy | 10 +++---- best-practices/sl/composer.texy | 2 +- .../sl/lets-create-contact-form.texy | 2 +- best-practices/sl/pagination.texy | 10 +++---- best-practices/tr/composer.texy | 2 +- .../tr/lets-create-contact-form.texy | 2 +- best-practices/tr/pagination.texy | 10 +++---- best-practices/uk/composer.texy | 2 +- .../uk/lets-create-contact-form.texy | 2 +- best-practices/uk/pagination.texy | 10 +++---- dependency-injection/bg/configuration.texy | 2 +- dependency-injection/bg/factory.texy | 2 +- dependency-injection/cs/configuration.texy | 2 +- dependency-injection/cs/factory.texy | 2 +- dependency-injection/de/configuration.texy | 2 +- dependency-injection/de/factory.texy | 2 +- dependency-injection/el/configuration.texy | 2 +- dependency-injection/el/factory.texy | 2 +- dependency-injection/en/configuration.texy | 2 +- dependency-injection/en/factory.texy | 2 +- dependency-injection/es/configuration.texy | 2 +- dependency-injection/es/factory.texy | 2 +- dependency-injection/fr/configuration.texy | 2 +- dependency-injection/fr/factory.texy | 2 +- dependency-injection/hu/configuration.texy | 2 +- dependency-injection/hu/factory.texy | 2 +- dependency-injection/it/configuration.texy | 2 +- dependency-injection/it/factory.texy | 2 +- dependency-injection/ja/configuration.texy | 2 +- dependency-injection/ja/factory.texy | 2 +- dependency-injection/pl/configuration.texy | 2 +- dependency-injection/pl/factory.texy | 2 +- dependency-injection/pt/configuration.texy | 2 +- dependency-injection/pt/factory.texy | 2 +- dependency-injection/ro/configuration.texy | 2 +- dependency-injection/ro/factory.texy | 2 +- dependency-injection/ru/configuration.texy | 2 +- dependency-injection/ru/factory.texy | 2 +- dependency-injection/sl/configuration.texy | 2 +- dependency-injection/sl/factory.texy | 2 +- dependency-injection/tr/configuration.texy | 2 +- dependency-injection/tr/factory.texy | 2 +- dependency-injection/uk/configuration.texy | 2 +- dependency-injection/uk/factory.texy | 2 +- forms/bg/in-presenter.texy | 4 +-- forms/cs/in-presenter.texy | 4 +-- forms/de/in-presenter.texy | 4 +-- forms/el/in-presenter.texy | 4 +-- forms/en/in-presenter.texy | 4 +-- forms/es/in-presenter.texy | 4 +-- forms/fr/in-presenter.texy | 4 +-- forms/hu/in-presenter.texy | 4 +-- forms/it/in-presenter.texy | 4 +-- forms/pl/in-presenter.texy | 4 +-- forms/pt/in-presenter.texy | 4 +-- forms/ro/in-presenter.texy | 4 +-- forms/ru/in-presenter.texy | 4 +-- forms/sl/in-presenter.texy | 4 +-- forms/tr/in-presenter.texy | 4 +-- forms/uk/in-presenter.texy | 4 +-- latte/bg/template-inheritance.texy | 2 +- latte/de/template-inheritance.texy | 2 +- latte/el/template-inheritance.texy | 2 +- latte/en/template-inheritance.texy | 2 +- latte/es/template-inheritance.texy | 2 +- latte/fr/template-inheritance.texy | 2 +- latte/hu/template-inheritance.texy | 2 +- latte/it/template-inheritance.texy | 2 +- latte/ja/template-inheritance.texy | 2 +- latte/pl/template-inheritance.texy | 2 +- latte/pt/template-inheritance.texy | 2 +- latte/ro/template-inheritance.texy | 2 +- latte/ru/template-inheritance.texy | 2 +- latte/sl/template-inheritance.texy | 2 +- latte/tr/template-inheritance.texy | 2 +- latte/uk/template-inheritance.texy | 2 +- quickstart/bg/@home.texy | 12 ++++---- quickstart/bg/authentication.texy | 22 +++++++------- quickstart/bg/comments.texy | 14 ++++----- quickstart/bg/creating-posts.texy | 24 +++++++-------- quickstart/bg/home-page.texy | 25 ++++++++-------- quickstart/bg/model.texy | 4 +-- quickstart/bg/single-post.texy | 28 +++++++++--------- quickstart/cs/@home.texy | 12 ++++---- quickstart/cs/authentication.texy | 18 +++++------ quickstart/cs/comments.texy | 12 ++++---- quickstart/cs/creating-posts.texy | 22 +++++++------- quickstart/cs/home-page.texy | 21 +++++++------ quickstart/cs/model.texy | 4 +-- quickstart/cs/single-post.texy | 26 ++++++++-------- quickstart/de/@home.texy | 12 ++++---- quickstart/de/authentication.texy | 18 +++++------ quickstart/de/comments.texy | 12 ++++---- quickstart/de/creating-posts.texy | 22 +++++++------- quickstart/de/home-page.texy | 21 +++++++------ quickstart/de/model.texy | 4 +-- quickstart/de/single-post.texy | 26 ++++++++-------- quickstart/el/@home.texy | 12 ++++---- quickstart/el/authentication.texy | 18 +++++------ quickstart/el/comments.texy | 12 ++++---- quickstart/el/creating-posts.texy | 22 +++++++------- quickstart/el/home-page.texy | 21 +++++++------ quickstart/el/model.texy | 4 +-- quickstart/el/single-post.texy | 26 ++++++++-------- quickstart/en/@home.texy | 12 ++++---- quickstart/en/authentication.texy | 18 +++++------ quickstart/en/comments.texy | 12 ++++---- quickstart/en/creating-posts.texy | 22 +++++++------- quickstart/en/home-page.texy | 21 +++++++------ quickstart/en/model.texy | 4 +-- quickstart/en/single-post.texy | 26 ++++++++-------- quickstart/es/@home.texy | 12 ++++---- quickstart/es/authentication.texy | 18 +++++------ quickstart/es/comments.texy | 12 ++++---- quickstart/es/creating-posts.texy | 22 +++++++------- quickstart/es/home-page.texy | 21 +++++++------ quickstart/es/model.texy | 4 +-- quickstart/es/single-post.texy | 26 ++++++++-------- quickstart/files/qs-tracy.avif | Bin 0 -> 14828 bytes quickstart/files/qs-tracy.webp | Bin 40154 -> 0 bytes quickstart/fr/@home.texy | 12 ++++---- quickstart/fr/authentication.texy | 18 +++++------ quickstart/fr/comments.texy | 12 ++++---- quickstart/fr/creating-posts.texy | 22 +++++++------- quickstart/fr/home-page.texy | 21 +++++++------ quickstart/fr/model.texy | 4 +-- quickstart/fr/single-post.texy | 26 ++++++++-------- quickstart/hu/@home.texy | 12 ++++---- quickstart/hu/authentication.texy | 18 +++++------ quickstart/hu/comments.texy | 12 ++++---- quickstart/hu/creating-posts.texy | 22 +++++++------- quickstart/hu/home-page.texy | 21 +++++++------ quickstart/hu/model.texy | 4 +-- quickstart/hu/single-post.texy | 26 ++++++++-------- quickstart/it/@home.texy | 12 ++++---- quickstart/it/authentication.texy | 18 +++++------ quickstart/it/comments.texy | 12 ++++---- quickstart/it/creating-posts.texy | 22 +++++++------- quickstart/it/home-page.texy | 21 +++++++------ quickstart/it/model.texy | 4 +-- quickstart/it/single-post.texy | 26 ++++++++-------- quickstart/pl/@home.texy | 12 ++++---- quickstart/pl/authentication.texy | 18 +++++------ quickstart/pl/comments.texy | 12 ++++---- quickstart/pl/creating-posts.texy | 22 +++++++------- quickstart/pl/home-page.texy | 21 +++++++------ quickstart/pl/model.texy | 4 +-- quickstart/pl/single-post.texy | 26 ++++++++-------- quickstart/pt/@home.texy | 12 ++++---- quickstart/pt/authentication.texy | 18 +++++------ quickstart/pt/comments.texy | 12 ++++---- quickstart/pt/creating-posts.texy | 22 +++++++------- quickstart/pt/home-page.texy | 21 +++++++------ quickstart/pt/model.texy | 4 +-- quickstart/pt/single-post.texy | 26 ++++++++-------- quickstart/ro/@home.texy | 12 ++++---- quickstart/ro/authentication.texy | 18 +++++------ quickstart/ro/comments.texy | 12 ++++---- quickstart/ro/creating-posts.texy | 22 +++++++------- quickstart/ro/home-page.texy | 21 +++++++------ quickstart/ro/model.texy | 4 +-- quickstart/ro/single-post.texy | 26 ++++++++-------- quickstart/ru/@home.texy | 12 ++++---- quickstart/ru/authentication.texy | 22 +++++++------- quickstart/ru/comments.texy | 14 ++++----- quickstart/ru/creating-posts.texy | 24 +++++++-------- quickstart/ru/home-page.texy | 25 ++++++++-------- quickstart/ru/model.texy | 4 +-- quickstart/ru/single-post.texy | 28 +++++++++--------- quickstart/sl/@home.texy | 12 ++++---- quickstart/sl/authentication.texy | 18 +++++------ quickstart/sl/comments.texy | 12 ++++---- quickstart/sl/creating-posts.texy | 22 +++++++------- quickstart/sl/home-page.texy | 21 +++++++------ quickstart/sl/model.texy | 4 +-- quickstart/sl/single-post.texy | 26 ++++++++-------- quickstart/tr/@home.texy | 12 ++++---- quickstart/tr/authentication.texy | 18 +++++------ quickstart/tr/comments.texy | 12 ++++---- quickstart/tr/creating-posts.texy | 22 +++++++------- quickstart/tr/home-page.texy | 21 +++++++------ quickstart/tr/model.texy | 4 +-- quickstart/tr/single-post.texy | 26 ++++++++-------- quickstart/uk/@home.texy | 12 ++++---- quickstart/uk/authentication.texy | 22 +++++++------- quickstart/uk/comments.texy | 14 ++++----- quickstart/uk/creating-posts.texy | 24 +++++++-------- quickstart/uk/home-page.texy | 25 ++++++++-------- quickstart/uk/model.texy | 4 +-- quickstart/uk/single-post.texy | 28 +++++++++--------- robot-loader/bg/@home.texy | 2 +- robot-loader/cs/@home.texy | 2 +- robot-loader/de/@home.texy | 2 +- robot-loader/el/@home.texy | 2 +- robot-loader/en/@home.texy | 2 +- robot-loader/es/@home.texy | 2 +- robot-loader/fr/@home.texy | 2 +- robot-loader/hu/@home.texy | 2 +- robot-loader/it/@home.texy | 2 +- robot-loader/pl/@home.texy | 2 +- robot-loader/pt/@home.texy | 2 +- robot-loader/ro/@home.texy | 2 +- robot-loader/ru/@home.texy | 2 +- robot-loader/sl/@home.texy | 2 +- robot-loader/tr/@home.texy | 2 +- robot-loader/uk/@home.texy | 2 +- tracy/bg/guide.texy | 6 ++-- tracy/cs/guide.texy | 6 ++-- tracy/de/guide.texy | 6 ++-- tracy/el/guide.texy | 6 ++-- tracy/en/guide.texy | 6 ++-- tracy/es/guide.texy | 6 ++-- tracy/fr/guide.texy | 6 ++-- tracy/hu/guide.texy | 6 ++-- tracy/it/guide.texy | 6 ++-- tracy/pl/guide.texy | 6 ++-- tracy/pt/guide.texy | 6 ++-- tracy/ro/guide.texy | 6 ++-- tracy/ru/guide.texy | 6 ++-- tracy/sl/guide.texy | 6 ++-- tracy/tr/guide.texy | 6 ++-- tracy/uk/guide.texy | 6 ++-- 276 files changed, 1255 insertions(+), 1303 deletions(-) create mode 100644 quickstart/files/qs-tracy.avif delete mode 100644 quickstart/files/qs-tracy.webp diff --git a/application/bg/routing.texy b/application/bg/routing.texy index 300a7755e2..e71cd50516 100644 --- a/application/bg/routing.texy +++ b/application/bg/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Интеграция .[#toc-integration] ============================== -За да свържем маршрутизатора си с приложението, трябва да информираме за това контейнера DI. Най-лесният начин е да се подготви фабрика, която ще създаде обект маршрутизатор, и да се каже на конфигурацията на контейнера да го използва. Да предположим, че напишем метод за това, `App\Router\RouterFactory::createRouter()`: +За да свържем маршрутизатора си с приложението, трябва да информираме за това контейнера DI. Най-лесният начин е да се подготви фабрика, която ще създаде обект маршрутизатор, и да се каже на конфигурацията на контейнера да го използва. Да предположим, че напишем метод за това, `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ class RouterFactory ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Всички зависимости, като например връзки към бази данни и т.н., се предават на метода на фабриката като параметри, като се използва [автоматично свързване |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ $router->addRoute(/* ... */); Затова отново ще добавим метод, който ще създаде например маршрутизатор: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Или ще създадем обектите директно: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/cs/routing.texy b/application/cs/routing.texy index 3f58166681..adb92c1cae 100644 --- a/application/cs/routing.texy +++ b/application/cs/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Začlenění do aplikace ===================== -Abychom vytvořený router zapojili do aplikace, musíme o něm říci DI kontejneru. Nejsnazší cesta je připravit továrnu, která objekt routeru vyrobí, a sdělit v konfiguraci kontejneru, že ji má použít. Dejme tomu, že k tomu účelu napíšeme metodu `App\Router\RouterFactory::createRouter()`: +Abychom vytvořený router zapojili do aplikace, musíme o něm říci DI kontejneru. Nejsnazší cesta je připravit továrnu, která objekt routeru vyrobí, a sdělit v konfiguraci kontejneru, že ji má použít. Dejme tomu, že k tomu účelu napíšeme metodu `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Do [konfigurace |dependency-injection:services] pak zapíšeme: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Jakékoliv závislosti, třeba na databázi atd, se předají tovární metodě jako její parametry pomocí [autowiringu|dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Samostatným použitím myslíme využití schopností routeru v aplikaci, kter Takže opět si vytvoříme metodu, která nám sestaví router, např.: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Anebo objekty přímo vyrobíme: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/de/routing.texy b/application/de/routing.texy index dac42c271d..d398f7f759 100644 --- a/application/de/routing.texy +++ b/application/de/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Einbindung .[#toc-integration] ============================== -Um unseren Router in die Anwendung einzubinden, müssen wir ihn dem DI-Container mitteilen. Am einfachsten ist es, die Fabrik vorzubereiten, die das Router-Objekt erstellt, und der Container-Konfiguration mitzuteilen, dass sie es verwenden soll. Schreiben wir also eine Methode für diesen Zweck `App\Router\RouterFactory::createRouter()`: +Um unseren Router in die Anwendung einzubinden, müssen wir ihn dem DI-Container mitteilen. Am einfachsten ist es, die Fabrik vorzubereiten, die das Router-Objekt erstellt, und der Container-Konfiguration mitzuteilen, dass sie es verwenden soll. Schreiben wir also eine Methode für diesen Zweck `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Dann schreiben wir in [configuration |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Alle Abhängigkeiten, wie z. B. eine Datenbankverbindung usw., werden der Factory-Methode als Parameter über [Autowiring |dependency-injection:autowiring] übergeben: @@ -663,7 +663,7 @@ Unter getrennter Nutzung verstehen wir die Verwendung der Router-Funktionen in e Wir werden also wieder eine Methode erstellen, die einen Router aufbaut, zum Beispiel: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Oder wir erstellen die Objekte direkt: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/el/routing.texy b/application/el/routing.texy index 448fa6f67b..cb79da06a4 100644 --- a/application/el/routing.texy +++ b/application/el/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Ενσωμάτωση .[#toc-integration] ============================== -Για να συνδέσουμε τον δρομολογητή μας στην εφαρμογή, πρέπει να ενημερώσουμε το DI container σχετικά με αυτόν. Ο ευκολότερος τρόπος είναι να προετοιμάσουμε το εργοστάσιο που θα κατασκευάσει το αντικείμενο του δρομολογητή και να πούμε στη διαμόρφωση του δοχείου να το χρησιμοποιήσει. Ας πούμε λοιπόν ότι γράφουμε μια μέθοδο για το σκοπό αυτό `App\Router\RouterFactory::createRouter()`: +Για να συνδέσουμε τον δρομολογητή μας στην εφαρμογή, πρέπει να ενημερώσουμε το DI container σχετικά με αυτόν. Ο ευκολότερος τρόπος είναι να προετοιμάσουμε το εργοστάσιο που θα κατασκευάσει το αντικείμενο του δρομολογητή και να πούμε στη διαμόρφωση του δοχείου να το χρησιμοποιήσει. Ας πούμε λοιπόν ότι γράφουμε μια μέθοδο για το σκοπό αυτό `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ class RouterFactory ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Οποιεσδήποτε εξαρτήσεις, όπως μια σύνδεση βάσης δεδομένων κ.λπ., περνούν στη μέθοδο factory ως παράμετροι με τη χρήση [αυτόματης σύνδεσης |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ $router->addRoute(/* ... */); Έτσι και πάλι θα δημιουργήσουμε μια μέθοδο που θα κατασκευάσει ένα δρομολογητή, για παράδειγμα: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Ή θα δημιουργήσουμε αντικείμενα απευθείας: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/en/routing.texy b/application/en/routing.texy index c35c692adb..9c49994566 100644 --- a/application/en/routing.texy +++ b/application/en/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integration =========== -In order to connect the our router into the application, we must tell the DI container about it. The easiest way is to prepare the factory that will build the router object and tell the container configuration to use it. So let's say we write a method for this purpose `App\Router\RouterFactory::createRouter()`: +In order to connect the our router into the application, we must tell the DI container about it. The easiest way is to prepare the factory that will build the router object and tell the container configuration to use it. So let's say we write a method for this purpose `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Then we write in [configuration |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Any dependencies, such as a database connection etc., are passed to the factory method as its parameters using [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ By separated usage, we mean the use of the router's capabilities in an applicati So again we will create a method that will build a router, for example: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Or we will create objects directly: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/es/routing.texy b/application/es/routing.texy index c6ed0f3950..8898449791 100644 --- a/application/es/routing.texy +++ b/application/es/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integración .[#toc-integration] =============================== -Para conectar nuestro router a la aplicación, debemos informar al contenedor DI sobre él. La forma más sencilla es preparar la fábrica que construirá el objeto router y decirle a la configuración del contenedor que lo utilice. Digamos que escribimos un método para este propósito `App\Router\RouterFactory::createRouter()`: +Para conectar nuestro router a la aplicación, debemos informar al contenedor DI sobre él. La forma más sencilla es preparar la fábrica que construirá el objeto router y decirle a la configuración del contenedor que lo utilice. Digamos que escribimos un método para este propósito `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Luego escribimos en [configuración |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Cualquier dependencia, como una conexión de base de datos, etc., se pasa al método de fábrica como sus parámetros utilizando [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Por uso separado, nos referimos al uso de las capacidades del router en una apli Así que de nuevo crearemos un método que construirá un enrutador, por ejemplo ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); O crearemos los objetos directamente: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/fr/routing.texy b/application/fr/routing.texy index 9fe5d5e4a6..3f1cb29675 100644 --- a/application/fr/routing.texy +++ b/application/fr/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Intégration .[#toc-integration] =============================== -Afin de connecter notre routeur à l'application, nous devons en informer le conteneur DI. Le moyen le plus simple est de préparer la fabrique qui construira l'objet routeur et de dire à la configuration du conteneur de l'utiliser. Disons que nous écrivons une méthode dans ce but `App\Router\RouterFactory::createRouter()`: +Afin de connecter notre routeur à l'application, nous devons en informer le conteneur DI. Le moyen le plus simple est de préparer la fabrique qui construira l'objet routeur et de dire à la configuration du conteneur de l'utiliser. Disons que nous écrivons une méthode dans ce but `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Puis nous écrivons dans la [configuration |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Toutes les dépendances, telles qu'une connexion à une base de données, etc., sont transmises à la méthode factory en tant que paramètres en utilisant le [câblage automatique |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Par utilisation séparée, nous entendons l'utilisation des capacités du routeu Donc encore une fois nous allons créer une méthode qui va construire un routeur, par exemple : ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Ou bien nous créerons directement des objets : ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/hu/routing.texy b/application/hu/routing.texy index 5cf399296b..c2b8f71eda 100644 --- a/application/hu/routing.texy +++ b/application/hu/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integráció .[#toc-integration] ============================== -Ahhoz, hogy a routerünket az alkalmazásba kapcsoljuk, tájékoztatnunk kell róla a DI konténert. A legegyszerűbb, ha elkészítjük a gyárat, amely a router objektumot fogja felépíteni, és megmondjuk a konténer konfigurációjának, hogy használja azt. Tegyük fel, hogy írunk egy metódust erre a célra `App\Router\RouterFactory::createRouter()`: +Ahhoz, hogy a routerünket az alkalmazásba kapcsoljuk, tájékoztatnunk kell róla a DI konténert. A legegyszerűbb, ha elkészítjük a gyárat, amely a router objektumot fogja felépíteni, és megmondjuk a konténer konfigurációjának, hogy használja azt. Tegyük fel, hogy írunk egy metódust erre a célra `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Ezután beírjuk a [konfigurációba |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Az esetleges függőségeket, például az adatbázis-kapcsolatot stb., az [autowiring |dependency-injection:autowiring] segítségével paraméterként átadjuk a gyári metódusnak: @@ -663,7 +663,7 @@ A szeparált használat alatt a router képességeinek olyan alkalmazásban tör Tehát ismét létrehozunk egy metódust, amely létrehoz egy útválasztót, például: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Vagy közvetlenül hozzuk létre az objektumokat: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/it/routing.texy b/application/it/routing.texy index c01d4ac823..128e2edf26 100644 --- a/application/it/routing.texy +++ b/application/it/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integrazione .[#toc-integration] ================================ -Per collegare il nostro router all'applicazione, dobbiamo comunicarlo al contenitore DI. Il modo più semplice è preparare il factory che costruirà l'oggetto router e dire al contenitore di configurazione di usarlo. Diciamo quindi di scrivere un metodo a questo scopo `App\Router\RouterFactory::createRouter()`: +Per collegare il nostro router all'applicazione, dobbiamo comunicarlo al contenitore DI. Il modo più semplice è preparare il factory che costruirà l'oggetto router e dire al contenitore di configurazione di usarlo. Diciamo quindi di scrivere un metodo a questo scopo `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Poi scriviamo nella [configurazione |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Tutte le dipendenze, come la connessione al database, ecc. vengono passate al metodo factory come parametri, utilizzando l'[autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Per uso separato si intende l'uso delle funzionalità del router in un'applicazi Quindi creeremo di nuovo un metodo che costruirà un router, ad esempio: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Oppure creeremo direttamente gli oggetti: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/pl/routing.texy b/application/pl/routing.texy index 4ce1af8644..699114b6e0 100644 --- a/application/pl/routing.texy +++ b/application/pl/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integracja aplikacji .[#toc-integration] ======================================== -Aby zintegrować stworzony router z aplikacją, musimy powiedzieć o nim kontenerowi DI. Najprostszym sposobem na to jest przygotowanie fabryki tworzącej obiekt routera i powiedzenie konfiguracji kontenera, aby go użyć. Załóżmy, że w tym celu napiszemy metodę `App\Router\RouterFactory::createRouter()`: +Aby zintegrować stworzony router z aplikacją, musimy powiedzieć o nim kontenerowi DI. Najprostszym sposobem na to jest przygotowanie fabryki tworzącej obiekt routera i powiedzenie konfiguracji kontenera, aby go użyć. Załóżmy, że w tym celu napiszemy metodę `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Następnie wpisujemy do [konfiguracji |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Wszelkie zależności, na przykład od bazy danych itp, są przekazywane do metody fabrycznej jako jej parametry przez [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Przez użycie samodzielne rozumiemy wykorzystanie możliwości routera w aplikac Czyli znowu tworzymy metodę, która buduje dla nas np. router: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Możemy też wykonać obiekty bezpośrednio: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/pt/routing.texy b/application/pt/routing.texy index 6caf887e2d..d9c249abe6 100644 --- a/application/pt/routing.texy +++ b/application/pt/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integração .[#toc-integration] ============================== -A fim de conectar nosso roteador à aplicação, devemos informar o recipiente DI sobre isso. A maneira mais fácil é preparar a fábrica que irá construir o objeto roteador e dizer à configuração do contêiner para usá-lo. Portanto, digamos que escrevemos um método para este fim `App\Router\RouterFactory::createRouter()`: +A fim de conectar nosso roteador à aplicação, devemos informar o recipiente DI sobre isso. A maneira mais fácil é preparar a fábrica que irá construir o objeto roteador e dizer à configuração do contêiner para usá-lo. Portanto, digamos que escrevemos um método para este fim `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Em seguida, escrevemos em [configuração |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Quaisquer dependências, tais como uma conexão de banco de dados, etc., são passadas para o método de fábrica como seus parâmetros usando [a fiação automática |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Por uso separado, entendemos o uso das capacidades do roteador em uma aplicaçã Assim, mais uma vez, criaremos um método que construirá um roteador, por exemplo: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Ou criaremos objetos diretamente: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/ro/routing.texy b/application/ro/routing.texy index 4f80ca99be..125ac60d22 100644 --- a/application/ro/routing.texy +++ b/application/ro/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integrare .[#toc-integration] ============================= -Pentru a conecta routerul nostru la aplicație, trebuie să informăm containerul DI despre acesta. Cel mai simplu este să pregătim fabrica care va construi obiectul router și să spunem configurației containerului să o folosească. Să spunem că scriem o metodă în acest scop `App\Router\RouterFactory::createRouter()`: +Pentru a conecta routerul nostru la aplicație, trebuie să informăm containerul DI despre acesta. Cel mai simplu este să pregătim fabrica care va construi obiectul router și să spunem configurației containerului să o folosească. Să spunem că scriem o metodă în acest scop `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Apoi scriem în [configurație |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Orice dependență, cum ar fi o conexiune la o bază de date etc., este transmisă metodei factory ca parametru al acesteia folosind [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Prin utilizare separată se înțelege utilizarea capacităților routerului în Deci, din nou, vom crea o metodă care va construi un router, de exemplu: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Sau vom crea obiecte direct: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/ru/routing.texy b/application/ru/routing.texy index dd37c4fd4d..0e90a2aca6 100644 --- a/application/ru/routing.texy +++ b/application/ru/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Интеграция .[#toc-integration] ============================== -Чтобы подключить наш маршрутизатор к приложению, мы должны сообщить о нем контейнеру DI. Самый простой способ - это подготовить фабрику, которая будет создавать объект маршрутизатора, и сообщить конфигурации контейнера, чтобы она его использовала. Допустим, мы напишем для этого метод `App\Router\RouterFactory::createRouter()`: +Чтобы подключить наш маршрутизатор к приложению, мы должны сообщить о нем контейнеру DI. Самый простой способ - это подготовить фабрику, которая будет создавать объект маршрутизатора, и сообщить конфигурации контейнера, чтобы она его использовала. Допустим, мы напишем для этого метод `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ class RouterFactory ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Любые зависимости, такие как подключение к базе данных и т.д., передаются методу фабрики в качестве параметров с помощью [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ $router->addRoute(/* ... */); Итак, мы снова добавим метод, который будет создавать, например, маршрутизатор: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Или мы будем создавать объекты напрямую: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/sl/routing.texy b/application/sl/routing.texy index 0f717178bb..6430a8c631 100644 --- a/application/sl/routing.texy +++ b/application/sl/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Integracija .[#toc-integration] =============================== -Da bi naš usmerjevalnik povezali z aplikacijo, moramo o tem obvestiti vsebnik DI. Najlažje je pripraviti tovarno, ki bo zgradila objekt usmerjevalnika, in povedati konfiguraciji vsebnika, naj jo uporabi. Recimo, da v ta namen napišemo metodo `App\Router\RouterFactory::createRouter()`: +Da bi naš usmerjevalnik povezali z aplikacijo, moramo o tem obvestiti vsebnik DI. Najlažje je pripraviti tovarno, ki bo zgradila objekt usmerjevalnika, in povedati konfiguraciji vsebnika, naj jo uporabi. Recimo, da v ta namen napišemo metodo `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Nato zapišemo v [konfiguracijo |dependency-injection:services]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Vse odvisnosti, kot je povezava s podatkovno bazo itd., se metodi tovarne posredujejo kot njeni parametri z uporabo [samodejnega povezovanja |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ Z ločeno uporabo mislimo na uporabo zmožnosti usmerjevalnika v aplikaciji, ki Tako bomo ponovno ustvarili metodo, ki bo zgradila usmerjevalnik, na primer: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Ali pa bomo predmete ustvarili neposredno: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/tr/routing.texy b/application/tr/routing.texy index cbd1656234..d298997568 100644 --- a/application/tr/routing.texy +++ b/application/tr/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Entegrasyon .[#toc-integration] =============================== -Yönlendiricimizi uygulamaya bağlamak için DI konteynerine bunu söylemeliyiz. Bunun en kolay yolu router nesnesini oluşturacak fabrikayı hazırlamak ve container konfigürasyonuna bunu kullanmasını söylemektir. Diyelim ki bu amaçla bir metot yazdık `App\Router\RouterFactory::createRouter()`: +Yönlendiricimizi uygulamaya bağlamak için DI konteynerine bunu söylemeliyiz. Bunun en kolay yolu router nesnesini oluşturacak fabrikayı hazırlamak ve container konfigürasyonuna bunu kullanmasını söylemektir. Diyelim ki bu amaçla bir metot yazdık `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ Daha sonra [yapılandırmaya |dependency-injection:services] yazıyoruz: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Veritabanı bağlantısı vb. gibi tüm bağımlılıklar, [otomatik |dependency-injection:autowiring] bağlantı kullanılarak fabrika yöntemine parametreleri olarak aktarılır: @@ -663,7 +663,7 @@ Ayrı kullanımla, yönlendiricinin yeteneklerinin Nette Uygulaması ve sunucula Bu yüzden yine örneğin bir yönlendirici oluşturacak bir yöntem oluşturacağız: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Ya da doğrudan nesneler oluşturacağız: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/application/uk/routing.texy b/application/uk/routing.texy index c19046885b..f270ca67fd 100644 --- a/application/uk/routing.texy +++ b/application/uk/routing.texy @@ -477,10 +477,10 @@ $router->addRoute('index', /* ... */); Інтеграція .[#toc-integration] ============================== -Щоб підключити наш маршрутизатор до застосунку, ми повинні повідомити про нього контейнер DI. Найпростіший спосіб - це підготувати фабрику, яка буде створювати об'єкт маршрутизатора, і повідомити конфігурацію контейнера, щоб вона його використовувала. Припустимо, ми напишемо для цього метод `App\Router\RouterFactory::createRouter()`: +Щоб підключити наш маршрутизатор до застосунку, ми повинні повідомити про нього контейнер DI. Найпростіший спосіб - це підготувати фабрику, яка буде створювати об'єкт маршрутизатора, і повідомити конфігурацію контейнера, щоб вона його використовувала. Припустимо, ми напишемо для цього метод `App\Core\RouterFactory::createRouter()`: ```php -namespace App\Router; +namespace App\Core; use Nette\Application\Routers\RouteList; @@ -499,7 +499,7 @@ class RouterFactory ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter ``` Будь-які залежності, такі як підключення до бази даних тощо, передаються методу фабрики як параметри за допомогою [autowiring |dependency-injection:autowiring]: @@ -663,7 +663,7 @@ $router->addRoute(/* ... */); Отже, ми знову додамо метод, який буде створювати, наприклад, маршрутизатор: ```php -namespace App\Router; +namespace App\Core; use Nette\Routing\RouteList; @@ -694,7 +694,7 @@ $httpRequest = $container->getByType(Nette\Http\IRequest::class); Або ми будемо створювати об'єкти безпосередньо: ```php -$router = App\Router\RouterFactory::createRouter(); +$router = App\Core\RouterFactory::createRouter(); $httpRequest = (new Nette\Http\RequestFactory)->fromGlobals(); ``` diff --git a/best-practices/bg/composer.texy b/best-practices/bg/composer.texy index 13bf7df4cc..2852264f64 100644 --- a/best-practices/bg/composer.texy +++ b/best-practices/bg/composer.texy @@ -189,7 +189,7 @@ Packagist.org - глобално хранилище .[#toc-packagist-org-global- Впоследствие трябва да стартирате командата `composer dumpautoload` при всяка промяна и да позволите на таблиците на автоматичния модул да се възстановят. Това е изключително неудобно и е много по-добре да оставите тази задача на [RobotLoader |robot-loader:], който върши същата работа автоматично във фонов режим и много по-бързо. -Вторият вариант е да следвате [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Казано по-просто, това е система, в която пространствата от имена и имената на класовете съответстват на структурата на директориите и имената на файловете, т.е. `App\Router\RouterFactory` се намира в `/path/to/App/Router/RouterFactory.php`. Примерна конфигурация: +Вторият вариант е да следвате [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Казано по-просто, това е система, в която пространствата от имена и имената на класовете съответстват на структурата на директориите и имената на файловете, т.е. `App\Core\RouterFactory` се намира в `/path/to/App/Core/RouterFactory.php`. Примерна конфигурация: ```js { diff --git a/best-practices/bg/lets-create-contact-form.texy b/best-practices/bg/lets-create-contact-form.texy index b0f3d7ccf6..80a29d0e4e 100644 --- a/best-practices/bg/lets-create-contact-form.texy +++ b/best-practices/bg/lets-create-contact-form.texy @@ -39,7 +39,7 @@ class HomePresenter extends Presenter Но какво ще стане, ако потребителят не попълни някои полета? В такъв случай трябва да го уведомим, че това е задължително поле. Направихме това с метода `setRequired()`. Накрая добавихме и [събитие |nette:glossary#events] `onSuccess`, което се задейства, ако формулярът е изпратен успешно. В нашия случай то извиква метода `contactFormSucceeded`, който се грижи за обработката на изпратения формуляр. След малко ще добавим това към кода. -Нека компонентът `contantForm` бъде визуализиран в шаблона `templates/Home/default.latte`: +Нека компонентът `contantForm` бъде визуализиран в шаблона `Home/default.latte`: ```latte {block content} diff --git a/best-practices/bg/pagination.texy b/best-practices/bg/pagination.texy index 28256dd731..9d04ddc1b1 100644 --- a/best-practices/bg/pagination.texy +++ b/best-practices/bg/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository След това въвеждаме класа на модела в презентатора и в метода `render` правим справка за публикуваните статии, които предаваме на шаблона: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -В шаблона се грижим за извеждането на списъка със статии: +След това шаблонът `default.latte` ще се погрижи за изброяването на статиите: ```latte {block content} @@ -114,7 +113,7 @@ class ArticleRepository Също така разширяваме метода `render`, за да получим инстанцията Paginator, да я конфигурираме и да изберем желаните статии, които да се показват в шаблона. HomePresenter ще изглежда по следния начин: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Не е необходимо да създаваме Paginator в презентатора, вместо това ще използваме метода на обекта `Selection`, върнат от хранилището: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/cs/composer.texy b/best-practices/cs/composer.texy index 9ac10dc558..8ea7581472 100644 --- a/best-practices/cs/composer.texy +++ b/best-practices/cs/composer.texy @@ -189,7 +189,7 @@ Nicméně je možné používat Composer i pro načítání dalších tříd i m Následně je potřeba při každé změně spustit příkaz `composer dumpautoload` a nechat autoloadovací tabulky přegenerovat. To je nesmírně nepohodlné a daleko lepší je tento úkol svěřit [RobotLoaderu|robot-loader:], který stejnou činnost provádí automaticky na pozadí a mnohem rychleji. -Druhou možností je dodržovat [PSR-4|https://www.php-fig.org/psr/psr-4/]. Zjednodušeně řečeno jde o systém, kdy jmenné prostory a názvy tříd odpovídají adresářové struktuře a názvům souborů, tedy např. `App\Router\RouterFactory` bude v souboru `/path/to/App/Router/RouterFactory.php`. Příklad konfigurace: +Druhou možností je dodržovat [PSR-4|https://www.php-fig.org/psr/psr-4/]. Zjednodušeně řečeno jde o systém, kdy jmenné prostory a názvy tříd odpovídají adresářové struktuře a názvům souborů, tedy např. `App\Core\RouterFactory` bude v souboru `/path/to/App/Core/RouterFactory.php`. Příklad konfigurace: ```js { diff --git a/best-practices/cs/lets-create-contact-form.texy b/best-practices/cs/lets-create-contact-form.texy index 78f2f92886..80503acf55 100644 --- a/best-practices/cs/lets-create-contact-form.texy +++ b/best-practices/cs/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Jak vidíte, vytvořili jsme dvě metody. První metoda `createComponentContactF Ale co když uživatel nevyplní nějaké pole? V takovém případě bychom mu měli dát vědět, že je to povinné pole. Toho jsme docílili metodou `setRequired()`. Nakonec jsme přidali také [událost |nette:glossary#Události] `onSuccess`, která se spustí, pokud je formulář úspěšně odeslán. V našem případě zavolá metodu `contactFormSucceeded`, která se postará o zpracování odeslaného formuláře. To do kódu doplníme za okamžik. -Komponentu `contantForm` necháme vykreslit v šabloně `templates/Home/default.latte`: +Komponentu `contantForm` necháme vykreslit v šabloně `Home/default.latte`: ```latte {block content} diff --git a/best-practices/cs/pagination.texy b/best-practices/cs/pagination.texy index bf7d18a418..8a558bb0b7 100644 --- a/best-practices/cs/pagination.texy +++ b/best-practices/cs/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository V presenteru si pak injectujeme modelovou třídu a v render metodě si vyžádáme publikované články, které předáme do šablony: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -V šabloně se pak postaráme o výpis článků: +V šabloně `default.latte` se pak postaráme o výpis článků: ```latte {block content} @@ -114,7 +113,7 @@ Následně se pustíme do úprav presenteru. Do render metody budeme předávat Dále také render metodu rozšíříme o získání instance Paginatoru, jeho nastavení a výběru správných článků pro zobrazení v šabloně. HomePresenter bude po úpravách vypadat takto: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository V presenteru nemusíme vytvářet Paginator, použijeme místo něj metodu třídy `Selection`, kterou nám vrací repositář: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/de/composer.texy b/best-practices/de/composer.texy index 8910b9e603..10aed8c202 100644 --- a/best-practices/de/composer.texy +++ b/best-practices/de/composer.texy @@ -189,7 +189,7 @@ Es ist jedoch auch möglich, Composer zu verwenden, um andere Klassen außerhalb Anschließend müssen Sie bei jeder Änderung den Befehl `composer dumpautoload` ausführen und die Autoloader-Tabellen neu generieren lassen. Dies ist äußerst lästig, und es ist weitaus besser, diese Aufgabe [RobotLoader |robot-loader:] anzuvertrauen, der dieselbe Tätigkeit automatisch im Hintergrund und viel schneller durchführt. -Die zweite Möglichkeit ist, [PSR-4 |https://www.php-fig.org/psr/psr-4/] zu folgen. Einfach gesagt handelt es sich um ein System, bei dem die Namensräume und Klassennamen der Verzeichnisstruktur und den Dateinamen entsprechen, d. h. `App\Router\RouterFactory` befindet sich in der Datei `/path/to/App/Router/RouterFactory.php`. Beispiel für eine Konfiguration: +Die zweite Möglichkeit ist, [PSR-4 |https://www.php-fig.org/psr/psr-4/] zu folgen. Einfach gesagt handelt es sich um ein System, bei dem die Namensräume und Klassennamen der Verzeichnisstruktur und den Dateinamen entsprechen, d. h. `App\Core\RouterFactory` befindet sich in der Datei `/path/to/App/Core/RouterFactory.php`. Beispiel für eine Konfiguration: ```js { diff --git a/best-practices/de/lets-create-contact-form.texy b/best-practices/de/lets-create-contact-form.texy index 67b26710b2..886b452767 100644 --- a/best-practices/de/lets-create-contact-form.texy +++ b/best-practices/de/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Wie Sie sehen können, haben wir zwei Methoden erstellt. Die erste Methode `crea Was aber, wenn der Benutzer einige Felder nicht ausfüllt? In diesem Fall sollten wir ihn darauf hinweisen, dass es sich um ein Pflichtfeld handelt. Wir haben dies mit der Methode `setRequired()` getan. Schließlich haben wir auch ein [Ereignis |nette:glossary#events] `onSuccess` hinzugefügt, das ausgelöst wird, wenn das Formular erfolgreich abgeschickt wurde. In unserem Fall ruft es die Methode `contactFormSucceeded` auf, die sich um die Verarbeitung des übermittelten Formulars kümmert. Das fügen wir dem Code gleich hinzu. -Die Komponente `contantForm` soll in der Vorlage `templates/Home/default.latte` gerendert werden: +Die Komponente `contantForm` soll in der Vorlage `Home/default.latte` gerendert werden: ```latte {block content} diff --git a/best-practices/de/pagination.texy b/best-practices/de/pagination.texy index ef5a0920ad..245680368c 100644 --- a/best-practices/de/pagination.texy +++ b/best-practices/de/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository In den Presenter injizieren wir dann die Modellklasse, und in der Rendering-Methode fragen wir nach den veröffentlichten Artikeln, die wir an die Vorlage übergeben: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -In der Vorlage kümmern wir uns um das Rendern einer Artikelliste: +Die Vorlage `default.latte` kümmert sich dann um die Auflistung der Artikel: ```latte {block content} @@ -114,7 +113,7 @@ Der nächste Schritt besteht darin, den Präsentator zu bearbeiten. Wir werden d Wir erweitern die Render-Methode auch, um die Paginator-Instanz zu erhalten, sie einzurichten und die richtigen Artikel für die Anzeige in der Vorlage auszuwählen. Der HomePresenter wird wie folgt aussehen: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Wir müssen keinen Paginator im Presenter erstellen, sondern verwenden die Methode des `Selection` -Objekts, das vom Repository zurückgegeben wird: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/el/composer.texy b/best-practices/el/composer.texy index 410b88c45a..75f9e3f0bc 100644 --- a/best-practices/el/composer.texy +++ b/best-practices/el/composer.texy @@ -189,7 +189,7 @@ Packagist.org - Παγκόσμιο αποθετήριο .[#toc-packagist-org-glo Στη συνέχεια, είναι απαραίτητο να εκτελείτε την εντολή `composer dumpautoload` με κάθε αλλαγή και να αφήνετε τους πίνακες αυτόματης φόρτωσης να αναγεννώνται. Αυτό είναι εξαιρετικά άβολο και είναι πολύ καλύτερο να αναθέσετε αυτή την εργασία στο [RobotLoader |robot-loader:], το οποίο εκτελεί την ίδια δραστηριότητα αυτόματα στο παρασκήνιο και πολύ πιο γρήγορα. -Η δεύτερη επιλογή είναι να ακολουθήσετε το [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Με απλά λόγια, πρόκειται για ένα σύστημα όπου τα namespaces και τα ονόματα των κλάσεων αντιστοιχούν στη δομή των καταλόγων και των ονομάτων των αρχείων, δηλαδή το `App\Router\RouterFactory` βρίσκεται στο αρχείο `/path/to/App/Router/RouterFactory.php`. Παράδειγμα διαμόρφωσης: +Η δεύτερη επιλογή είναι να ακολουθήσετε το [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Με απλά λόγια, πρόκειται για ένα σύστημα όπου τα namespaces και τα ονόματα των κλάσεων αντιστοιχούν στη δομή των καταλόγων και των ονομάτων των αρχείων, δηλαδή το `App\Core\RouterFactory` βρίσκεται στο αρχείο `/path/to/App/Core/RouterFactory.php`. Παράδειγμα διαμόρφωσης: ```js { diff --git a/best-practices/el/lets-create-contact-form.texy b/best-practices/el/lets-create-contact-form.texy index aeded4979a..8cf6ab9a9f 100644 --- a/best-practices/el/lets-create-contact-form.texy +++ b/best-practices/el/lets-create-contact-form.texy @@ -39,7 +39,7 @@ class HomePresenter extends Presenter Τι γίνεται όμως αν ο χρήστης δεν συμπληρώσει κάποια πεδία; Σε αυτή την περίπτωση, θα πρέπει να τον ενημερώσουμε ότι πρόκειται για υποχρεωτικό πεδίο. Αυτό το κάναμε με τη μέθοδο `setRequired()`. Τέλος, προσθέσαμε και ένα [συμβάν |nette:glossary#events] `onSuccess`, το οποίο ενεργοποιείται αν η φόρμα υποβληθεί με επιτυχία. Στην περίπτωσή μας, καλεί τη μέθοδο `contactFormSucceeded`, η οποία αναλαμβάνει την επεξεργασία της υποβληθείσας φόρμας. Θα το προσθέσουμε αυτό στον κώδικα σε λίγο. -Αφήστε το στοιχείο `contantForm` να αποδοθεί στο πρότυπο `templates/Home/default.latte`: +Αφήστε το στοιχείο `contantForm` να αποδοθεί στο πρότυπο `Home/default.latte`: ```latte {block content} diff --git a/best-practices/el/pagination.texy b/best-practices/el/pagination.texy index 06fca7da8a..599f3ff25a 100644 --- a/best-practices/el/pagination.texy +++ b/best-practices/el/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Στον Presenter στη συνέχεια εισάγουμε την κλάση model και στη μέθοδο render θα ζητήσουμε τα δημοσιευμένα άρθρα που θα περάσουμε στο template: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -Στο πρότυπο, θα φροντίσουμε για την απόδοση μιας λίστας άρθρων: +Το πρότυπο `default.latte` θα αναλάβει στη συνέχεια την καταχώριση των άρθρων: ```latte {block content} @@ -114,7 +113,7 @@ class ArticleRepository Επεκτείνουμε επίσης τη μέθοδο render για να λάβουμε την περίπτωση Paginator, να τη ρυθμίσουμε και να επιλέξουμε τα σωστά άρθρα που θα εμφανίζονται στο πρότυπο. Το HomePresenter θα μοιάζει με αυτό: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Δεν χρειάζεται να δημιουργήσουμε Paginator στο Presenter, αντίθετα θα χρησιμοποιήσουμε τη μέθοδο του αντικειμένου `Selection` που επιστρέφεται από το αποθετήριο: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/en/composer.texy b/best-practices/en/composer.texy index bc65bb1c55..d8753b98bd 100644 --- a/best-practices/en/composer.texy +++ b/best-practices/en/composer.texy @@ -189,7 +189,7 @@ However, it is also possible to use Composer to load other classes outside the f Subsequently, it is necessary to run the command `composer dumpautoload` with each change and let the autoloading tables regenerate. This is extremely inconvenient, and it is far better to entrust this task to [RobotLoader|robot-loader:], which performs the same activity automatically in the background and much faster. -The second option is to follow [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Simply saying, it is a system where the namespaces and class names correspond to the directory structure and file names, ie `App\Router\RouterFactory` is located in the file `/path/to/App/Router/RouterFactory.php`. Configuration example: +The second option is to follow [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Simply saying, it is a system where the namespaces and class names correspond to the directory structure and file names, ie `App\Core\RouterFactory` is located in the file `/path/to/App/Core/RouterFactory.php`. Configuration example: ```js { diff --git a/best-practices/en/lets-create-contact-form.texy b/best-practices/en/lets-create-contact-form.texy index ad2472ed15..f00cad1b75 100644 --- a/best-practices/en/lets-create-contact-form.texy +++ b/best-practices/en/lets-create-contact-form.texy @@ -39,7 +39,7 @@ As you can see, we have created two methods. The first method `createComponentCo But what if the user doesn't fill in some fields? In that case, we should let him know that it is a required field. We did this with the `setRequired()` method. Finally, we also added an [event |nette:glossary#events] `onSuccess`, which is triggered if the form is submitted successfully. In our case, it calls the `contactFormSucceeded` method , which takes care of processing the submitted form. We'll add that to the code in a moment. -Let the `contantForm` component be rendered in the `templates/Home/default.latte` template: +Let the `contantForm` component be rendered in the `Home/default.latte` template: ```latte {block content} diff --git a/best-practices/en/pagination.texy b/best-practices/en/pagination.texy index 113ce80193..8fa2b98ace 100644 --- a/best-practices/en/pagination.texy +++ b/best-practices/en/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository In the Presenter we then inject the model class and in the render method we will ask for the published articles that we pass to the template: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -In the template, we will take care of rendering an articles list: +The `default.latte` template will then take care of listing the articles: ```latte {block content} @@ -114,7 +113,7 @@ The next step is to edit the presenter. We will forward the number of the curren We also expand the render method to get the Paginator instance, setting it up, and selecting the correct articles to display in the template. HomePresenter will look like this: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository We do not have to create Paginator in the Presenter, instead we will use the method of `Selection` object returned by the repository: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/es/composer.texy b/best-practices/es/composer.texy index e9fd4a1bf3..86cf99808a 100644 --- a/best-practices/es/composer.texy +++ b/best-practices/es/composer.texy @@ -189,7 +189,7 @@ Sin embargo, también es posible utilizar Composer para cargar otras clases fuer Posteriormente, es necesario ejecutar el comando `composer dumpautoload` con cada cambio y dejar que se regeneren las tablas de autocarga. Esto es extremadamente incómodo, y es mucho mejor confiar esta tarea a [RobotLoader |robot-loader:], que realiza la misma actividad automáticamente en segundo plano y mucho más rápido. -La segunda opción es seguir [PSR-4 |https://www.php-fig.org/psr/psr-4/]. En pocas palabras, se trata de un sistema en el que los espacios de nombres y los nombres de las clases se corresponden con la estructura de directorios y los nombres de los archivos, es decir, `App\Router\RouterFactory` se encuentra en el archivo `/path/to/App/Router/RouterFactory.php`. Ejemplo de configuración: +La segunda opción es seguir [PSR-4 |https://www.php-fig.org/psr/psr-4/]. En pocas palabras, se trata de un sistema en el que los espacios de nombres y los nombres de las clases se corresponden con la estructura de directorios y los nombres de los archivos, es decir, `App\Core\RouterFactory` se encuentra en el archivo `/path/to/App/Core/RouterFactory.php`. Ejemplo de configuración: ```js { diff --git a/best-practices/es/lets-create-contact-form.texy b/best-practices/es/lets-create-contact-form.texy index 2c7e155167..142740037a 100644 --- a/best-practices/es/lets-create-contact-form.texy +++ b/best-practices/es/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Como puedes ver, hemos creado dos métodos. El primer método `createComponentCo Pero, ¿qué pasa si el usuario no rellena algunos campos? En ese caso, debemos hacerle saber que se trata de un campo obligatorio. Hicimos esto con el método `setRequired()`. Por último, también añadimos un [evento |nette:glossary#events] `onSuccess`, que se activa si el formulario se envía correctamente. En nuestro caso, llama al método `contactFormSucceeded`, que se encarga de procesar el formulario enviado. Lo añadiremos al código en un momento. -Dejemos que el componente `contantForm` sea renderizado en la plantilla `templates/Home/default.latte`: +Dejemos que el componente `contantForm` sea renderizado en la plantilla `Home/default.latte`: ```latte {block content} diff --git a/best-practices/es/pagination.texy b/best-practices/es/pagination.texy index 44d6fddd5f..287b5d17a3 100644 --- a/best-practices/es/pagination.texy +++ b/best-practices/es/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository En el Presentador inyectamos entonces la clase modelo y en el método render pediremos los artículos publicados que pasamos al modelo: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -En la plantilla nos encargaremos de renderizar una lista de artículos: +La plantilla `default.latte` se encargará de listar los artículos: ```latte {block content} @@ -114,7 +113,7 @@ El siguiente paso es editar el presentador. Enviaremos el número de la página También expandimos el método render para obtener la instancia Paginator, configurándola, y seleccionando los artículos correctos para mostrar en la plantilla. HomePresenter tendrá este aspecto: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository No tenemos que crear Paginator en el Presentador, en su lugar utilizaremos el método del objeto `Selection` devuelto por el repositorio: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/fr/composer.texy b/best-practices/fr/composer.texy index d934b6499d..bb6de406f9 100644 --- a/best-practices/fr/composer.texy +++ b/best-practices/fr/composer.texy @@ -189,7 +189,7 @@ Toutefois, il est également possible d'utiliser Composer pour charger d'autres Par la suite, il est nécessaire d'exécuter la commande `composer dumpautoload` à chaque modification et de laisser les tables d'autoloadage se régénérer. Ceci est extrêmement gênant, et il est de loin préférable de confier cette tâche à [RobotLoader |robot-loader:], qui effectue la même activité automatiquement en arrière-plan et beaucoup plus rapidement. -La deuxième option consiste à suivre le [système PSR-4 |https://www.php-fig.org/psr/psr-4/]. Pour faire simple, il s'agit d'un système où les espaces de noms et les noms de classes correspondent à la structure des répertoires et aux noms de fichiers, c'est-à-dire que `App\Router\RouterFactory` est situé dans le fichier `/path/to/App/Router/RouterFactory.php`. Exemple de configuration : +La deuxième option consiste à suivre le [système PSR-4 |https://www.php-fig.org/psr/psr-4/]. Pour faire simple, il s'agit d'un système où les espaces de noms et les noms de classes correspondent à la structure des répertoires et aux noms de fichiers, c'est-à-dire que `App\Core\RouterFactory` est situé dans le fichier `/path/to/App/Core/RouterFactory.php`. Exemple de configuration : ```js { diff --git a/best-practices/fr/lets-create-contact-form.texy b/best-practices/fr/lets-create-contact-form.texy index 50afc50327..0b3b5b4409 100644 --- a/best-practices/fr/lets-create-contact-form.texy +++ b/best-practices/fr/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Comme vous pouvez le voir, nous avons créé deux méthodes. La première métho Mais que se passe-t-il si l'utilisateur ne remplit pas certains champs ? Dans ce cas, nous devons l'informer qu'il s'agit d'un champ obligatoire. C'est ce que nous avons fait avec la méthode `setRequired()`. Enfin, nous avons également ajouté un [événement |nette:glossary#events] `onSuccess`, qui est déclenché si le formulaire est soumis avec succès. Dans notre cas, il appelle la méthode `contactFormSucceeded`, qui se charge de traiter le formulaire soumis. Nous l'ajouterons au code dans un instant. -Laissez le composant `contantForm` être rendu dans le modèle `templates/Home/default.latte`: +Laissez le composant `contantForm` être rendu dans le modèle `Home/default.latte`: ```latte {block content} diff --git a/best-practices/fr/pagination.texy b/best-practices/fr/pagination.texy index cbd07b5ec6..cafbff84cc 100644 --- a/best-practices/fr/pagination.texy +++ b/best-practices/fr/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Dans le Presenter nous injectons ensuite la classe model et dans la méthode render nous allons demander les articles publiés que nous passons au template : ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -Dans le modèle, nous allons nous occuper de rendre une liste d'articles : +Le modèle `default.latte` se chargera ensuite de répertorier les articles : ```latte {block content} @@ -114,7 +113,7 @@ L'étape suivante consiste à modifier le présentateur. Nous allons transmettre Nous étendons également la méthode de rendu pour obtenir l'instance de Paginator, la configurer et sélectionner les bons articles à afficher dans le modèle. Le HomePresenter ressemblera à ceci : ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Nous n'avons pas besoin de créer le Paginator dans le Presenter, à la place nous utiliserons la méthode de l'objet `Selection` retourné par le référentiel : ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/hu/composer.texy b/best-practices/hu/composer.texy index fee65b20c5..d3c767b633 100644 --- a/best-practices/hu/composer.texy +++ b/best-practices/hu/composer.texy @@ -189,7 +189,7 @@ Lehetőség van azonban arra is, hogy a Composer segítségével a `vendor` mapp Ezt követően minden egyes változtatásnál el kell indítani a `composer dumpautoload` parancsot, és hagyni kell, hogy az autoloading táblák újratermelődjenek. Ez rendkívül kényelmetlen, és sokkal jobb, ha ezt a feladatot a [RobotLoaderre |robot-loader:] bízzuk, amely a háttérben automatikusan és sokkal gyorsabban végzi el ugyanezt a tevékenységet. -A második lehetőség a [PSR-4 |https://www.php-fig.org/psr/psr-4/] követése. Egyszerűen fogalmazva, ez egy olyan rendszer, ahol a névterek és az osztálynevek megfelelnek a könyvtárszerkezetnek és a fájlneveknek, azaz a `App\Router\RouterFactory` a `/path/to/App/Router/RouterFactory.php` fájlban található. Konfigurációs példa: +A második lehetőség a [PSR-4 |https://www.php-fig.org/psr/psr-4/] követése. Egyszerűen fogalmazva, ez egy olyan rendszer, ahol a névterek és az osztálynevek megfelelnek a könyvtárszerkezetnek és a fájlneveknek, azaz a `App\Core\RouterFactory` a `/path/to/App/Core/RouterFactory.php` fájlban található. Konfigurációs példa: ```js { diff --git a/best-practices/hu/lets-create-contact-form.texy b/best-practices/hu/lets-create-contact-form.texy index 0f6e9b14d8..f13d2dc808 100644 --- a/best-practices/hu/lets-create-contact-form.texy +++ b/best-practices/hu/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Mint látható, két metódust hoztunk létre. Az első metódus `createComponen De mi van akkor, ha a felhasználó nem tölt ki néhány mezőt? Ebben az esetben tudatnunk kell vele, hogy az adott mező kötelezően kitöltendő. Ezt a `setRequired()` metódussal tettük meg. Végül hozzáadtunk egy `onSuccess`[eseményt |nette:glossary#events] is, amely akkor lép működésbe, ha az űrlapot sikeresen elküldtük. A mi esetünkben meghívja a `contactFormSucceeded` metódust , amely a beküldött űrlap feldolgozásáról gondoskodik. Ezt is hozzáadjuk a kódhoz egy pillanat múlva. -Legyen a `contantForm` komponens megjelenítve a `templates/Home/default.latte` sablonban: +Legyen a `contantForm` komponens megjelenítve a `Home/default.latte` sablonban: ```latte {block content} diff --git a/best-practices/hu/pagination.texy b/best-practices/hu/pagination.texy index e1805afd07..f9611c6e3f 100644 --- a/best-practices/hu/pagination.texy +++ b/best-practices/hu/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository A Presenterben ezután befecskendezzük a modell osztályt, és a render metódusban lekérdezzük a publikált cikkeket, amelyeket átadunk a sablonhoz: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -A sablonban gondoskodunk egy cikklista rendereléséről: +A `default.latte` sablon ezután gondoskodik a cikkek felsorolásáról: ```latte {block content} @@ -114,7 +113,7 @@ A következő lépés a bemutató szerkesztése. Az aktuálisan megjelenített o A render metódust kibővítjük a Paginator példány megszerzésével, beállításával és a sablonban megjelenítendő megfelelő cikkek kiválasztásával is. A HomePresenter így fog kinézni: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Nem kell Paginátort létrehoznunk a Presenterben, helyette az adattár által visszaadott `Selection` objektum metódusát fogjuk használni: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/it/composer.texy b/best-practices/it/composer.texy index 93f33e4133..6ca7aff82e 100644 --- a/best-practices/it/composer.texy +++ b/best-practices/it/composer.texy @@ -189,7 +189,7 @@ Tuttavia, è anche possibile usare Composer per caricare altre classi al di fuor Successivamente, è necessario eseguire il comando `composer dumpautoload` a ogni modifica e lasciare che le tabelle di autocaricamento si rigenerino. Questo è estremamente scomodo ed è molto meglio affidare questo compito a [RobotLoader |robot-loader:], che svolge la stessa attività automaticamente in background e molto più velocemente. -La seconda opzione consiste nel seguire [PSR-4 |https://www.php-fig.org/psr/psr-4/]. In parole povere, si tratta di un sistema in cui gli spazi dei nomi e i nomi delle classi corrispondono alla struttura delle directory e ai nomi dei file, cioè `App\Router\RouterFactory` si trova nel file `/path/to/App/Router/RouterFactory.php`. Esempio di configurazione: +La seconda opzione consiste nel seguire [PSR-4 |https://www.php-fig.org/psr/psr-4/]. In parole povere, si tratta di un sistema in cui gli spazi dei nomi e i nomi delle classi corrispondono alla struttura delle directory e ai nomi dei file, cioè `App\Core\RouterFactory` si trova nel file `/path/to/App/Core/RouterFactory.php`. Esempio di configurazione: ```js { diff --git a/best-practices/it/lets-create-contact-form.texy b/best-practices/it/lets-create-contact-form.texy index 463ed21c39..468790dce9 100644 --- a/best-practices/it/lets-create-contact-form.texy +++ b/best-practices/it/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Come si può vedere, abbiamo creato due metodi. Il primo metodo `createComponent Ma cosa succede se l'utente non compila alcuni campi? In questo caso, dovremmo fargli sapere che si tratta di un campo obbligatorio. Lo abbiamo fatto con il metodo `setRequired()`. Infine, abbiamo aggiunto anche un [evento |nette:glossary#events] `onSuccess`, che si attiva se il form viene inviato con successo. Nel nostro caso, richiama il metodo `contactFormSucceeded`, che si occupa di elaborare il modulo inviato. Lo aggiungeremo al codice tra poco. -Il componente `contantForm` deve essere reso nel template `templates/Home/default.latte`: +Il componente `contantForm` deve essere reso nel template `Home/default.latte`: ```latte {block content} diff --git a/best-practices/it/pagination.texy b/best-practices/it/pagination.texy index 0d6ca96483..adf166b262 100644 --- a/best-practices/it/pagination.texy +++ b/best-practices/it/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Nel Presenter iniettiamo poi la classe Model e nel metodo render chiediamo gli articoli pubblicati che passiamo al template: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -Nel modello, ci occuperemo di rendere un elenco di articoli: +Il modello `default.latte` si occuperà di elencare gli articoli: ```latte {block content} @@ -114,7 +113,7 @@ Il passo successivo è modificare il presentatore. Inoltreremo il numero della p Espandiamo inoltre il metodo render per ottenere l'istanza di Paginator, impostandola e selezionando gli articoli corretti da visualizzare nel template. HomePresenter avrà questo aspetto: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Non è necessario creare il Paginator nel Presenter, ma si utilizzerà il metodo dell'oggetto `Selection` restituito dal repository: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/pl/composer.texy b/best-practices/pl/composer.texy index 125441e90d..77950657da 100644 --- a/best-practices/pl/composer.texy +++ b/best-practices/pl/composer.texy @@ -189,7 +189,7 @@ Jednakże możliwe jest również użycie Composera do załadowania innych klas Następnie musisz uruchomić polecenie `composer dumpautoload` za każdym razem, gdy dokonujesz zmiany i masz ponownie wygenerowane tabele autoloader. Jest to niezwykle uciążliwe i zdecydowanie lepiej powierzyć to zadanie [RobotLoaderowi |robot-loader:], który wykonuje tę samą pracę automatycznie w tle i znacznie szybciej. -Inną możliwością jest zastosowanie się do [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Mówiąc najprościej, jest to system, w którym przestrzenie nazw i nazwy klas odpowiadają strukturom katalogów i nazwom plików, więc na przykład `App\Router\RouterFactory` będzie w pliku `/path/to/App/Router/RouterFactory.php`. Przykładowa konfiguracja: +Inną możliwością jest zastosowanie się do [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Mówiąc najprościej, jest to system, w którym przestrzenie nazw i nazwy klas odpowiadają strukturom katalogów i nazwom plików, więc na przykład `App\Core\RouterFactory` będzie w pliku `/path/to/App/Core/RouterFactory.php`. Przykładowa konfiguracja: ```js { diff --git a/best-practices/pl/lets-create-contact-form.texy b/best-practices/pl/lets-create-contact-form.texy index 25c109b3c9..40f832e01b 100644 --- a/best-practices/pl/lets-create-contact-form.texy +++ b/best-practices/pl/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Jak widać, stworzyliśmy dwie metody. Pierwsza metoda `createComponentContactFo Ale co jeśli użytkownik nie wypełni niektórych pól? W takim przypadku powinniśmy dać mu znać, że jest to pole wymagane. Zrobiliśmy to za pomocą metody `setRequired()`. Na koniec dodaliśmy również [zdarzenie |nette:glossary#events] `onSuccess`, które jest wywoływane, jeśli formularz zostanie przesłany pomyślnie. W naszym przypadku wywołuje ono metodę `contactFormSucceeded`, która zajmuje się przetwarzaniem przesłanego formularza. Za chwilę dodamy to do kodu. -Niech komponent `contantForm` będzie renderowany w szablonie `templates/Home/default.latte`: +Niech komponent `contantForm` będzie renderowany w szablonie `Home/default.latte`: ```latte {block content} diff --git a/best-practices/pl/pagination.texy b/best-practices/pl/pagination.texy index d6da41b76b..13e39bab4a 100644 --- a/best-practices/pl/pagination.texy +++ b/best-practices/pl/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Następnie wstrzykujemy klasę modelu w prezenterze i w metodzie render żądamy opublikowanych artykułów do przekazania do szablonu: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -W szablonie zajmujemy się następnie wyszczególnieniem artykułów: +Szablon `default.latte` zajmie się następnie listą artykułów: ```latte {block content} @@ -114,7 +113,7 @@ Następnie zabierzemy się do pracy nad modyfikacją prezentera. Do metody rende Następnie rozszerzymy również metodę render, aby uzyskać instancję Paginatora, skonfigurować ją i wybrać odpowiednie artykuły do wyświetlenia w szablonie. HomePresenter po modyfikacjach będzie wyglądał tak: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Nie musimy tworzyć Paginatora w prezenterze, zamiast tego używamy metody klasy `Selection` zwracanej przez repozytorium: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/pt/composer.texy b/best-practices/pt/composer.texy index a22608c832..bc48d771b3 100644 --- a/best-practices/pt/composer.texy +++ b/best-practices/pt/composer.texy @@ -189,7 +189,7 @@ Entretanto, também é possível utilizar o Composer para carregar outras classe Em seguida, é necessário executar o comando `composer dumpautoload` a cada mudança e deixar as mesas de auto-carga se regenerar. Isto é extremamente inconveniente, e é muito melhor confiar esta tarefa ao [RobotLoader |robot-loader:], que executa a mesma atividade automaticamente em segundo plano e muito mais rápido. -A segunda opção é seguir o [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Simplesmente dizendo, é um sistema onde os namespaces e nomes de classes correspondem à estrutura do diretório e nomes de arquivos, ou seja, `App\Router\RouterFactory` está localizado no arquivo `/path/to/App/Router/RouterFactory.php`. Exemplo de configuração: +A segunda opção é seguir o [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Simplesmente dizendo, é um sistema onde os namespaces e nomes de classes correspondem à estrutura do diretório e nomes de arquivos, ou seja, `App\Core\RouterFactory` está localizado no arquivo `/path/to/App/Core/RouterFactory.php`. Exemplo de configuração: ```js { diff --git a/best-practices/pt/lets-create-contact-form.texy b/best-practices/pt/lets-create-contact-form.texy index 73db878db9..6fd619dd72 100644 --- a/best-practices/pt/lets-create-contact-form.texy +++ b/best-practices/pt/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Como você pode ver, nós criamos dois métodos. O primeiro método `createCompo Mas e se o usuário não preencher alguns campos? Nesse caso, devemos avisá-lo que se trata de um campo obrigatório. Fizemos isso com o método `setRequired()`. Finalmente, adicionamos também um [evento |nette:glossary#events] `onSuccess`, que é acionado se o formulário for submetido com sucesso. Em nosso caso, ele chama o método `contactFormSucceeded`, que se encarrega de processar o formulário submetido. Acrescentaremos isso ao código em um momento. -Deixe o componente `contantForm` ser apresentado no modelo `templates/Home/default.latte`: +Deixe o componente `contantForm` ser apresentado no modelo `Home/default.latte`: ```latte {block content} diff --git a/best-practices/pt/pagination.texy b/best-practices/pt/pagination.texy index 7fae6d5b5e..149dfc1b72 100644 --- a/best-practices/pt/pagination.texy +++ b/best-practices/pt/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository No Apresentador injetamos então a classe do modelo e no método de renderização pediremos os artigos publicados que passamos para o modelo: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -No modelo, nós nos encarregaremos de elaborar uma lista de artigos: +O modelo `default.latte` se encarregará de listar os artigos: ```latte {block content} @@ -114,7 +113,7 @@ O próximo passo é editar o apresentador. Nós encaminharemos o número da pág Também expandimos o método de renderização para obter a instância Paginator, configurando-a e selecionando os artigos corretos a serem exibidos no modelo. Home PagePresenter terá este aspecto: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Não temos que criar o Paginador no Apresentador, em vez disso usaremos o método do objeto `Selection` devolvido pelo repositório: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/ro/composer.texy b/best-practices/ro/composer.texy index a2c5f12e81..0905a7c202 100644 --- a/best-practices/ro/composer.texy +++ b/best-practices/ro/composer.texy @@ -189,7 +189,7 @@ Cu toate acestea, este de asemenea posibil să utilizați Composer pentru a înc Ulterior, este necesar să executați comanda `composer dumpautoload` cu fiecare modificare și să lăsați tabelele de autoloading să se regenereze. Acest lucru este extrem de incomod și este mult mai bine să încredințați această sarcină lui [RobotLoader |robot-loader:], care efectuează aceeași activitate în mod automat în fundal și mult mai rapid. -A doua opțiune este să urmați [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Spunând simplu, este un sistem în care spațiile de nume și numele claselor corespund structurii directoarelor și numelor de fișiere, adică `App\Router\RouterFactory` se află în fișierul `/path/to/App/Router/RouterFactory.php`. Exemplu de configurare: +A doua opțiune este să urmați [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Spunând simplu, este un sistem în care spațiile de nume și numele claselor corespund structurii directoarelor și numelor de fișiere, adică `App\Core\RouterFactory` se află în fișierul `/path/to/App/Core/RouterFactory.php`. Exemplu de configurare: ```js { diff --git a/best-practices/ro/lets-create-contact-form.texy b/best-practices/ro/lets-create-contact-form.texy index eecffd9791..42435507e4 100644 --- a/best-practices/ro/lets-create-contact-form.texy +++ b/best-practices/ro/lets-create-contact-form.texy @@ -39,7 +39,7 @@ După cum puteți vedea, am creat două metode. Prima metodă `createComponentCo Dar ce se întâmplă dacă utilizatorul nu completează unele câmpuri? În acest caz, ar trebui să-l anunțăm că este un câmp obligatoriu. Am făcut acest lucru cu metoda `setRequired()`. În cele din urmă, am adăugat și un [eveniment |nette:glossary#events] `onSuccess`, care este declanșat dacă formularul este trimis cu succes. În cazul nostru, acesta apelează metoda `contactFormSucceeded`, care se ocupă de procesarea formularului trimis. Vom adăuga acest lucru în cod imediat. -Lăsați componenta `contantForm` să fie redată în șablonul `templates/Home/default.latte`: +Lăsați componenta `contantForm` să fie redată în șablonul `Home/default.latte`: ```latte {block content} diff --git a/best-practices/ro/pagination.texy b/best-practices/ro/pagination.texy index 40d9de47aa..ee9ac16acc 100644 --- a/best-practices/ro/pagination.texy +++ b/best-practices/ro/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository În Presenter vom injecta apoi clasa model, iar în metoda render vom cere articolele publicate pe care le vom trece în șablon: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -În șablon, ne vom ocupa de redarea unei liste de articole: +Șablonul `default.latte` se va ocupa apoi de listarea articolelor: ```latte {block content} @@ -114,7 +113,7 @@ Următorul pas este să modificăm prezentatorul. Vom transmite numărul paginii De asemenea, extindem metoda de randare pentru a obține instanța Paginator, configurând-o și selectând articolele corecte pentru a fi afișate în șablon. HomePresenter va arăta astfel: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Nu trebuie să creăm Paginator în Presenter, în schimb vom folosi metoda obiectului `Selection` returnat de depozit: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/ru/composer.texy b/best-practices/ru/composer.texy index 276a92c29e..6e77697023 100644 --- a/best-practices/ru/composer.texy +++ b/best-practices/ru/composer.texy @@ -189,7 +189,7 @@ Packagist.org — глобальный репозиторий .[#toc-packagist-o Впоследствии необходимо выполнять команду `composer dumpautoload` при каждом изменении и позволять таблицам автозагрузки регенерироваться. Это крайне неудобно, и гораздо лучше доверить эту задачу [RobotLoader|robot-loader:], который выполняет ту же самую работу автоматически в фоновом режиме и гораздо быстрее. -Второй вариант — следовать [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Проще говоря, это система, в которой пространства имен и имена классов соответствуют структуре каталогов и именам файлов, т. е. `App\Router\RouterFactory` находится в файле `/path/to/App/Router/RouterFactory.php`. Пример конфигурации: +Второй вариант — следовать [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Проще говоря, это система, в которой пространства имен и имена классов соответствуют структуре каталогов и именам файлов, т. е. `App\Core\RouterFactory` находится в файле `/path/to/App/Core/RouterFactory.php`. Пример конфигурации: ```js { diff --git a/best-practices/ru/lets-create-contact-form.texy b/best-practices/ru/lets-create-contact-form.texy index f81335f4ef..bed8cf51df 100644 --- a/best-practices/ru/lets-create-contact-form.texy +++ b/best-practices/ru/lets-create-contact-form.texy @@ -39,7 +39,7 @@ class HomePresenter extends Presenter Но что, если пользователь не заполнит некоторые поля? В этом случае мы должны сообщить ему, что это обязательное поле. Мы сделали это с помощью метода `setRequired()`. Наконец, мы также добавили [событие |nette:glossary#events] `onSuccess`, которое срабатывает в случае успешной отправки формы. В нашем случае оно вызывает метод `contactFormSucceeded`, который обрабатывает отправленную форму. Мы добавим это в код через некоторое время. -Пусть компонент `contantForm` будет отображен в шаблоне `templates/Home/default.latte`: +Пусть компонент `contantForm` будет отображен в шаблоне `Home/default.latte`: ```latte {block content} diff --git a/best-practices/ru/pagination.texy b/best-practices/ru/pagination.texy index 6d384a2ebf..87693d2c25 100644 --- a/best-practices/ru/pagination.texy +++ b/best-practices/ru/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Затем в презентере мы вводим класс модели и в методе `render` запрашиваем опубликованные статьи, которые передаем в шаблон: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -В шаблоне мы позаботимся о выводе списка статей: +Шаблон `default.latte` позаботится о перечислении статей: ```latte {block content} @@ -114,7 +113,7 @@ class ArticleRepository Мы также расширяем метод `render` для получения экземпляра Paginator, его настройки и выбора нужных статей для отображения в шаблоне. HomePresenter будет выглядеть следующим образом: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Нам не нужно создавать Paginator в презентере, вместо этого мы будем использовать метод объекта `Selection`, возвращаемый репозиторием: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/sl/composer.texy b/best-practices/sl/composer.texy index 97a8e4ad75..6a3fa3ffdc 100644 --- a/best-practices/sl/composer.texy +++ b/best-practices/sl/composer.texy @@ -189,7 +189,7 @@ Vendar je mogoče Composer uporabiti tudi za nalaganje drugih razredov zunaj map Nato je treba ob vsaki spremembi zagnati ukaz `composer dumpautoload` in pustiti, da se tabele za samodejno nalaganje regenerirajo. To je izredno neprijetno in veliko bolje je to nalogo zaupati programu [RobotLoader |robot-loader:], ki isto dejavnost opravi samodejno v ozadju in veliko hitreje. -Druga možnost je, da sledite [priporočilu PSR-4 |https://www.php-fig.org/psr/psr-4/]. Preprosto povedano, gre za sistem, v katerem imenska območja in imena razredov ustrezajo imeniški strukturi in imenom datotek, tj. `App\Router\RouterFactory` se nahaja v datoteki `/path/to/App/Router/RouterFactory.php`. Primer konfiguracije: +Druga možnost je, da sledite [priporočilu PSR-4 |https://www.php-fig.org/psr/psr-4/]. Preprosto povedano, gre za sistem, v katerem imenska območja in imena razredov ustrezajo imeniški strukturi in imenom datotek, tj. `App\Core\RouterFactory` se nahaja v datoteki `/path/to/App/Core/RouterFactory.php`. Primer konfiguracije: ```js { diff --git a/best-practices/sl/lets-create-contact-form.texy b/best-practices/sl/lets-create-contact-form.texy index feeae86ee8..0fe2c371a9 100644 --- a/best-practices/sl/lets-create-contact-form.texy +++ b/best-practices/sl/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Kot lahko vidite, smo ustvarili dve metodi. Prva metoda `createComponentContactF Kaj pa, če uporabnik ne izpolni nekaterih polj? V tem primeru mu moramo sporočiti, da gre za zahtevano polje. To smo storili z metodo `setRequired()`. Na koncu smo dodali še [dogodek |nette:glossary#events] `onSuccess`, ki se sproži, če je obrazec uspešno oddan. V našem primeru pokliče metodo `contactFormSucceeded`, ki poskrbi za obdelavo oddanega obrazca. To bomo v kodo dodali v naslednjem trenutku. -Naj bo komponenta `contantForm` prikazana v predlogi `templates/Home/default.latte`: +Naj bo komponenta `contantForm` prikazana v predlogi `Home/default.latte`: ```latte {block content} diff --git a/best-practices/sl/pagination.texy b/best-practices/sl/pagination.texy index fff9e4bf1f..f0136cebbc 100644 --- a/best-practices/sl/pagination.texy +++ b/best-practices/sl/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository V Presenter nato injiciramo razred model in v metodi render bomo zahtevali objavljene članke, ki jih posredujemo predlogi: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -V predlogi bomo poskrbeli za upodobitev seznama člankov: +Predloga `default.latte` bo nato poskrbela za seznam člankov: ```latte {block content} @@ -114,7 +113,7 @@ Naslednji korak je urejanje predstavnika. Številko trenutno prikazane strani bo Metodo upodabljanja razširimo tudi na pridobitev primerka Paginatorja, njegovo nastavitev in izbiro pravilnih člankov za prikaz v predlogi. HomePresenter bo videti takole: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Namesto tega bomo uporabili metodo predmeta `Selection`, ki ga je vrnil repozitorij: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/tr/composer.texy b/best-practices/tr/composer.texy index c16a3f0864..f16faee810 100644 --- a/best-practices/tr/composer.texy +++ b/best-practices/tr/composer.texy @@ -189,7 +189,7 @@ Ancak, Composer'ı `vendor` klasörü dışındaki diğer sınıfları yüklemek Daha sonra, her değişiklikte `composer dumpautoload` komutunu çalıştırmak ve otomatik yükleme tablolarının yeniden oluşturulmasına izin vermek gerekir. Bu son derece zahmetlidir ve bu görevi, aynı etkinliği arka planda otomatik olarak ve çok daha hızlı gerçekleştiren [RobotLoader'a |robot-loader:] emanet etmek çok daha iyidir. -İkinci seçenek [PSR-4'ü |https://www.php-fig.org/psr/psr-4/] takip etmektir. Basitçe söylemek gerekirse, ad alanlarının ve sınıf adlarının dizin yapısına ve dosya adlarına karşılık geldiği bir sistemdir, yani `App\Router\RouterFactory`, `/path/to/App/Router/RouterFactory.php` dosyasında bulunur. Yapılandırma örneği: +İkinci seçenek [PSR-4'ü |https://www.php-fig.org/psr/psr-4/] takip etmektir. Basitçe söylemek gerekirse, ad alanlarının ve sınıf adlarının dizin yapısına ve dosya adlarına karşılık geldiği bir sistemdir, yani `App\Core\RouterFactory`, `/path/to/App/Core/RouterFactory.php` dosyasında bulunur. Yapılandırma örneği: ```js { diff --git a/best-practices/tr/lets-create-contact-form.texy b/best-practices/tr/lets-create-contact-form.texy index 52d307b8bf..306be16c72 100644 --- a/best-practices/tr/lets-create-contact-form.texy +++ b/best-practices/tr/lets-create-contact-form.texy @@ -39,7 +39,7 @@ Gördüğünüz gibi iki metot oluşturduk. İlk yöntem `createComponentContact Peki ya kullanıcı bazı alanları doldurmazsa? Bu durumda, ona bunun gerekli bir alan olduğunu bildirmeliyiz. Bunu `setRequired()` metodu ile yaptık. Son olarak, form başarıyla gönderildiğinde tetiklenen bir `onSuccess`[olayı |nette:glossary#events] da ekledik. Bizim durumumuzda, gönderilen formun işlenmesiyle ilgilenen `contactFormSucceeded` yöntemini çağırır. Bunu birazdan koda ekleyeceğiz. - `contantForm` bileşeninin `templates/Home/default.latte` şablonunda oluşturulmasına izin verin: + `contantForm` bileşeninin `Home/default.latte` şablonunda oluşturulmasına izin verin: ```latte {block content} diff --git a/best-practices/tr/pagination.texy b/best-practices/tr/pagination.texy index 0f0d378bfd..e6513d47d1 100644 --- a/best-practices/tr/pagination.texy +++ b/best-practices/tr/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Presenter'da daha sonra model sınıfını enjekte edeceğiz ve render yönteminde şablona aktardığımız yayınlanmış makaleleri isteyeceğiz: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -Şablonda, bir makale listesi oluşturmaya özen göstereceğiz: +`default.latte` şablonu daha sonra makaleleri listelemekle ilgilenecektir: ```latte {block content} @@ -114,7 +113,7 @@ Bir sonraki adım sunucuyu düzenlemektir. Şu anda görüntülenen sayfanın nu Ayrıca Paginator örneğini almak, ayarlamak ve şablonda görüntülenecek doğru makaleleri seçmek için render yöntemini genişletiyoruz. HomePresenter şu şekilde görünecektir: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Presenter'da Paginator oluşturmak zorunda değiliz, bunun yerine repository tarafından döndürülen `Selection` nesnesinin yöntemini kullanacağız: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/best-practices/uk/composer.texy b/best-practices/uk/composer.texy index edca818c9a..e6777c8700 100644 --- a/best-practices/uk/composer.texy +++ b/best-practices/uk/composer.texy @@ -189,7 +189,7 @@ Packagist.org - глобальний репозиторій .[#toc-packagist-org Згодом необхідно виконувати команду `composer dumpautoload` при кожній зміні та дозволяти таблицям автозавантаження регенеруватися. Це вкрай незручно, і набагато краще довірити цю задачу [RobotLoader |robot-loader:], який виконує ту ж саму роботу автоматично у фоновому режимі і набагато швидше. -Другий варіант - слідувати [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Простіше кажучи, це система, в якій простори імен та імена класів відповідають структурі каталогів та іменам файлів, тобто `App\Router\RouterFactory` знаходиться у файлі `/path/to/App/Router/RouterFactory.php`. Приклад конфігурації: +Другий варіант - слідувати [PSR-4 |https://www.php-fig.org/psr/psr-4/]. Простіше кажучи, це система, в якій простори імен та імена класів відповідають структурі каталогів та іменам файлів, тобто `App\Core\RouterFactory` знаходиться у файлі `/path/to/App/Core/RouterFactory.php`. Приклад конфігурації: ```js { diff --git a/best-practices/uk/lets-create-contact-form.texy b/best-practices/uk/lets-create-contact-form.texy index 724f0c58d7..e4cc290b82 100644 --- a/best-practices/uk/lets-create-contact-form.texy +++ b/best-practices/uk/lets-create-contact-form.texy @@ -39,7 +39,7 @@ class HomePresenter extends Presenter Але що, якщо користувач не заповнить деякі поля? У такому випадку ми повинні повідомити йому, що це поле є обов'язковим для заповнення. Ми зробили це за допомогою методу `setRequired()`. Нарешті, ми також додали [подію |nette:glossary#events] `onSuccess`, яка спрацьовує в разі успішного відправлення форми. У нашому випадку вона викликає метод `contactFormSucceeded`, який відповідає за обробку надісланої форми. Ми додамо його до коду за мить. -Нехай компонент `contantForm` рендериться в шаблоні `templates/Home/default.latte`: +Нехай компонент `contantForm` рендериться в шаблоні `Home/default.latte`: ```latte {block content} diff --git a/best-practices/uk/pagination.texy b/best-practices/uk/pagination.texy index 56ddd52028..c74c942c2e 100644 --- a/best-practices/uk/pagination.texy +++ b/best-practices/uk/pagination.texy @@ -11,7 +11,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -34,7 +33,7 @@ class ArticleRepository Потім у презентері ми вводимо клас моделі і в методі `render` запитуємо опубліковані статті, які передаємо в шаблон: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -53,7 +52,7 @@ class HomePresenter extends Nette\Application\UI\Presenter } ``` -У шаблоні ми подбаємо про виведення списку статей: +Після цього шаблон `default.latte` подбає про список статей: ```latte {block content} @@ -114,7 +113,7 @@ class ArticleRepository Ми також розширюємо метод `render` для отримання екземпляра Paginator, його налаштування та вибору потрібних статей для відображення в шаблоні. HomePresenter матиме такий вигляд: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; @@ -190,7 +189,6 @@ namespace App\Model; use Nette; - class ArticleRepository { public function __construct( @@ -210,7 +208,7 @@ class ArticleRepository Нам не потрібно створювати Paginator у презентері, натомість ми використовуватимемо метод об'єкта `Selection`, який повертає сховище: ```php -namespace App\Presenters; +namespace App\UI\Home; use Nette; use App\Model\ArticleRepository; diff --git a/dependency-injection/bg/configuration.texy b/dependency-injection/bg/configuration.texy index b9ff04bf42..a1bfa25820 100644 --- a/dependency-injection/bg/configuration.texy +++ b/dependency-injection/bg/configuration.texy @@ -67,7 +67,7 @@ parameters: ```neon decorator: # За всички услуги, които са екземпляри на този клас или интерфейс - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # извикване на този метод - $absoluteUrls = true # и задаване на променлива diff --git a/dependency-injection/bg/factory.texy b/dependency-injection/bg/factory.texy index 43699fde67..b50ea73905 100644 --- a/dependency-injection/bg/factory.texy +++ b/dependency-injection/bg/factory.texy @@ -220,7 +220,7 @@ services: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.context ) diff --git a/dependency-injection/cs/configuration.texy b/dependency-injection/cs/configuration.texy index 4b80e78339..0ae0adcd06 100644 --- a/dependency-injection/cs/configuration.texy +++ b/dependency-injection/cs/configuration.texy @@ -67,7 +67,7 @@ Jak upravit hromadně všechny služby určitého typu? Třeba zavolat určitou ```neon decorator: # u všech služeb, co jsou instancí této třídy nebo rozhraní - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # zavolej tuto metodu - $absoluteUrls = true # a nastav proměnnou diff --git a/dependency-injection/cs/factory.texy b/dependency-injection/cs/factory.texy index 082f32d37e..94da4bbd94 100644 --- a/dependency-injection/cs/factory.texy +++ b/dependency-injection/cs/factory.texy @@ -220,7 +220,7 @@ Druhou možností je využít k definici [tagy|services#Tagy]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/de/configuration.texy b/dependency-injection/de/configuration.texy index d8fd5fbb37..81e37a18f5 100644 --- a/dependency-injection/de/configuration.texy +++ b/dependency-injection/de/configuration.texy @@ -67,7 +67,7 @@ Wie kann man alle Dienste eines bestimmten Typs als Ganzes bearbeiten? Müssen S ```neon decorator: # für alle Dienste, die Instanzen dieser Klasse oder Schnittstelle sind - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # diese Methode aufrufen - $absoluteUrls = true # und setze die Variable diff --git a/dependency-injection/de/factory.texy b/dependency-injection/de/factory.texy index c5ea50f342..2ff999d106 100644 --- a/dependency-injection/de/factory.texy +++ b/dependency-injection/de/factory.texy @@ -220,7 +220,7 @@ Eine weitere Möglichkeit, eine Multifabrik zu definieren, ist die Verwendung vo ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/el/configuration.texy b/dependency-injection/el/configuration.texy index b99ecbbcf9..2fb9c48458 100644 --- a/dependency-injection/el/configuration.texy +++ b/dependency-injection/el/configuration.texy @@ -67,7 +67,7 @@ parameters: ```neon decorator: # για όλες τις υπηρεσίες που είναι στιγμιότυπα αυτής της κλάσης ή διεπαφής - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # καλέστε αυτή τη μέθοδο - $absoluteUrls = true # και ορίστε τη μεταβλητή diff --git a/dependency-injection/el/factory.texy b/dependency-injection/el/factory.texy index ae2f1951f0..d6f61b4c87 100644 --- a/dependency-injection/el/factory.texy +++ b/dependency-injection/el/factory.texy @@ -220,7 +220,7 @@ services: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/en/configuration.texy b/dependency-injection/en/configuration.texy index 4400910043..baa5467cfb 100644 --- a/dependency-injection/en/configuration.texy +++ b/dependency-injection/en/configuration.texy @@ -67,7 +67,7 @@ How to bulk edit all services of a certain type? Need to call a certain method f ```neon decorator: # for all services that are instances of this class or interface - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # call this method - $absoluteUrls = true # and set the variable diff --git a/dependency-injection/en/factory.texy b/dependency-injection/en/factory.texy index e96c7c385c..d3cc3a3c6c 100644 --- a/dependency-injection/en/factory.texy +++ b/dependency-injection/en/factory.texy @@ -220,7 +220,7 @@ Another option how to define a multifactory is to use [tags|services#Tags]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/es/configuration.texy b/dependency-injection/es/configuration.texy index ae0b652501..536a89a5d1 100644 --- a/dependency-injection/es/configuration.texy +++ b/dependency-injection/es/configuration.texy @@ -67,7 +67,7 @@ Decorador .[#toc-decorator] ```neon decorator: # para todos los servicios que son instancias de esta clase o interfaz - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # llamar a este método - $absoluteUrls = true # y establecer la variable diff --git a/dependency-injection/es/factory.texy b/dependency-injection/es/factory.texy index 4e6151853f..ef367ff00a 100644 --- a/dependency-injection/es/factory.texy +++ b/dependency-injection/es/factory.texy @@ -220,7 +220,7 @@ Otra opción para definir un multifactory es utilizar [tags|services#Tags]: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/fr/configuration.texy b/dependency-injection/fr/configuration.texy index 1970ea21e7..4241d58871 100644 --- a/dependency-injection/fr/configuration.texy +++ b/dependency-injection/fr/configuration.texy @@ -67,7 +67,7 @@ Comment modifier en masse tous les services d'un certain type ? Vous avez besoin ```neon decorator: # pour tous les services qui sont des instances de cette classe ou interface - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # appelle cette méthode - $absoluteUrls = true # et définir la variable diff --git a/dependency-injection/fr/factory.texy b/dependency-injection/fr/factory.texy index 7c49950361..836e6ee438 100644 --- a/dependency-injection/fr/factory.texy +++ b/dependency-injection/fr/factory.texy @@ -220,7 +220,7 @@ Une autre option pour définir un multifactory est d'utiliser des [balises |serv ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/hu/configuration.texy b/dependency-injection/hu/configuration.texy index ed9aa0144e..16d1097e80 100644 --- a/dependency-injection/hu/configuration.texy +++ b/dependency-injection/hu/configuration.texy @@ -67,7 +67,7 @@ Hogyan lehet egy bizonyos típusú összes szolgáltatást tömegesen szerkeszte ```neon decorator: # minden olyan szolgáltatáshoz, amely ennek az osztálynak vagy interfésznek a példánya. - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - # hívja meg ezt a metódust - $absoluteUrls = true # és állítsuk be a változót diff --git a/dependency-injection/hu/factory.texy b/dependency-injection/hu/factory.texy index 438effdcc6..5ae2bec739 100644 --- a/dependency-injection/hu/factory.texy +++ b/dependency-injection/hu/factory.texy @@ -220,7 +220,7 @@ Egy másik lehetőség a multifactory definiálására a [címkék |services#Tag ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/it/configuration.texy b/dependency-injection/it/configuration.texy index 628d6a3bc0..f1c063c0ad 100644 --- a/dependency-injection/it/configuration.texy +++ b/dependency-injection/it/configuration.texy @@ -67,7 +67,7 @@ Come modificare in blocco tutti i servizi di un certo tipo? È necessario chiama ```neon decorator: # per tutti i servizi che sono istanze di questa classe o interfaccia - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # chiama questo metodo - $absoluteUrls = true # e imposta la variabile diff --git a/dependency-injection/it/factory.texy b/dependency-injection/it/factory.texy index 8eafe7bbc9..5487c86971 100644 --- a/dependency-injection/it/factory.texy +++ b/dependency-injection/it/factory.texy @@ -220,7 +220,7 @@ Un'altra opzione per definire una multifactory è quella di usare i [tag |servic ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/ja/configuration.texy b/dependency-injection/ja/configuration.texy index a6417023d2..e2c485badc 100644 --- a/dependency-injection/ja/configuration.texy +++ b/dependency-injection/ja/configuration.texy @@ -67,7 +67,7 @@ parameters: ```neon decorator: # for all services that are instances of this class or interface - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # call this method - $absoluteUrls = true # and set the variable diff --git a/dependency-injection/ja/factory.texy b/dependency-injection/ja/factory.texy index 80d8064a3c..e5e83e538e 100644 --- a/dependency-injection/ja/factory.texy +++ b/dependency-injection/ja/factory.texy @@ -220,7 +220,7 @@ services: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/pl/configuration.texy b/dependency-injection/pl/configuration.texy index f3ed899ede..2e1ec832d2 100644 --- a/dependency-injection/pl/configuration.texy +++ b/dependency-injection/pl/configuration.texy @@ -67,7 +67,7 @@ Jak masowo edytować wszystkie usługi danego typu? Na przykład wywołaj okreś ```neon decorator: # dla wszystkich usług, które są instancjami tej klasy lub interfejsu - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # wywołaj tę metodę - $absoluteUrls = true # i ustawić zmienną diff --git a/dependency-injection/pl/factory.texy b/dependency-injection/pl/factory.texy index 1658beda00..f566dad4ee 100644 --- a/dependency-injection/pl/factory.texy +++ b/dependency-injection/pl/factory.texy @@ -220,7 +220,7 @@ Druga opcja to użycie [tagów |services#Tags] do definicji: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/pt/configuration.texy b/dependency-injection/pt/configuration.texy index eab09bb9dc..e6fd0e2aa6 100644 --- a/dependency-injection/pt/configuration.texy +++ b/dependency-injection/pt/configuration.texy @@ -67,7 +67,7 @@ Como editar em massa todos os serviços de um determinado tipo? Precisa chamar u ```neon decorator: # para todos os serviços que são instâncias desta classe ou interface - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # chamar este método - $absoluteUrls = true # e definir a variável diff --git a/dependency-injection/pt/factory.texy b/dependency-injection/pt/factory.texy index 785b1ea569..293f3418b7 100644 --- a/dependency-injection/pt/factory.texy +++ b/dependency-injection/pt/factory.texy @@ -220,7 +220,7 @@ Outra opção para definir uma multifábrica é a utilização de [etiquetas |se ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/ro/configuration.texy b/dependency-injection/ro/configuration.texy index 92e4c59ecd..311cbfd773 100644 --- a/dependency-injection/ro/configuration.texy +++ b/dependency-injection/ro/configuration.texy @@ -67,7 +67,7 @@ Cum se pot edita în bloc toate serviciile de un anumit tip? Aveți nevoie să a ```neon decorator: # pentru toate serviciile care sunt instanțe ale acestei clase sau interfețe - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # apelează această metodă - $absoluteUrls = true # și setează variabila diff --git a/dependency-injection/ro/factory.texy b/dependency-injection/ro/factory.texy index 25a1475f01..d282fe1624 100644 --- a/dependency-injection/ro/factory.texy +++ b/dependency-injection/ro/factory.texy @@ -220,7 +220,7 @@ O altă opțiune de definire a unui multifactorial este utilizarea [etichetelor ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/ru/configuration.texy b/dependency-injection/ru/configuration.texy index 6fc86f0476..db9e0d2c8d 100644 --- a/dependency-injection/ru/configuration.texy +++ b/dependency-injection/ru/configuration.texy @@ -67,7 +67,7 @@ parameters: ```neon decorator: # Для всех сервисов, являющихся экземплярами этого класса или интерфейса - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # вызываем этот метод - $absoluteUrls = true # и задаем переменную diff --git a/dependency-injection/ru/factory.texy b/dependency-injection/ru/factory.texy index ebe578c30c..21149c2339 100644 --- a/dependency-injection/ru/factory.texy +++ b/dependency-injection/ru/factory.texy @@ -220,7 +220,7 @@ services: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.context ) diff --git a/dependency-injection/sl/configuration.texy b/dependency-injection/sl/configuration.texy index 5ab5cf0e50..f815b42c31 100644 --- a/dependency-injection/sl/configuration.texy +++ b/dependency-injection/sl/configuration.texy @@ -67,7 +67,7 @@ Kako množično urediti vse storitve določene vrste? Ali morate poklicati dolo ```neon decorator: # za vse storitve, ki so primerki tega razreda ali vmesnika. - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # pokliče to metodo - $absoluteUrls = true # in nastavi spremenljivko diff --git a/dependency-injection/sl/factory.texy b/dependency-injection/sl/factory.texy index 9c7a9dcb45..6fba37cb35 100644 --- a/dependency-injection/sl/factory.texy +++ b/dependency-injection/sl/factory.texy @@ -220,7 +220,7 @@ Druga možnost, kako opredeliti večpredstavnostno zbirko, je uporaba [oznak |se ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/tr/configuration.texy b/dependency-injection/tr/configuration.texy index 03cc7541d7..8861ae66a8 100644 --- a/dependency-injection/tr/configuration.texy +++ b/dependency-injection/tr/configuration.texy @@ -67,7 +67,7 @@ Belirli bir türdeki tüm hizmetleri toplu olarak nasıl düzenleyebilirim? Beli ```neon decorator: # bu sınıfın veya arayüzün örneği olan tüm hizmetler için - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # bu yöntemi çağır - $absoluteUrls = true # ve değişkeni ayarlayın diff --git a/dependency-injection/tr/factory.texy b/dependency-injection/tr/factory.texy index 26bd3c9ab1..60de28c2be 100644 --- a/dependency-injection/tr/factory.texy +++ b/dependency-injection/tr/factory.texy @@ -220,7 +220,7 @@ Bir multifactory'nin nasıl tanımlanacağına dair bir başka seçenek de [etik ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.explorer ) diff --git a/dependency-injection/uk/configuration.texy b/dependency-injection/uk/configuration.texy index 47b57a328e..e29d6c661a 100644 --- a/dependency-injection/uk/configuration.texy +++ b/dependency-injection/uk/configuration.texy @@ -67,7 +67,7 @@ parameters: ```neon decorator: # Для всіх сервісів, які є екземплярами цього класу або інтерфейсу - App\Presenters\BasePresenter: + App\UI\BasePresenter: setup: - setProjectId(10) # викликаємо цей метод - $absoluteUrls = true # і задаємо змінну diff --git a/dependency-injection/uk/factory.texy b/dependency-injection/uk/factory.texy index b3dd17aa8e..a5c0dc0806 100644 --- a/dependency-injection/uk/factory.texy +++ b/dependency-injection/uk/factory.texy @@ -220,7 +220,7 @@ services: ```neon services: - - App\Router\RouterFactory::createRouter + - App\Core\RouterFactory::createRouter - App\Model\DatabaseAccessor( db1: @database.db1.context ) diff --git a/forms/bg/in-presenter.texy b/forms/bg/in-presenter.texy index 6a96b8e901..8ab681eadd 100644 --- a/forms/bg/in-presenter.texy +++ b/forms/bg/in-presenter.texy @@ -30,7 +30,7 @@ $form->onSuccess[] = [$this, 'formSucceeded']; От гледна точка на водещия формулярът е общ компонент. Затова той се третира като компонент и се включва в презентатора чрез [метода factory |application:components#Factory-Methods]. Това ще изглежда по следния начин: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter А визуализирането в шаблона се извършва с помощта на тага `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Регистрация

{control registrationForm} diff --git a/forms/cs/in-presenter.texy b/forms/cs/in-presenter.texy index e8d3bddccd..807bdb1822 100644 --- a/forms/cs/in-presenter.texy +++ b/forms/cs/in-presenter.texy @@ -30,7 +30,7 @@ Formulář v presenteru je objekt třídy `Nette\Application\UI\Form`, její př Z pohledu presenteru je formulář běžná komponenta. Proto se s ním jako s komponentou zachází a začleníme ji do presenteru pomocí [tovární metody |application:components#Tovární metody]. Bude to vypadat takto: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter A v šabloně formulář vykreslíme značkou `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registrace

{control registrationForm} diff --git a/forms/de/in-presenter.texy b/forms/de/in-presenter.texy index 5397143c73..7a6e875a70 100644 --- a/forms/de/in-presenter.texy +++ b/forms/de/in-presenter.texy @@ -30,7 +30,7 @@ Das Formular im Presenter ist ein Objekt der Klasse `Nette\Application\UI\Form`, Aus der Sicht des Präsentators ist das Formular eine gemeinsame Komponente. Daher wird es als Komponente behandelt und mit der [Factory-Methode |application:components#Factory Methods] in den Presenter eingebunden. Das sieht dann wie folgt aus: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Und das Rendern in der Vorlage erfolgt mit dem Tag `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/el/in-presenter.texy b/forms/el/in-presenter.texy index ee4a9f9280..5245fbb365 100644 --- a/forms/el/in-presenter.texy +++ b/forms/el/in-presenter.texy @@ -30,7 +30,7 @@ $form->onSuccess[] = [$this, 'formSucceeded']; Από τη σκοπιά του παρουσιαστή, η φόρμα είναι ένα κοινό συστατικό. Ως εκ τούτου, αντιμετωπίζεται ως συστατικό και ενσωματώνεται στον παρουσιαστή χρησιμοποιώντας τη [μέθοδο factory |application:components#Factory Methods]. Αυτό θα έχει την εξής μορφή: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Και η απόδοση στο πρότυπο γίνεται με τη χρήση της ετικέτας `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/en/in-presenter.texy b/forms/en/in-presenter.texy index 5d2fe73214..5f94cf5b32 100644 --- a/forms/en/in-presenter.texy +++ b/forms/en/in-presenter.texy @@ -30,7 +30,7 @@ The form in the presenter is an object of the class `Nette\Application\UI\Form`, From the presenter's point of view, the form is a common component. Therefore, it is treated as a component and incorporated into the presenter using [factory method |application:components#Factory Methods]. It will look like this: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter And render in template is done using `{control}` tag: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/es/in-presenter.texy b/forms/es/in-presenter.texy index a6d66ed0e3..99d39ebc29 100644 --- a/forms/es/in-presenter.texy +++ b/forms/es/in-presenter.texy @@ -30,7 +30,7 @@ El formulario en el presentador es un objeto de la clase `Nette\Application\UI\F Desde el punto de vista del presentador, el formulario es un componente común. Por lo tanto, se trata como un componente y se incorpora al presentador utilizando [el método factory |application:components#Factory Methods]. Tendrá el siguiente aspecto: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Y el renderizado en la plantilla se realiza utilizando la etiqueta `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registro

{control registrationForm} diff --git a/forms/fr/in-presenter.texy b/forms/fr/in-presenter.texy index 8f8bcb4739..15a544b6a7 100644 --- a/forms/fr/in-presenter.texy +++ b/forms/fr/in-presenter.texy @@ -30,7 +30,7 @@ Le formulaire dans le présentateur est un objet de la classe `Nette\Application Du point de vue du présentateur, le formulaire est un composant commun. Par conséquent, il est traité comme un composant et incorporé dans le présentateur à l'aide de la [méthode factory |application:components#Factory Methods]. Cela ressemblera à ceci : -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Et le rendu dans le modèle est effectué à l'aide de la balise `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/hu/in-presenter.texy b/forms/hu/in-presenter.texy index 70f4742247..980683e6c4 100644 --- a/forms/hu/in-presenter.texy +++ b/forms/hu/in-presenter.texy @@ -30,7 +30,7 @@ A prezenterben lévő űrlap a `Nette\Application\UI\Form` osztály objektuma, e A bemutató szempontjából az űrlap egy közös komponens. Ezért komponensként kezeljük, és a [factory metódus |application:components#Factory Methods] segítségével beépítjük a prezentálóba. Ez így fog kinézni: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter A sablonban történő megjelenítés pedig a `{control}` tag használatával történik: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/it/in-presenter.texy b/forms/it/in-presenter.texy index bf398c453b..2c9e8433c0 100644 --- a/forms/it/in-presenter.texy +++ b/forms/it/in-presenter.texy @@ -30,7 +30,7 @@ Il modulo nel presentatore è un oggetto della classe `Nette\Application\UI\Form Dal punto di vista del presentatore, il modulo è un componente comune. Pertanto, viene trattato come un componente e incorporato nel presentatore con il [metodo factory |application:components#Factory Methods]. L'aspetto sarà il seguente: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter E il rendering nel template viene effettuato utilizzando il tag `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/pl/in-presenter.texy b/forms/pl/in-presenter.texy index afa333ac67..464a7951fa 100644 --- a/forms/pl/in-presenter.texy +++ b/forms/pl/in-presenter.texy @@ -30,7 +30,7 @@ Formularz w prezenterze jest obiektem klasy `Nette\Application\UI\Form`, jego po Z punktu widzenia prezentera formularz jest normalnym komponentem. Dlatego traktujemy go jako komponent i włączamy do prezentera za pomocą [metody factory |application:components#Factory-Methods]. Będzie to wyglądało tak: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter A w szablonie renderujemy formularz z tagiem `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registrace

{control registrationForm} diff --git a/forms/pt/in-presenter.texy b/forms/pt/in-presenter.texy index a21a2650d3..76aee63d4f 100644 --- a/forms/pt/in-presenter.texy +++ b/forms/pt/in-presenter.texy @@ -30,7 +30,7 @@ A forma no apresentador é um objeto da classe `Nette\Application\UI\Form`, seu Do ponto de vista do apresentador, a forma é um componente comum. Portanto, ele é tratado como um componente e incorporado ao apresentador usando [o método de fábrica |application:components#Factory Methods]. Será parecido com isto: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter E a renderização em modelo é feita usando a tag `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/ro/in-presenter.texy b/forms/ro/in-presenter.texy index 86b61b0e37..e191ef2786 100644 --- a/forms/ro/in-presenter.texy +++ b/forms/ro/in-presenter.texy @@ -30,7 +30,7 @@ Formularul din prezentator este un obiect din clasa `Nette\Application\UI\Form`, Din punctul de vedere al prezentatorului, formularul este o componentă comună. Prin urmare, acesta este tratat ca o componentă și încorporat în prezentator folosind [metoda factory |application:components#Factory Methods]. Acesta va arăta astfel: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Iar redarea în șablon se face cu ajutorul etichetei `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/ru/in-presenter.texy b/forms/ru/in-presenter.texy index ff2fa742cf..4f4992658b 100644 --- a/forms/ru/in-presenter.texy +++ b/forms/ru/in-presenter.texy @@ -30,7 +30,7 @@ $form->onSuccess[] = [$this, 'formSucceeded']; С точки зрения презентера форма является общим компонентом. Поэтому она рассматривается как компонент и включается в презентер с помощью [фабричного метода |application:components#Factory-Methods]. Это будет выглядеть следующим образом: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter А рендеринг в шаблоне осуществляется с помощью тега `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Регистрация

{control registrationForm} diff --git a/forms/sl/in-presenter.texy b/forms/sl/in-presenter.texy index 807a389a7a..229bee3900 100644 --- a/forms/sl/in-presenter.texy +++ b/forms/sl/in-presenter.texy @@ -30,7 +30,7 @@ Obrazec v predstavitvi je objekt razreda `Nette\Application\UI\Form`, njegov pre Z vidika predstavnika je obrazec skupna komponenta. Zato ga obravnavamo kot komponento in ga vključimo v predstavitveni program z uporabo [tovarniške metode |application:components#Factory Methods]. To bo videti takole: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Prikaz v predlogi pa se izvede z uporabo oznake `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/tr/in-presenter.texy b/forms/tr/in-presenter.texy index 09764a3ad0..9a384a6600 100644 --- a/forms/tr/in-presenter.texy +++ b/forms/tr/in-presenter.texy @@ -30,7 +30,7 @@ Sunucudaki form `Nette\Application\UI\Form` sınıfının bir nesnesidir, selefi Sunucunun bakış açısından, form ortak bir bileşendir. Bu nedenle, bir bileşen olarak ele alınır ve [fabrika yöntemi |application:components#Factory Methods] kullanılarak sunucuya dahil edilir. Bu şekilde görünecektir: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter Ve şablonda render işlemi `{control}` etiketi kullanılarak yapılır: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Registration

{control registrationForm} diff --git a/forms/uk/in-presenter.texy b/forms/uk/in-presenter.texy index de72fb81d7..34d1e2e401 100644 --- a/forms/uk/in-presenter.texy +++ b/forms/uk/in-presenter.texy @@ -30,7 +30,7 @@ $form->onSuccess[] = [$this, 'formSucceeded']; З точки зору презентера форма є загальним компонентом. Тому вона розглядається як компонент і включається в презентер за допомогою [фабричного методу |application:components#Factory-Methods]. Це виглядатиме наступним чином: -```php .{file:app/Presenters/HomePresenter.php} +```php .{file:app/UI/Home/HomePresenter.php} use Nette; use Nette\Application\UI\Form; @@ -59,7 +59,7 @@ class HomePresenter extends Nette\Application\UI\Presenter А рендеринг у шаблоні здійснюється за допомогою тега `{control}`: -```latte .{file:app/Presenters/templates/Home/default.latte} +```latte .{file:app/UI/Home/default.latte}

Регистрация

{control registrationForm} diff --git a/latte/bg/template-inheritance.texy b/latte/bg/template-inheritance.texy index 029d5cf9b3..f25013bc40 100644 --- a/latte/bg/template-inheritance.texy +++ b/latte/bg/template-inheritance.texy @@ -132,7 +132,7 @@ - Ако използвате `{layout}` в шаблон, той трябва да бъде първият таг на шаблона в този шаблон. -- Макетът може да се [търси автоматично |develop#automatic-layout-lookup] (както в [презентаторите |application:templates#search-for-templates]). В този случай, ако шаблонът не трябва да има оформление, той ще посочи това с тага `{layout none}`. +- Макетът може да се [търси автоматично |develop#automatic-layout-lookup] (както в [презентаторите |application:templates#Template Lookup]). В този случай, ако шаблонът не трябва да има оформление, той ще посочи това с тага `{layout none}`. - Тагът `{layout}` има псевдоним `{extends}`. diff --git a/latte/de/template-inheritance.texy b/latte/de/template-inheritance.texy index 1741888e5e..0f57bdd16e 100644 --- a/latte/de/template-inheritance.texy +++ b/latte/de/template-inheritance.texy @@ -132,7 +132,7 @@ Hier finden Sie einige Tipps für die Arbeit mit Layoutvererbung: - Wenn Sie `{layout}` in einer Vorlage verwenden, muss es das erste Vorlagen-Tag in dieser Vorlage sein. -- Das Layout kann [automatisch gesucht |develop#automatic-layout-lookup] werden (wie bei [Präsentationen |application:templates#search-for-templates]). In diesem Fall, wenn die Vorlage kein Layout haben sollte, wird dies mit dem Tag `{layout none}` angezeigt. +- Das Layout kann [automatisch gesucht |develop#automatic-layout-lookup] werden (wie bei [Präsentationen |application:templates#Template Lookup]). In diesem Fall, wenn die Vorlage kein Layout haben sollte, wird dies mit dem Tag `{layout none}` angezeigt. - Das Tag `{layout}` hat den Alias `{extends}`. diff --git a/latte/el/template-inheritance.texy b/latte/el/template-inheritance.texy index 1c544fdb1b..321ee58522 100644 --- a/latte/el/template-inheritance.texy +++ b/latte/el/template-inheritance.texy @@ -132,7 +132,7 @@ - Εάν χρησιμοποιείτε το `{layout}` σε ένα πρότυπο, πρέπει να είναι η πρώτη ετικέτα προτύπου σε αυτό το πρότυπο. -- Η διάταξη μπορεί να [αναζητηθεί αυτόματα |develop#automatic-layout-lookup] (όπως στους [παρουσιαστές |application:templates#search-for-templates]). Σε αυτή την περίπτωση, αν το πρότυπο δεν πρέπει να έχει διάταξη, θα το υποδείξει με την ετικέτα `{layout none}`. +- Η διάταξη μπορεί να [αναζητηθεί αυτόματα |develop#automatic-layout-lookup] (όπως στους [παρουσιαστές |application:templates#Template Lookup]). Σε αυτή την περίπτωση, αν το πρότυπο δεν πρέπει να έχει διάταξη, θα το υποδείξει με την ετικέτα `{layout none}`. - Η ετικέτα `{layout}` έχει ψευδώνυμο `{extends}`. diff --git a/latte/en/template-inheritance.texy b/latte/en/template-inheritance.texy index 5294812f14..9e734e9382 100644 --- a/latte/en/template-inheritance.texy +++ b/latte/en/template-inheritance.texy @@ -132,7 +132,7 @@ Here are some tips for working with layout inheritance: - If you use `{layout}` in a template, it must be the first template tag in that template. -- Layout can be [searched automatically |develop#automatic-layout-lookup] (like in [presenters |application:templates#search-for-templates]). In this case, if the template should not have a layout, it will indicate this with the `{layout none}` tag. +- Layout can be [searched automatically |develop#automatic-layout-lookup] (like in [presenters |application:templates#Template Lookup]). In this case, if the template should not have a layout, it will indicate this with the `{layout none}` tag. - Tag `{layout}` has alias `{extends}`. diff --git a/latte/es/template-inheritance.texy b/latte/es/template-inheritance.texy index 61607723aa..f3d3b430cc 100644 --- a/latte/es/template-inheritance.texy +++ b/latte/es/template-inheritance.texy @@ -132,7 +132,7 @@ Aquí tienes algunos consejos para trabajar con la herencia de diseños: - Si utiliza `{layout}` en una plantilla, debe ser la primera etiqueta de plantilla en esa plantilla. -- La maquetación puede [buscarse automáticamente |develop#automatic-layout-lookup] (como en [los presentadores |application:templates#search-for-templates]). En este caso, si la plantilla no debe tener un diseño, lo indicará con la etiqueta `{layout none}`. +- La maquetación puede [buscarse automáticamente |develop#automatic-layout-lookup] (como en [los presentadores |application:templates#Template Lookup]). En este caso, si la plantilla no debe tener un diseño, lo indicará con la etiqueta `{layout none}`. - La etiqueta `{layout}` tiene el alias `{extends}`. diff --git a/latte/fr/template-inheritance.texy b/latte/fr/template-inheritance.texy index d0b17c5615..f8dbf93934 100644 --- a/latte/fr/template-inheritance.texy +++ b/latte/fr/template-inheritance.texy @@ -132,7 +132,7 @@ Voici quelques conseils pour travailler avec l'héritage de mise en page : - Si vous utilisez `{layout}` dans un modèle, il doit s'agir de la première balise de modèle de ce modèle. -- La mise en page peut être [recherchée automatiquement |develop#automatic-layout-lookup] (comme dans les [présentateurs |application:templates#search-for-templates]). Dans ce cas, si le modèle ne doit pas avoir de mise en page, il l'indiquera avec la balise `{layout none}`. +- La mise en page peut être [recherchée automatiquement |develop#automatic-layout-lookup] (comme dans les [présentateurs |application:templates#Template Lookup]). Dans ce cas, si le modèle ne doit pas avoir de mise en page, il l'indiquera avec la balise `{layout none}`. - La balise `{layout}` a un alias `{extends}`. diff --git a/latte/hu/template-inheritance.texy b/latte/hu/template-inheritance.texy index eee1de2384..561a7bae06 100644 --- a/latte/hu/template-inheritance.texy +++ b/latte/hu/template-inheritance.texy @@ -132,7 +132,7 @@ Tippek .[#toc-tips] - Ha a `{layout}` címet használja egy sablonban, akkor annak a sablonban az első sabloncímkének kell lennie. -- Az elrendezés [automatikusan kereshető |develop#automatic-layout-lookup] (mint [az előadókban |application:templates#search-for-templates]). Ebben az esetben, ha a sablonban nem kell elrendezés, akkor ezt a `{layout none}` címkével jelzi. +- Az elrendezés [automatikusan kereshető |develop#automatic-layout-lookup] (mint [az előadókban |application:templates#Template Lookup]). Ebben az esetben, ha a sablonban nem kell elrendezés, akkor ezt a `{layout none}` címkével jelzi. - A `{layout}` címkének a `{extends}` aliasával rendelkezik. diff --git a/latte/it/template-inheritance.texy b/latte/it/template-inheritance.texy index ede86caa3c..be6be739eb 100644 --- a/latte/it/template-inheritance.texy +++ b/latte/it/template-inheritance.texy @@ -132,7 +132,7 @@ Ecco alcuni suggerimenti per lavorare con l'ereditarietà dei layout: - Se si usa `{layout}` in un modello, deve essere il primo tag del modello in quel modello. -- Il layout può essere [cercato automaticamente |develop#automatic-layout-lookup] (come nei [presentatori |application:templates#search-for-templates]). In questo caso, se il modello non deve avere un layout, lo indicherà con il tag `{layout none}`. +- Il layout può essere [cercato automaticamente |develop#automatic-layout-lookup] (come nei [presentatori |application:templates#Template Lookup]). In questo caso, se il modello non deve avere un layout, lo indicherà con il tag `{layout none}`. - Il tag `{layout}` ha l'alias `{extends}`. diff --git a/latte/ja/template-inheritance.texy b/latte/ja/template-inheritance.texy index a1fb0e9823..6ed251797f 100644 --- a/latte/ja/template-inheritance.texy +++ b/latte/ja/template-inheritance.texy @@ -132,7 +132,7 @@ Latteのテンプレート継承のコンセプトは、PHPのクラス継承に - テンプレート内で`{layout}` を使用する場合、そのテンプレート内の最初のテンプレートタグでなければなりません。 -- レイアウトは[自動的に検索 |develop#automatic-layout-lookup]することができます（[プレゼンターの |application:en:templates#search-for-templates]ように）。この場合、テンプレートがレイアウトを持つべきではない場合は、`{layout none}` タグでその旨を表示します。 +- レイアウトは[自動的に検索 |develop#automatic-layout-lookup]することができます（[プレゼンターの |application:en:templates#Template Lookup]ように）。この場合、テンプレートがレイアウトを持つべきではない場合は、`{layout none}` タグでその旨を表示します。 - タグ`{layout}` はエイリアス`{extends}` を持ちます。 diff --git a/latte/pl/template-inheritance.texy b/latte/pl/template-inheritance.texy index 2488266e2b..25483c9fab 100644 --- a/latte/pl/template-inheritance.texy +++ b/latte/pl/template-inheritance.texy @@ -132,7 +132,7 @@ Oto kilka wskazówek dotyczących pracy z dziedziczeniem układów: - Jeśli używasz `{layout}` w szablonie , musi to być pierwszy tag szablonu w tym szablonie. -- Układ może być [wyszukiwany automatycznie |develop#automatic-layout-lookup] (jak w [prezenterach |application:templates#search-for-templates]). W takim przypadku, jeśli szablon nie powinien mieć układu, wskaże to za pomocą znacznika `{layout none}`. +- Układ może być [wyszukiwany automatycznie |develop#automatic-layout-lookup] (jak w [prezenterach |application:templates#Template Lookup]). W takim przypadku, jeśli szablon nie powinien mieć układu, wskaże to za pomocą znacznika `{layout none}`. - Znacznik `{layout}` ma alias `{extends}`. diff --git a/latte/pt/template-inheritance.texy b/latte/pt/template-inheritance.texy index 2a426f0cd7..daf38bde1b 100644 --- a/latte/pt/template-inheritance.texy +++ b/latte/pt/template-inheritance.texy @@ -132,7 +132,7 @@ Aqui estão algumas dicas para trabalhar com a herança de layout: - Se você usar `{layout}` em um template, ele deve ser a primeira etiqueta do template nesse template. -- O layout pode ser [pesquisado automaticamente |develop#automatic-layout-lookup] (como nos [apresentadores |application:templates#search-for-templates]). Nesse caso, se o modelo não tiver um layout, ele indicará isso com a tag `{layout none}`. +- O layout pode ser [pesquisado automaticamente |develop#automatic-layout-lookup] (como nos [apresentadores |application:templates#Template Lookup]). Nesse caso, se o modelo não tiver um layout, ele indicará isso com a tag `{layout none}`. - A tag `{layout}` tem o pseudônimo `{extends}`. diff --git a/latte/ro/template-inheritance.texy b/latte/ro/template-inheritance.texy index 77075ed241..4b8ffe5bdc 100644 --- a/latte/ro/template-inheritance.texy +++ b/latte/ro/template-inheritance.texy @@ -132,7 +132,7 @@ Iată câteva sfaturi pentru a lucra cu moștenirea aspectului: - Dacă utilizați `{layout}` într-un șablon, trebuie să fie prima etichetă de șablon din șablonul respectiv. -- Layout-ul poate fi [căutat în mod automat |develop#automatic-layout-lookup] (la fel ca în [prezentări |application:templates#search-for-templates]). În acest caz, dacă șablonul nu ar trebui să aibă un layout, se va indica acest lucru cu eticheta `{layout none}`. +- Layout-ul poate fi [căutat în mod automat |develop#automatic-layout-lookup] (la fel ca în [prezentări |application:templates#Template Lookup]). În acest caz, dacă șablonul nu ar trebui să aibă un layout, se va indica acest lucru cu eticheta `{layout none}`. - Eticheta `{layout}` are aliasul `{extends}`. diff --git a/latte/ru/template-inheritance.texy b/latte/ru/template-inheritance.texy index bc728af54a..362f08b420 100644 --- a/latte/ru/template-inheritance.texy +++ b/latte/ru/template-inheritance.texy @@ -132,7 +132,7 @@ - Если вы используете `{layout}` в шаблоне, он должен быть первым тегом шаблона в этом шаблоне. -- Макет может [искаться автоматически |develop#automatic-layout-lookup] (как в [презентаторах |application:templates#search-for-templates]). В этом случае, если шаблон не должен иметь макета, он укажет на это с помощью тега `{layout none}`. +- Макет может [искаться автоматически |develop#automatic-layout-lookup] (как в [презентаторах |application:templates#Template Lookup]). В этом случае, если шаблон не должен иметь макета, он укажет на это с помощью тега `{layout none}`. - Тег `{layout}` имеет псевдоним `{extends}`. diff --git a/latte/sl/template-inheritance.texy b/latte/sl/template-inheritance.texy index e5b6da9144..d749775406 100644 --- a/latte/sl/template-inheritance.texy +++ b/latte/sl/template-inheritance.texy @@ -132,7 +132,7 @@ Tukaj je nekaj nasvetov za delo z dedovanjem postavitve: - Če v predlogi uporabite `{layout}`, mora biti to prva oznaka v predlogi. -- Postavitev lahko [iščete samodejno |develop#automatic-layout-lookup] (kot v [predstavitvah |application:templates#search-for-templates]). Če v tem primeru predloga ne sme imeti postavitve, se to označi z oznako `{layout none}`. +- Postavitev lahko [iščete samodejno |develop#automatic-layout-lookup] (kot v [predstavitvah |application:templates#Template Lookup]). Če v tem primeru predloga ne sme imeti postavitve, se to označi z oznako `{layout none}`. - Oznaka `{layout}` ima vzdevek `{extends}`. diff --git a/latte/tr/template-inheritance.texy b/latte/tr/template-inheritance.texy index 92db9e8c6c..b681815e53 100644 --- a/latte/tr/template-inheritance.texy +++ b/latte/tr/template-inheritance.texy @@ -132,7 +132,7 @@ Düzen kalıtımı ile çalışmak için bazı ipuçları: - Bir şablonda `{layout}` kullanıyorsanız, bu şablondaki ilk şablon etiketi olmalıdır. -- Düzen [otomatik olarak aranabilir |develop#automatic-layout-lookup] ( [sunumlarda |application:templates#search-for-templates] olduğu gibi). Bu durumda, şablonun bir düzene sahip olmaması gerekiyorsa, bunu `{layout none}` etiketi ile belirtecektir. +- Düzen [otomatik olarak aranabilir |develop#automatic-layout-lookup] ( [sunumlarda |application:templates#Template Lookup] olduğu gibi). Bu durumda, şablonun bir düzene sahip olmaması gerekiyorsa, bunu `{layout none}` etiketi ile belirtecektir. - `{layout}` etiketinin `{extends}` takma adı vardır. diff --git a/latte/uk/template-inheritance.texy b/latte/uk/template-inheritance.texy index 0db6e1062e..c4fd39ba89 100644 --- a/latte/uk/template-inheritance.texy +++ b/latte/uk/template-inheritance.texy @@ -132,7 +132,7 @@ - Якщо ви використовуєте `{layout}` у шаблоні, він має бути першим тегом шаблону в цьому шаблоні. -- Макет можна [шукати автоматично |develop#automatic-layout-lookup] (як у [презентаторах |application:templates#search-for-templates]). У цьому випадку, якщо шаблон не повинен мати макет, він вкаже на це тегом `{layout none}`. +- Макет можна [шукати автоматично |develop#automatic-layout-lookup] (як у [презентаторах |application:templates#Template Lookup]). У цьому випадку, якщо шаблон не повинен мати макет, він вкаже на це тегом `{layout none}`. - Тег `{layout}` має псевдонім `{extends}`. diff --git a/quickstart/bg/@home.texy b/quickstart/bg/@home.texy index 6a69c02c80..ef481e0351 100644 --- a/quickstart/bg/@home.texy +++ b/quickstart/bg/@home.texy @@ -45,9 +45,9 @@ http://localhost/nette-blog/www/ /--pre nette-blog/ ├── app/ ← каталог приложения -│ ├── Presenters/ ← классы презентеров -│ │ └── templates/← шаблоны -│ ├── Router/ ← конфигурация адресов URL +│ ├── Core/ ← основни необходими класове +│ ├── UI/ ← презентатори, шаблони и др. +│ │ └── Home/ ← Каталог на водещите │ └── Bootstrap.php ← загрузочный класс Bootstrap ├── bin/ ← скрипты для командной строки ├── config/ ← конфигурационные файлы @@ -67,7 +67,7 @@ http://localhost/nette-blog/www/ Почистване .[#toc-cleanup] ========================== -Уеб проектът съдържа начална страница, която можем да премахнем - не се колебайте да замените съдържанието на файла `app/Presenters/templates/Home/default.latte` с текста `Hello world!`. +Уеб проектът съдържа начална страница, която можем да премахнем - не се колебайте да замените съдържанието на файла `app/UI/Home/default.latte` с текста `Hello world!`. [* qs-hello.webp .{url:-} *] @@ -76,9 +76,9 @@ http://localhost/nette-blog/www/ Tracy (дебъгер) .[#toc-tracy-debugger] ====================================== -Изключително важен инструмент за разработка е [дебъгер, наречен Tracy. |tracy:] Опитайте се да направите някои грешки във вашия файл `app/Presenters/HomePresenter.php` (например да премахнете къдравата скоба от дефиницията на класа HomePresenter) и вижте какво ще се случи. Ще се появи страница с червен екран и разбираемо описание на грешката. +Изключително важен инструмент за разработка е [дебъгер, наречен Tracy. |tracy:] Опитайте се да направите някои грешки във вашия файл `app/UI/Home/HomePresenter.php` (например да премахнете къдравата скоба от дефиницията на класа HomePresenter) и вижте какво ще се случи. Ще се появи страница с червен екран и разбираемо описание на грешката. -[* qs-tracy.webp .{url:-}(debugger screen) *] +[* qs-tracy.avif .{url:-}(debugger screen) *] Трейси ще ви помогне значително да откриете грешките. Обърнете внимание и на плаващата лента Tracy Bar в долния десен ъгъл, която ви информира за важни данни по време на работа. diff --git a/quickstart/bg/authentication.texy b/quickstart/bg/authentication.texy index 4950637a2b..81d340662e 100644 --- a/quickstart/bg/authentication.texy +++ b/quickstart/bg/authentication.texy @@ -28,9 +28,9 @@ Nette автоматично ще създаде услуга в контейн Нека започнем с формата за вход. Вече знаете как работят формулярите в програмата Presenter. Създайте `SignPresenter` и метод `createComponentSignInForm`. Това трябва да изглежда по следния начин: -```php .{file:app/Presenters/SignPresenter.php} +```php .{file:app/UI/Sign/SignPresenter.php} Войти @@ -77,7 +77,7 @@ final class SignPresenter extends Nette\Application\UI\Presenter Обслужващият модул просто взема потребителското име и паролата, които потребителят е въвел, и ги предава на удостоверителя. След като влезете в системата, ще ви пренасочим към началната страница: -```php .{file:app/Presenters/SignPresenter.php} +```php .{file:app/UI/Sign/SignPresenter.php} private function signInFormSucceeded(Form $form, \stdClass $data): void { try { @@ -102,7 +102,7 @@ private function signInFormSucceeded(Form $form, \stdClass $data): void Ще създадем метод `startup()`, който се изпълнява веднага в началото на [жизнения цикъл на презентатора |application:presenters#Life-Cycle-of-Presenter]. Това пренасочва нерегистрираните потребители към формата за вход. -```php .{file:app/Presenters/EditPresenter.php} +```php .{file:app/UI/Edit/EditPresenter.php} public function startup(): void { parent::startup(); @@ -117,7 +117,7 @@ public function startup(): void Скриване на връзки .[#toc-hide-links] ------------------------------------- -Неоторизиран потребител вече не може да вижда страниците за създаване и редактиране, но все още може да вижда връзките, които сочат към тях. Нека скрием и тях. Една такава връзка се намира на адрес `app/Presenters/templates/Home/default.latte`, като тя трябва да бъде видима само ако потребителят е влязъл в системата. +Неоторизиран потребител вече не може да вижда страниците за създаване и редактиране, но все още може да вижда връзките, които сочат към тях. Нека скрием и тях. Една такава връзка се намира на адрес `app/UI/Home/default.latte`, като тя трябва да бъде видима само ако потребителят е влязъл в системата. Можем да го скрием, като използваме *n:атрибута*, наречен `n:if`. Ако изявлението в него е `false`, тогава целият таг `` и съдържанието му няма да бъде показано: @@ -131,15 +131,15 @@ public function startup(): void {if $user->isLoggedIn()}Создать пост{/if} ``` -По същия начин скрийте връзката за редактиране, намираща се на адрес `app/Presenters/templates/Post/show.latte`. +По същия начин скрийте връзката за редактиране, намираща се на адрес `app/UI/Post/show.latte`. Връзка към формуляра за влизане .[#toc-login-form-link] ======================================================= -Здравейте, но как да стигнем до страницата за вход? Няма връзка, която да сочи към него. Нека да го добавим към файла с шаблона `app/Presenters/templates/@layout.latte`. Опитайте се да намерите добро място, може да е всяко място, което ви харесва най-много. +Здравейте, но как да стигнем до страницата за вход? Няма връзка, която да сочи към него. Нека да го добавим към файла с шаблона `app/UI/@layout.latte`. Опитайте се да намерите добро място, може да е всяко място, което ви харесва най-много. -```latte .{file:app/Presenters/templates/@layout.latte} +```latte .{file:app/UI/@layout.latte} ...
  • Главная
    • @@ -156,7 +156,7 @@ public function startup(): void Действието за излизане от системата изглежда по следния начин и тъй като пренасочваме потребителя веднага, няма нужда от шаблон на изгледа: -```php .{file:app/Presenters/SignPresenter.php} +```php .{file:app/UI/Sign/SignPresenter.php} public function actionOut(): void { $this->getUser()->logout(); diff --git a/quickstart/bg/comments.texy b/quickstart/bg/comments.texy index be67b39c24..d401e0eb9c 100644 --- a/quickstart/bg/comments.texy +++ b/quickstart/bg/comments.texy @@ -44,7 +44,7 @@ CREATE TABLE `comments` ( Nette има понятие за *компоненти*. **Компонент** е клас или част от кода за многократна употреба, който може да бъде прикрепен към друг компонент. Дори водещият е компонент. Всеки компонент се създава с помощта на фабрика за компоненти. И така, нека дефинираме фабриката за формуляри за коментари в `PostPresenter`. -```php .{file:app/Presenters/PostPresenter.php} +```php .{file:app/UI/Post/PostPresenter.php} protected function createComponentCommentForm(): Form { $form = new Form; // означава Nette\Application\UI\Form @@ -65,9 +65,9 @@ protected function createComponentCommentForm(): Form Нека да го обясним малко. Първият ред създава нова инстанция на компонента `Form`. Методите по-долу поставят HTML елементите *input* във формуляра. `->addText` ще се покаже като ``, с ``. Както вече сте се досетили, `->addTextArea` прикрепя `