-
- {foreach $list as $id => $item}
-
- {$item} обновить - {/foreach} -
-
+ {foreach $items as $id => $item}
+
- {$item} + {/foreach} +
-
- {foreach $list as $id => $item}
-
- {$item} обновить - {/foreach} -
-
-Bootstrap е кодът на bootstrap, който инициализира средата, създава контейнера за изпълнение на зависимости (DI) и стартира приложението. Обсъждаме:
-
-- Как да настроите приложение, използващо файлове NEON
-- Как да работите с режими за производство и разработка
-- Как да създадете контейнер DI
-
-
-
-
-Приложенията, независимо дали са уеб приложения или скриптове от команден ред, започват с инициализиране на средата под една или друга форма. В древни времена за това може да е отговарял файл, наречен например `include.inc.php`, който е бил включен в изходния файл.
-В съвременните приложения на Nette той е заменен с класа `Bootstrap`, който се намира като част от приложението във файла `app/Bootstrap.php`. Това може да изглежда например така:
-
-```php
-use Nette\Bootstrap\Configurator;
-
-class Bootstrap
-{
- public static function boot(): Configurator
- {
- $appDir = dirname(__DIR__);
- $configurator = new Configurator;
- //$configurator->setDebugMode('secret@23.75.345.200');
- $configurator->enableTracy($appDir . '/log');
- $configurator->setTempDirectory($appDir . '/temp');
- $configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
- $configurator->addConfig($appDir . '/config/common.neon');
- return $configurator;
- }
-}
-```
-
-
-index.php .[#toc-index-php]
-===========================
-
-В случая на уеб приложения началният файл е `index.php`, който се намира в публичната директория `www/`. Той позволява на класа `Bootstrap` да инициализира средата и връща `$configurator`, който създава контейнера DI. След това тя извлича услугата `Application`, която стартира уеб приложението:
-
-```php
-// инициализиране на средата + получаване на обект Configurator
-$configurator = App\Bootstrap::boot();
-// създаване на DI-контейнер
-$container = $configurator->createContainer();
-// DI-контейнерът ще създаде обект Nette\Application\Application
-$application = $container->getByType(Nette\Application\Application::class);
-//стартиране на приложението Nette
-$application->run();
-```
-
-Както виждате, класът [api:Nette\Bootstrap\Configurator], който сега ще представим по-подробно, помага при настройването на средата и създаването на контейнера за инжектиране на зависимости (DI).
-
-
-Режим на разработка и производствен режим .[#toc-development-vs-production-mode]
-================================================================================
-
-Nette прави разграничение между два основни режима, в които се изпълнява заявката: разработка и производство. Режимът за разработка е насочен към максимално удобство за програмиста, показва се Tracy, кешът се обновява автоматично при промяна на шаблоните или конфигурацията на DI контейнера и т.н. Производственият режим е ориентиран към производителността, Tracy регистрира само грешки, а промените в шаблоните и другите файлове не се проверяват.
-
-Режимът се избира чрез автоматично разпознаване, така че обикновено не е необходимо да конфигурирате или превключвате нещо ръчно. Режимът за разработка се използва, ако приложението се изпълнява на локален хост (т.е. IP адресът е `127.0.0.1` или `::1`) и няма прокси сървър (т.е. HTTP заглавието му). В противен случай приложението работи в производствен режим.
-
-Ако искате да активирате режима за разработка в други случаи, например за програмисти, които имат достъп от определен IP адрес, можете да използвате `setDebugMode()`:
-
-```php
-$configurator->setDebugMode('23.75.345.200'); // един или повече IP адреси
-```
-
-Определено препоръчваме да комбинирате IP адреса с "бисквитка". Ще съхраним тайния токен в "бисквитката" `nette-debug', например, `secret1234`, а режимът за разработка ще бъде активиран за програмистите с тази комбинация от IP и "бисквитка".
-
-```php
-$configurator->setDebugMode('secret1234@23.75.345.200');
-```
-
-Можете да деактивирате напълно режима за разработчици, дори за localhost:
-
-```php
-$configurator->setDebugMode(false);
-```
-
-Обърнете внимание, че стойността `true` активира плътно режима за разработчици, което никога не трябва да се случва на производствен сървър.
-
-
-Инструмент за отстраняване на грешки в Tracy .[#toc-debugging-tool-tracy]
-=========================================================================
-
-За да улесним дебъгването, ще включим чудесния инструмент [Tracy |tracy:]. В режим за разработчици той визуализира грешките, а в производствен режим записва грешките в определена директория:
-
-```php
-$configurator->enableTracy($appDir . '/log');
-```
-
-
-Временни файлове .[#toc-temporary-files]
-========================================
-
-Nette използва кеш за DI-контейнер, RobotLoader, шаблони и др. Затова е необходимо да се зададе пътят до директорията, в която се съхранява кешът:
-
-```php
-$configurator->setTempDirectory($appDir . '/temp');
-```
-
-В Linux или macOS задайте [разрешения за запис |nette:troubleshooting#Setting-Directory-Permissions] за директориите `log/` и `temp/`.
-
-
-RobotLoader .[#toc-robotloader]
-===============================
-
-Обикновено искаме да заредим класовете автоматично с помощта на [RobotLoader |robot-loader:], така че трябва да го стартираме и да му позволим да зареди класовете от директорията, в която се намира `Bootstrap.php` (т.е. `__DIR__`) и всички негови поддиректории:
-
-```php
-$configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
-```
-
-Алтернативен начин е да се използва само автозадаващото устройство PSR-4 [Composer |best-practices:composer].
-
-
-Часова зона .[#toc-timezone]
-============================
-
-Конфигураторът ви позволява да зададете часовата зона за вашето приложение.
-
-```php
-$configurator->setTimeZone('Europe/Prague');
-```
-
-
-Конфигурация на DI-контейнер .[#toc-di-container-configuration]
-===============================================================
-
-Част от процеса на изтегляне е създаването на контейнера DI, т.е. фабриката за обекти, която е сърцето на цялото приложение. Всъщност това е клас на PHP, създаден от Nette и съхраняван в директория за кеш. Фабриката създава ключовите обекти на приложението, а конфигурационните файлове я инструктират как да ги създава и конфигурира, като по този начин влияем върху поведението на цялото приложение.
-
-Файловете за конфигурация обикновено се записват във формат [NEON |neon:format]. Можете да прочетете [какво може да се конфигурира тук |nette:configuring].
-
-.[tip]
-В режим на разработка контейнерът се актуализира автоматично при всяка промяна на кода или конфигурационните файлове. В производствен режим той се генерира само веднъж и промените във файловете не се проверяват за максимална производителност.
-
-Файловете за конфигурация се зареждат с помощта на `addConfig()`:
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-```
-
-Методът `addConfig()` може да се извика няколко пъти, за да се добавят няколко файла.
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-$configurator->addConfig($appDir . '/config/local.neon');
-if (PHP_SAPI === 'cli') {
- $configurator->addConfig($appDir . '/config/cli.php');
-}
-```
-
-Свързването `cli.php` не е печатна грешка, конфигурацията може да бъде записана и в PHP файл, който я връща като масив.
-
-Като алтернатива можем да използваме [раздела `includes` |dependency-injection:configuration#Including-Files] за зареждане на конфигурационни файлове.
-
-Ако в конфигурационните файлове се появят елементи със същите ключове, те ще бъдат [презаписани или обединени в |dependency-injection:configuration#Merging] случай на масиви. По-късно включен файл има по-висок приоритет от предишния. Файлът, посочен в раздела `includes`, има по-висок приоритет от файловете, включени в него.
-
-
-Статични параметри .[#toc-static-parameters]
---------------------------------------------
-
-Параметрите, използвани в конфигурационните файлове, могат да бъдат дефинирани [в раздела `parameters` |dependency-injection:configuration#parameters] и да бъдат взети (или презаписани) от метода `addStaticParameters()` (той има псевдоним `addParameters()`). Важно е, че различните стойности на параметрите водят до генериране на допълнителни DI-контейнери, т.е. допълнителни класове.
-
-```php
-$configurator->addStaticParameters([
- 'projectId' => 23,
-]);
-```
-
-Конфигурационните файлове могат да използват нормалния запис `%projectId%` за достъп до параметъра с име `projectId`. По подразбиране конфигураторът попълва следните параметри: `appDir`, `wwwDir`, `tempDir`, `vendorDir`, `debugMode` и `consoleMode`.
-
-
-Динамични параметри .[#toc-dynamic-parameters]
-----------------------------------------------
-
-Възможно е също така да се добавят динамични параметри към контейнер. Различните им стойности, за разлика от статичните параметри, не генерират нови контейнери DI.
-
-```php
-$configurator->addDynamicParameters([
- 'remoteIp' => $_SERVER['REMOTE_ADDR'],
-]);
-```
-
-Достъпът до променливите на средата е лесен с помощта на динамични параметри. Достъпът до тях се осъществява чрез `%env.variable%` в конфигурационните файлове.
-
-```php
-$configurator->addDynamicParameters([
- 'env' => getenv(),
-]);
-```
-
-
-Внесени услуги .[#toc-imported-services]
-----------------------------------------
-
-Нека се задълбочим. Въпреки че целта на контейнера DI е да създава обекти, може да се наложи в контейнера да се вмъкне съществуващ обект. Това става чрез дефиниране на услуга с атрибута `imported: true`:
-
-```neon
-services:
- myservice:
- type: App\Model\MyCustomService
- imported: true
-```
-
-Създайте нов екземпляр и го вмъкнете в Bootstrap:
-
-```php
-$configurator->addServices([
- 'myservice' => new App\Model\MyCustomService('foobar'),
-]);
-```
-
-
-Различни среди .[#toc-different-environments]
-=============================================
-
-Не се колебайте да персонализирате класа `Bootstrap` според нуждите си. Можете да добавите параметри към метода `boot()`, за да разделите уеб проектите, или да добавите други методи, като например `bootForTests()`, който инициализира средата за тестове на единици, `bootForCli()` за скриптове, извикани от командния ред, и т.н.
-
-```php
-public static function bootForTests(): Configurator
-{
- $configurator = self::boot();
- Tester\Environment::setup(); // Инициализация Nette Tester
- return $configurator;
-}
-```
diff --git a/application/bg/bootstrapping.texy b/application/bg/bootstrapping.texy
new file mode 100644
index 0000000000..12decd318d
--- /dev/null
+++ b/application/bg/bootstrapping.texy
@@ -0,0 +1,297 @@
+Зареждане
+*********
+
+
+
+Зареждането е процесът на инициализиране на средата на приложението, създаване на контейнер за инжектиране на зависимости (DI) и стартиране на приложението. Ще обсъдим:
+
+- как класът Bootstrap инициализира средата
+- как приложенията се конфигурират чрез NEON файлове
+- как да разграничаваме между производствен и разработчически режим
+- как да създаваме и конфигурираме DI контейнера
+
+
+
+
+Приложенията, независимо дали са уеб или скриптове, стартирани от командния ред, започват своята работа с някаква форма на инициализация на средата. В миналото за това отговаряше файл с име например `include.inc.php`, който първоначалният файл включваше. В съвременните Nette приложения той е заменен от клас `Bootstrap`, който като част от приложението ще намерите във файла `app/Bootstrap.php`. Може да изглежда например така:
+
+```php
+use Nette\Bootstrap\Configurator;
+
+class Bootstrap
+{
+ private Configurator $configurator;
+ private string $rootDir;
+
+ public function __construct()
+ {
+ $this->rootDir = dirname(__DIR__);
+ // Конфигураторът е отговорен за настройката на средата на приложението и сървисите.
+ $this->configurator = new Configurator;
+ // Задава директорията за временни файлове, генерирани от Nette (напр. компилирани шаблони)
+ $this->configurator->setTempDirectory($this->rootDir . '/temp');
+ }
+
+ public function bootWebApplication(): Nette\DI\Container
+ {
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+ }
+
+ private function initializeEnvironment(): void
+ {
+ // Nette е умно и режимът за разработка се включва автоматично,
+ // или можете да го разрешите за конкретен IP адрес, като разкоментирате следния ред:
+ // $this->configurator->setDebugMode('secret@23.75.345.200');
+
+ // Активира Tracy: ултимативният "швейцарски нож" за дебъгване.
+ $this->configurator->enableTracy($this->rootDir . '/log');
+
+ // RobotLoader: автоматично зарежда всички класове в избраната директория
+ $this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+ }
+
+ private function setupContainer(): void
+ {
+ // Зарежда конфигурационните файлове
+ $this->configurator->addConfig($this->rootDir . '/config/common.neon');
+ }
+}
+```
+
+
+index.php
+=========
+
+Първоначалният файл в случай на уеб приложения е `index.php`, който се намира в [публичната директория |directory-structure#Публична директория www] `www/`. Той изисква от клас Bootstrap да инициализира средата и да създаде DI контейнер. След това от него получава сървиса `Application`, който стартира уеб приложението:
+
+```php
+$bootstrap = new App\Bootstrap;
+// Инициализация на средата + създаване на DI контейнер
+$container = $bootstrap->bootWebApplication();
+// DI контейнерът създава обект Nette\Application\Application
+$application = $container->getByType(Nette\Application\Application::class);
+// Стартиране на приложението Nette и обработка на входящата заявка
+$application->run();
+```
+
+Както се вижда, с настройката на средата и създаването на dependency injection (DI) контейнер помага класът [api:Nette\Bootstrap\Configurator], който сега ще разгледаме по-подробно.
+
+
+Режим за разработка срещу продукционен режим
+============================================
+
+Nette се държи различно в зависимост от това дали работи на сървър за разработка или на продукционен сървър:
+
+🛠️ Режим за разработка (Development):
+ - Показва Tracy debugbar с полезна информация (SQL заявки, време за изпълнение, използвана памет)
+ - При грешка показва подробна страница за грешка с извиквания на функции и съдържание на променливи
+ - Автоматично обновява кеша при промяна на Latte шаблони, редактиране на конфигурационни файлове и т.н.
+
+
+🚀 Продукционен режим (Production):
+ - Не показва никаква информация за дебъгване, всички грешки се записват в лога
+ - При грешка показва ErrorPresenter или обща страница "Server Error"
+ - Кешът никога не се обновява автоматично!
+ - Оптимизиран за скорост и сигурност
+
+
+Изборът на режим се извършва чрез автодетекция, така че обикновено не е необходимо нищо да се конфигурира или ръчно да се превключва:
+
+- режим за разработка: на localhost (IP адрес `127.0.0.1` или `::1`), ако няма прокси (т.е. неговия HTTP хедър)
+- продукционен режим: навсякъде другаде
+
+Ако искаме да разрешим режима за разработка и в други случаи, например за програмисти, достъпващи от конкретен IP адрес, използваме `setDebugMode()`:
+
+```php
+$this->configurator->setDebugMode('23.75.345.200'); // може да се посочи и масив от IP адреси
+```
+
+Определено препоръчваме да комбинирате IP адрес с бисквитка. В бисквитката `nette-debug` ще запазим таен токен, напр. `secret1234`, и по този начин ще активираме режима за разработка за програмисти, достъпващи от конкретен IP адрес и същевременно имащи споменатия токен в бисквитката:
+
+```php
+$this->configurator->setDebugMode('secret1234@23.75.345.200');
+```
+
+Можем също така да изключим напълно режима за разработка, дори и за localhost:
+
+```php
+$this->configurator->setDebugMode(false);
+```
+
+Внимание, стойността `true` включва режима за разработка принудително, което никога не трябва да се случва на продукционен сървър.
+
+
+Инструмент за дебъгване Tracy
+=============================
+
+За лесно дебъгване ще включим и страхотния инструмент [Tracy |tracy:]. В режим за разработка той визуализира грешките, а в продукционен режим ги записва в лога в посочената директория:
+
+```php
+$this->configurator->enableTracy($this->rootDir . '/log');
+```
+
+
+Временни файлове
+================
+
+Nette използва кеш за DI контейнер, RobotLoader, шаблони и т.н. Затова е необходимо да се зададе път до директорията, където ще се съхранява кешът:
+
+```php
+$this->configurator->setTempDirectory($this->rootDir . '/temp');
+```
+
+На Linux или macOS задайте на директориите `log/` и `temp/` [права за запис |nette:troubleshooting#Настройка на правата на директориите].
+
+
+RobotLoader
+===========
+
+Обикновено ще искаме автоматично да зареждаме класове с помощта на [RobotLoader |robot-loader:], затова трябва да го стартираме и да го накараме да зарежда класове от директорията, където се намира `Bootstrap.php` (т.е. `__DIR__`), и всички поддиректории:
+
+```php
+$this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+```
+
+Алтернативен подход е да оставите класовете да се зареждат само чрез [Composer |best-practices:composer] при спазване на PSR-4.
+
+
+Часова зона
+===========
+
+Чрез конфигуратора можете да зададете подразбиращата се часова зона.
+
+```php
+$this->configurator->setTimeZone('Europe/Prague');
+```
+
+
+Конфигурация на DI контейнера
+=============================
+
+Част от процеса на зареждане е създаването на DI контейнер или фабрика за обекти, което е сърцето на цялото приложение. Всъщност това е PHP клас, който Nette генерира и съхранява в директорията с кеша. Фабриката произвежда ключови обекти на приложението и с помощта на конфигурационни файлове я инструктираме как да ги създава и настройва, като по този начин влияем на поведението на цялото приложение.
+
+Конфигурационните файлове обикновено се записват във формат [NEON |neon:format]. В отделна глава ще научите [какво всичко може да се конфигурира |nette:configuring].
+
+.[tip]
+В режим за разработка контейнерът се актуализира автоматично при всяка промяна на кода или конфигурационните файлове. В продукционен режим той се генерира само веднъж и промените не се проверяват заради максимална производителност.
+
+Конфигурационните файлове зареждаме с помощта на `addConfig()`:
+
+```php
+$this->configurator->addConfig($this->rootDir . '/config/common.neon');
+```
+
+Ако искаме да добавим повече конфигурационни файлове, можем да извикаме функцията `addConfig()` няколко пъти.
+
+```php
+$configDir = $this->rootDir . '/config';
+$this->configurator->addConfig($configDir . '/common.neon');
+$this->configurator->addConfig($configDir . '/services.neon');
+if (PHP_SAPI === 'cli') {
+ $this->configurator->addConfig($configDir . '/cli.php');
+}
+```
+
+Името `cli.php` не е грешка, конфигурацията може да бъде записана и в PHP файл, който я връща като масив.
+
+Също така можем да добавим други конфигурационни файлове в [секцията `includes` |dependency-injection:configuration#Включване на файлове].
+
+Ако в конфигурационните файлове се появят елементи със същите ключове, те ще бъдат презаписани или в случай на [масиви слети |dependency-injection:configuration#Сливане]. По-късно включеният файл има по-висок приоритет от предходния. Файлът, в който е посочена секцията `includes`, има по-висок приоритет от включените в него файлове.
+
+
+Статични параметри
+------------------
+
+Параметрите, използвани в конфигурационните файлове, можем да дефинираме [в секцията `parameters` |dependency-injection:configuration#Параметри] и също така да ги предаваме (или презаписваме) с метода `addStaticParameters()` (има псевдоним `addParameters()`). Важно е, че различните стойности на параметрите ще доведат до генериране на допълнителни DI контейнери, т.е. допълнителни класове.
+
+```php
+$this->configurator->addStaticParameters([
+ 'projectId' => 23,
+]);
+```
+
+Към параметъра `projectId` може да се обърнем в конфигурацията с обичайния запис `%projectId%`.
+
+
+Динамични параметри
+-------------------
+
+В контейнера можем да добавим и динамични параметри, чиито различни стойности, за разлика от статичните параметри, не предизвикват генериране на нови DI контейнери.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'remoteIp' => $_SERVER['REMOTE_ADDR'],
+]);
+```
+
+Лесно можем да добавим напр. променливи на средата, към които след това можем да се обърнем в конфигурацията със записа `%env.variable%`.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'env' => getenv(),
+]);
+```
+
+
+Параметри по подразбиране
+-------------------------
+
+В конфигурационните файлове можете да използвате тези статични параметри:
+
+- `%appDir%` е абсолютният път до директорията с файла `Bootstrap.php`
+- `%wwwDir%` е абсолютният път до директорията с входния файл `index.php`
+- `%tempDir%` е абсолютният път до директорията за временни файлове
+- `%vendorDir%` е абсолютният път до директорията, където Composer инсталира библиотеките
+- `%rootDir%` е абсолютният път до коренната директория на проекта
+- `%debugMode%` указва дали приложението е в режим на дебъгване
+- `%consoleMode%` указва дали заявката е дошла през командния ред
+
+
+Импортирани сървиси
+-------------------
+
+Сега вече навлизаме по-дълбоко. Въпреки че смисълът на DI контейнера е да произвежда обекти, по изключение може да възникне нужда да се вмъкне съществуващ обект в контейнера. Правим това, като дефинираме сървиса с флаг `imported: true`.
+
+```neon
+services:
+ myservice:
+ type: App\Model\MyCustomService
+ imported: true
+```
+
+И в bootstrap вмъкваме обекта в контейнера:
+
+```php
+$this->configurator->addServices([
+ 'myservice' => new App\Model\MyCustomService('foobar'),
+]);
+```
+
+
+Различна среда
+==============
+
+Не се страхувайте да промените клас Bootstrap според вашите нужди. Към метода `bootWebApplication()` можете да добавите параметри за разграничаване на уеб проекти. Или можем да добавим други методи, например `bootTestEnvironment()`, който инициализира средата за единични тестове, `bootConsoleApplication()` за скриптове, извиквани от командния ред и т.н.
+
+```php
+public function bootTestEnvironment(): Nette\DI\Container
+{
+ Tester\Environment::setup(); // инициализация на Nette Tester
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+
+public function bootConsoleApplication(): Nette\DI\Container
+{
+ $this->configurator->setDebugMode(false);
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+```
diff --git a/application/bg/components.texy b/application/bg/components.texy
index 27b0129100..42049c0017 100644
--- a/application/bg/components.texy
+++ b/application/bg/components.texy
@@ -3,27 +3,27 @@
-Компонентите са отделни обекти за многократна употреба, които поставяме на страниците. Те могат да бъдат формуляри, решетки за данни, проучвания, изобщо всичко, което има смисъл да се използва многократно. След това научаваме:
+Компонентите са самостоятелни обекти за многократна употреба, които вмъкваме в страниците. Това могат да бъдат формуляри, datagrid-ове, анкети, всъщност всичко, което има смисъл да се използва многократно. Ще покажем:
-- как да използвате компонентите?
-- Как да ги напишем?
-- Какво представляват сигналите?
+- как да използваме компоненти?
+- как да ги пишем?
+- какво са сигналите?
-Nette има вградена система от компоненти. По-възрастните може да си спомнят нещо подобно от Delphi или ASP.NET Web Forms. React или Vue.js са изградени на базата на нещо отдалечено подобно. В света на PHP фреймуърците обаче това е напълно уникална функция.
+Nette има вградена компонентна система. Нещо подобно може да е познато на ветераните от Delphi или ASP.NET Web Forms, на нещо отдалечено подобно са базирани React или Vue.js. Въпреки това, в света на PHP фреймуърците това е уникално явление.
-В същото време компонентите променят из основи начина на разработване на приложения. Можете да съставяте страници от предварително подготвени блокове. Имате ли нужда от мрежа за данни в администрацията си? Можете да го намерите в [Componette |https://componette.org/search/component], хранилището за добавки с отворен код (не само компоненти) за Nette, и просто да го вмъкнете в презентатора.
+При това компонентите фундаментално влияят на подхода към създаването на приложения. Можете да сглобявате страници от предварително подготвени единици. Нуждаете се от datagrid в администрацията? Намерете го на [Componette |https://componette.org/search/component], хранилище на open-source добавки (т.е. не само компоненти) за Nette и просто го вмъкнете в презентера.
-Можете да включите произволен брой компоненти в презентатора. Можете да вмъкнете други компоненти в някои компоненти. Така се създава дърво на компонентите, в което водещият е коренът.
+В презентера можете да включите произволен брой компоненти. А в някои компоненти можете да вмъквате други компоненти. Така се създава компонентно дърво, чийто корен е презентерът.
-Фабрични методи .[#toc-factory-methods]
-=======================================
+Фабрични методи
+===============
-Как се поставят и впоследствие използват компонентите в презентатора? Обикновено се използват сглобяеми методи.
+Как се вмъкват компоненти в презентера и след това се използват? Обикновено с помощта на фабрични методи.
-Фабриката за компоненти е елегантен начин за създаване на компоненти само когато са необходими (лениво/при поискване). Магията се крие в изпълнението на метода `createComponentПроголосуйте, пожалуйста
+Гласувайте
{control poll} ``` -Холивудски стил .[#toc-hollywood-style] -======================================= +Hollywood style +=============== -Компонентите обикновено използват един страхотен трик, който наричаме холивудски стил. Вероятно знаете това клише, което актьорите често чуват по време на кастингите: "Не се обаждайте на нас, ние ще се обадим на вас". И това е най-важното. +Компонентите обикновено използват една свежа техника, която обичаме да наричаме Hollywood style. Със сигурност познавате крилатата фраза, която толкова често чуват участниците във филмови кастинги: „Не ни звънете, ние ще ви се обадим“. И точно за това става въпрос. -В Nette, вместо постоянно да задавате въпроси ("Подадена ли е формата?", "Валидна ли е?" или "Кликна ли някой върху този бутон?"), казвате на фреймуърка "Когато това се случи, извикайте този метод" и оставяте по-нататъшната работа върху него. Ако програмирате на JavaScript, този стил на програмиране ви е познат. Пишете функции, които се извикват при настъпване на определено събитие. И двигателят им предава съответните параметри. +В Nette, вместо постоянно да се налага да питате нещо („беше ли изпратен формулярът?“, „беше ли валиден?“ или „натисна ли потребителят този бутон?“), казвате на фреймуърка „когато това се случи, извикай този метод“ и оставяте по-нататъшната работа на него. Ако програмирате на JavaScript, този стил на програмиране ви е добре познат. Пишете функции, които се извикват, когато настъпи определено събитие. И езикът им предава съответните параметри. -Това изцяло променя начина на писане на приложения. Колкото повече задачи можете да делегирате на рамката, толкова по-малко работа ще трябва да свършите. И колкото по-малко можете да забравите. +Това напълно променя гледната точка към писането на приложения. Колкото повече задачи можете да оставите на фреймуърка, толкова по-малко работа имате вие. И толкова по-малко неща можете да пропуснете. -Как да напишем компонент .[#toc-how-to-write-a-component] -========================================================= +Пишем компонент +=============== -Под компонент обикновено разбираме потомък на класа [api:Nette\Application\UI\Control]. Самият презентатор [api:Nette\Application\UI\Presenter] също е потомък на класа `Control`. +Под понятието компонент обикновено разбираме наследник на клас [api:Nette\Application\UI\Control]. (По-точно би било да се използва терминът „controls“, но „контроли“ на български има съвсем различно значение и по-скоро се е наложило „компоненти“.) Самият презентер [api:Nette\Application\UI\Presenter] между другото също е наследник на клас `Control`. ```php .{file:PollControl.php} use Nette\Application\UI\Control; @@ -84,22 +84,22 @@ class PollControl extends Control ``` -Изобразяване на .[#toc-rendering] -================================= +Рендиране +========= -Вече знаем, че тагът `{control componentName}` се използва за визуализиране на компонент. Всъщност се извиква методът `render()` на компонента, в който ние се грижим за рендирането. Както и в презентатора, имаме шаблон [Latte |latte:] в променливата `$this->template`, на който подаваме параметри. За разлика от използването в презентатора, тук трябва да посочим файла на шаблона и да го оставим да се визуализира: +Вече знаем, че за рендиране на компонент се използва тагът `{control componentName}`. Той всъщност извиква метода `render()` на компонента, в който се грижим за рендирането. На разположение имаме, точно както в презентера, [Latte шаблон|templates] в променливата `$this->template`, на която предаваме параметри. За разлика от презентера, трябва да посочим файла с шаблона и да го накараме да се рендира: ```php .{file:PollControl.php} public function render(): void { - // въвеждаме някои параметри в шаблона + // вмъкваме в шаблона някакви параметри $this->template->param = $value; - //и го визуализирайте + // и го рендираме $this->template->render(__DIR__ . '/poll.latte'); } ``` -Тагът `{control}` ни позволява да предаваме параметри на метода `render()`: +Тагът `{control}` позволява да се предадат параметри на метода `render()`: ```latte {control poll $id, $message} @@ -112,7 +112,7 @@ public function render(int $id, string $message): void } ``` -Понякога един компонент може да се състои от няколко части, които искаме да визуализираме поотделно. За всяка от тях ще създадем различен метод за визуализация, например `renderPaginator()`: +Понякога компонентът може да се състои от няколко части, които искаме да рендираме отделно. За всяка от тях създаваме собствен метод за рендиране, тук в примера например `renderPaginator()`: ```php .{file:PollControl.php} public function renderPaginator(): void @@ -121,107 +121,107 @@ public function renderPaginator(): void } ``` -След това в шаблона го извикваме с: +А в шаблона след това го извикваме с помощта на: ```latte {control poll:paginator} ``` -Полезно е да знаете как даден таг се компилира в PHP код, за да го разберете по-добре. +За по-добро разбиране е добре да знаете как този таг се превежда на PHP. ```latte {control poll} {control poll:paginator 123, 'hello'} ``` -Това е събрано в: +се превежда като: ```php $control->getComponent('poll')->render(); $control->getComponent('poll')->renderPaginator(123, 'hello'); ``` -Методът `getComponent()` връща компонента `poll` и след това за него се извиква съответно методът `render()` или `renderPaginator()`. +Методът `getComponent()` връща компонента `poll` и върху този компонент извиква метода `render()`, респ. `renderPaginator()`, ако в тага след двоеточието е посочен друг начин на рендиране. .[caution] -Ако някъде в параметрите се използва **`=>`**, всички параметри ще бъдат обвити в масив и предадени като първи аргумент: +Внимание, ако някъде в параметрите се появи **`=>`**, всички параметри ще бъдат опаковани в масив и предадени като първи аргумент: ```latte -{control poll, id => 123, message => 'hello'} +{control poll, id: 123, message: 'hello'} ``` -съставен за: +се превежда като: ```php $control->getComponent('poll')->render(['id' => 123, 'message' => 'hello']); ``` -Изобразяване на вложен компонент: +Рендиране на подкомпонент: ```latte {control cartControl-someForm} ``` -съставени в: +се превежда като: ```php $control->getComponent("cartControl-someForm")->render(); ``` -Компонентите, както и презентаторите, автоматично предават няколко полезни променливи на шаблоните: +Компонентите, както и презентерите, предават на шаблоните няколко полезни променливи автоматично: -- `$basePath` - абсолютен URL път до главната директория (напр. `/CD-collection`). -- `$baseUrl` е абсолютният URL адрес на главната директория (напр, `http://localhost/CD-collection`) -- `$user` е обектът, който [представлява потребителя |security:authentication]. -- `$presenter` - настоящ водещ +- `$basePath` е абсолютният URL път до коренната директория (напр. `/eshop`) +- `$baseUrl` е абсолютният URL до коренната директория (напр. `http://localhost/eshop`) +- `$user` е обект [представляващ потребителя |security:authentication] +- `$presenter` е текущият презентер - `$control` е текущият компонент -- `$flashes` е списък на [съобщенията, |#flash-сообщений] изпратени по метода `flashMessage()`. +- `$flashes` масив от [съобщения |#Flash съобщения], изпратени с функцията `flashMessage()` -Сигнал .[#toc-signal] -===================== +Сигнал +====== -Вече знаем, че навигацията в приложението Nette се състои от връзки или пренасочвания към двойки `Presenter:action`. Но какво да правим, ако искаме да извършим действие само на **текущата страница**? Например, промяна на реда на сортиране на колоните в таблица; изтриване на елемент; превключване на светъл/тъмен режим; изпращане на формуляр; гласуване в анкета и т.н. +Вече знаем, че навигацията в Nette приложение се състои в свързване или пренасочване към двойки `Presenter:action`. Но какво, ако просто искаме да извършим действие на **текущата страница**? Например да променим сортирането на колони в таблица; да изтрием елемент; да превключим светъл/тъмен режим; да изпратим формуляр; да гласуваме в анкета; и т.н. -Този тип заявка се нарича сигнал. И как действията извикват методи `action
-Създаването на връзки в Nette е толкова лесно, колкото да посочите с пръст. Просто насочете курсора и системата ще свърши цялата работа вместо вас. Ние ви показваме:
+Създаването на връзки в Nette е лесно като посочване с пръст. Достатъчно е само да насочите и фреймуъркът вече ще свърши цялата работа вместо вас. Ще покажем:
-- Как да създавате връзки в шаблони и на други места
-- как да маркирате връзка в текущата страница
-- Какво да правим с невалидните връзки
+- как да създаваме връзки в шаблони и другаде
+- как да различим връзка към текущата страница
+- какво да правим с невалидни връзки
-Благодарение на [двупосочното маршрутизиране |routing] не се налага да кодирате URL адресите на приложенията в шаблони или код, който може да се промени по-късно или да бъде сложен за съставяне. Просто посочете презентатора и действието във връзката, подайте всички параметри и рамката сама ще генерира URL адреса. Всъщност това е много подобно на извикване на функция. Ще ви хареса.
+Благодарение на [двупосочното маршрутизиране |routing] никога няма да се налага да записвате твърдо URL адреси на вашето приложение в шаблони или код, които могат по-късно да се променят, или сложно да ги сглобявате. Във връзката е достатъчно да посочите презентера и действието, да предадете евентуални параметри и фреймуъркът вече ще генерира URL сам. Всъщност е много подобно на извикването на функция. Това ще ви хареса.
-В шаблона на водещия. .[#toc-in-the-presenter-template]
-=======================================================
+В шаблона на презентера
+=======================
-В повечето случаи създаваме връзки в шаблони, а атрибутът `n:href` е чудесен помощник:
+Най-често създаваме връзки в шаблони и страхотен помощник е атрибутът `n:href`:
```latte
-подробнее
+детайл
```
-Обърнете внимание, че вместо HTML атрибута `href` сме използвали [n:атрибута |latte:syntax#n:attributes] `n:href`. Стойността му не е URL адресът, както сте свикнали да виждате в атрибута `href`, а името на водещия и действието.
+Забележете, че вместо HTML атрибута `href` използвахме [n:атрибут |latte:syntax#n:атрибути] `n:href`. Неговата стойност тогава не е URL, както би било в случая с атрибута `href`, а името на презентера и действието.
-Щракването върху връзката, казано по-просто, е нещо като извикване на метода `ProductPresenter::renderShow()`. И ако в сигнатурата му има параметри, можем да го извикаме с аргументи:
+Кликването върху връзка е, опростено казано, нещо като извикване на метода `ProductPresenter::renderShow()`. И ако той има параметри в своята сигнатура, можем да го извикаме с аргументи:
```latte
-подробнее
+детайл на продукта
```
-Можем също така да предаваме именувани параметри. Следната връзка предава параметъра `lang` със стойност `en`:
+Възможно е да се предават и именувани параметри. Следващата връзка предава параметъра `lang` със стойност `cs`:
```latte
-подробнее
+детайл на продукта
```
-Ако методът `ProductPresenter::renderShow()` няма `$lang` в сигнатурата си, той може да прочете стойността на параметъра, като използва `$lang = $this->getParameter('lang')`.
+Ако методът `ProductPresenter::renderShow()` няма `$lang` в своята сигнатура, може да разбере стойността на параметъра с помощта на `$lang = $this->getParameter('lang')` или от [свойство |presenters#Параметри на заявката].
-Ако параметрите се съхраняват в масив, те могат да бъдат разширени с помощта на оператора `(expand)` (нещо като `...` в PHP, но работи с асоциативни масиви):
+Ако параметрите са съхранени в масив, могат да се разгърнат с оператора `...` (в Latte 2.x с оператора `(expand)`):
```latte
-{var $args = [$product->id, lang => en]}
-подробнее
+{var $args = [$product->id, lang => cs]}
+детайл на продукта
```
-Така наречените [постоянни параметри |presenters#Persistent-Parameters] също се предават автоматично в референции.
+Във връзките автоматично се предават и т.нар. [персистентни параметри |presenters#Персистентни параметри].
-Атрибутът `n:href` е много полезен за HTML тагове. ``. Ако искаме да покажем връзката на друго място, например в текста, използваме `{link}`:
+Атрибутът `n:href` е много удобен за HTML тагове ``. Ако искаме да изпишем връзка другаде, например в текст, използваме `{link}`:
```latte
-URL: {link Home:default}
+Адресът е: {link Home:default}
```
-В кода .[#toc-in-the-code]
-==========================
+В кода
+======
-Методът `link()` се използва за създаване на връзка в презентатора:
+За създаване на връзка в презентера служи методът `link()`:
```php
$url = $this->link('Product:show', $product->id);
```
-Параметрите могат да се предават и като масив, който може да съдържа именувани параметри:
+Параметрите могат да се предадат и с помощта на масив, където могат да се посочат и именувани параметри:
```php
$url = $this->link('Product:show', [$product->id, 'lang' => 'cs']);
```
-Връзки могат да се създават и без презентатор, като се използва [LinkGenerator |#LinkGenerator] и неговият метод `link()`.
+Връзки могат да се създават и без презентер, за това е тук [#LinkGenerator] и неговият метод `link()`.
-Препратки към водещия .[#toc-links-to-presenter]
-================================================
+Връзки към презентер
+====================
-Ако целта на връзката е да се свърже с представящия и действието, тя има следния синтаксис:
+Ако целта на връзката е презентер и действие, тя има следния синтаксис:
```
[//] [[[[:]module:]presenter:]action | this] [#fragment]
```
-Форматът се поддържа от всички тагове на Latte и всички методи на презентатора, които работят с връзки, т.е. `n:href`, `{link}`, `{plink}`, `link()`, `lazyLink()`, `isLinkCurrent()`, `redirect()`, `redirectPermanent()`, `forward()`, `canonicalize()`, както и [LinkGenerator |#LinkGenerator]. Следователно, дори ако в примерите се използва `n:href`, тук може да се използва всяка от функциите.
+Форматът се поддържа от всички тагове на Latte и всички методи на презентера, които работят с връзки, т.е. `n:href`, `{link}`, `{plink}`, `link()`, `lazyLink()`, `isLinkCurrent()`, `redirect()`, `redirectPermanent()`, `forward()`, `canonicalize()` и също [#LinkGenerator]. Така че, дори ако в примерите е използван `n:href`, там може да бъде която и да е от функциите.
-Следователно основната форма е `Presenter:action`:
+Основната форма е следователно `Presenter:action`:
```latte
-главная страница
+начална страница
```
-Ако се позоваваме на действието на текущия водещ, можем да пропуснем името му:
+Ако свързваме към действие на текущия презентер, можем да пропуснем неговото име:
```latte
-главная страница
+начална страница
```
-Ако действието е `default`, можем да го пропуснем, но двоеточието трябва да остане:
+Ако целта е действието `default`, можем да го пропуснем, но двоеточието трябва да остане:
```latte
-главная страница
+начална страница
```
-Връзките могат да сочат и към други [модули |modules]. Тук връзките се разграничават на относителни към подмодули или абсолютни. Принципът е подобен на дисковите пътища, само че с двоеточия вместо с наклонени черти. Да предположим, че водещият е част от модул `Front`, тогава записваме:
+Връзките могат също да сочат към други [модули |directory-structure#Презентери и шаблони]. Тук връзките се разграничават на относителни към вложен подмодул или абсолютни. Принципът е аналогичен на пътищата на диска, само че вместо наклонени черти има двоеточия. Да предположим, че текущият презентер е част от модула `Front`, тогава ще запишем:
```latte
-ссылка на Front:Shop:Product:show
-ссылка на Admin:Product:show
+връзка към Front:Shop:Product:show
+връзка към Admin:Product:show
```
-Специален случай е [самореференцията |#Link-to-Current-Page]. Тук ще напишем `this` като цел.
+Специален случай е връзка [към себе си |#Връзка към текущата страница], когато като цел посочим `this`.
```latte
-refresh
+обнови
```
-Можем да направим връзка към определена част от HTML страницата чрез така наречения фрагмент след символа хеш `#`:
+Можем да свързваме към определена част от страницата чрез т.нар. фрагмент след знака диез `#`:
```latte
-ссылка на Home:default и фрагмент #main
+връзка към Home:default и фрагмент #main
```
-Абсолютни пътища .[#toc-absolute-paths]
-=======================================
+Абсолютни пътища
+================
-Връзките, генерирани от `link()` или `n:href`, винаги са абсолютни пътища (т.е. започват с `/`), но не и абсолютни URL адреси с протокол и домейн, като `https://domain`.
+Връзките, генерирани с помощта на `link()` или `n:href`, са винаги абсолютни пътища (т.е. започват със знак `/`), но не и абсолютни URL с протокол и домейн като `https://domain`.
-За да създадете абсолютен URL адрес, добавете две наклонени черти в началото (например `n:href="//Home:"`). Или можете да превключите презентатора да генерира само абсолютни връзки, като зададете `$this->absoluteUrls = true`.
+За да генерирате абсолютен URL, добавете в началото две наклонени черти (напр. `n:href="//Home:"`). Или може да превключите презентера да генерира само абсолютни връзки, като зададете `$this->absoluteUrls = true`.
-Връзка към текущата страница .[#toc-link-to-current-page]
-=========================================================
+Връзка към текущата страница
+============================
-Целта `this` ще създаде връзка към текущата страница:
+Целта `this` създава връзка към текущата страница:
```latte
-обновить
+обнови
```
-Това ще предаде всички параметри, посочени в сигнатурата на метода. `render
+
+Как да проектираме ясна и мащабируема директорийна структура за проекти в Nette Framework? Ще покажем доказани практики, които ще ви помогнат с организацията на кода. Ще научите:
+
+- как **логически да разделим** приложението на директории
+- как да проектираме структурата така, че **добре да се мащабира** с растежа на проекта
+- какви са **възможните алтернативи** и техните предимства или недостатъци
+
+
+
+
+Важно е да се спомене, че самият Nette Framework не налага никаква конкретна структура. Той е проектиран така, че да може лесно да се адаптира към всякакви нужди и предпочитания.
+
+
+Основна структура на проекта
+============================
+
+Въпреки че Nette Framework не диктува никаква твърда директорийна структура, съществува доказано подразбиращо се подреждане под формата на [Web Project|https://github.com/nette/web-project]:
+
+/--pre
+web-project/
+├── app/ ← директория с приложението
+├── assets/ ← файлове SCSS, JS, изображения..., алтернативно resources/
+├── bin/ ← скриптове за командния ред
+├── config/ ← конфигурация
+├── log/ ← логвани грешки
+├── temp/ ← временни файлове, кеш
+├── tests/ ← тестове
+├── vendor/ ← библиотеки, инсталирани от Composer
+└── www/ ← публична директория (document-root)
+\--
+
+Тази структура можете свободно да променяте според вашите нужди - да преименувате или премествате папки. След това е достатъчно само да промените относителните пътища до директориите във файла `Bootstrap.php` и евентуално `composer.json`. Нищо повече не е необходимо, никаква сложна реконфигурация, никакви промени на константи. Nette разполага с умна автодетекция и автоматично разпознава местоположението на приложението, включително неговата URL основа.
+
+
+Принципи на организация на кода
+===============================
+
+Когато за първи път разглеждате нов проект, трябва бързо да се ориентирате в него. Представете си, че разгръщате директорията `app/Model/` и виждате тази структура:
+
+/--pre
+app/Model/
+├── Services/
+├── Repositories/
+└── Entities/
+\--
+
+От нея разбирате само, че проектът използва някакви сървиси, репозиторита и ентитита. За истинската цел на приложението не научавате абсолютно нищо.
+
+Да разгледаме друг подход - **организация по домейни**:
+
+/--pre
+app/Model/
+├── Cart/
+├── Payment/
+├── Order/
+└── Product/
+\--
+
+Тук е различно - на пръв поглед е ясно, че става въпрос за електронен магазин. Самите имена на директориите разкриват какво може приложението - работи с плащания, поръчки и продукти.
+
+Първият подход (организация по тип класове) носи на практика редица проблеми: код, който логически е свързан, е разпръснат в различни папки и трябва да прескачате между тях. Затова ще организираме по домейни.
+
+
+Именни пространства
+-------------------
+
+Прието е директорийната структура да съответства на именните пространства в приложението. Това означава, че физическото местоположение на файловете отговаря на техния namespace. Например клас, разположен в `app/Model/Product/ProductRepository.php`, трябва да има namespace `App\Model\Product`. Този принцип помага за ориентацията в кода и опростява autoloading-а.
+
+
+Единствено срещу множествено число в имената
+--------------------------------------------
+
+Забележете, че при основните директории на приложението използваме единствено число: `app`, `config`, `log`, `temp`, `www`. Също така и вътре в приложението: `Model`, `Core`, `Presentation`. Това е така, защото всяка от тях представлява една цялостна концепция.
+
+Подобно, например `app/Model/Product` представлява всичко около продуктите. Няма да го наречем `Products`, защото не става въпрос за папка, пълна с продукти (тогава там биха били файлове `nokia.php`, `samsung.php`). Това е namespace, съдържащ класове за работа с продукти - `ProductRepository.php`, `ProductService.php`.
+
+Папката `app/Tasks` е в множествено число, защото съдържа набор от самостоятелни изпълними скриптове - `CleanupTask.php`, `ImportTask.php`. Всеки от тях е самостоятелна единица.
+
+За консистентност препоръчваме да използвате:
+- Единствено число за namespace, представляващ функционална цялост (макар и работещ с множество ентитита)
+- Множествено число за колекции от самостоятелни единици
+- В случай на несигурност или ако не искате да мислите за това, изберете единствено число
+
+
+Публична директория `www/`
+==========================
+
+Тази директория е единствената достъпна от уеб (т.нар. document-root). Често можете да срещнете и името `public/` вместо `www/` - това е само въпрос на конвенция и няма влияние върху функционалността на приложението. Директорията съдържа:
+- [Входна точка |bootstrapping#index.php] на приложението `index.php`
+- Файл `.htaccess` с правила за mod_rewrite (при Apache)
+- Статични файлове (CSS, JavaScript, изображения)
+- Качени файлове
+
+За правилното осигуряване на сигурността на приложението е от съществено значение да имате правилно [конфигуриран document-root |nette:troubleshooting#Как да промените или премахнете директорията www от URL адреса].
+
+.[note]
+Никога не поставяйте в тази директория папката `node_modules/` - тя съдържа хиляди файлове, които могат да бъдат изпълними и не трябва да бъдат публично достъпни.
+
+
+Апликационна директория `app/`
+==============================
+
+Това е основната директория с кода на приложението. Основна структура:
+
+/--pre
+app/
+├── Core/ ← инфраструктурни въпроси
+├── Model/ ← бизнес логика
+├── Presentation/ ← презентери и шаблони
+├── Tasks/ ← командни скриптове
+└── Bootstrap.php ← зареждащ клас на приложението
+\--
+
+`Bootstrap.php` е [стартовият клас на приложението|bootstrapping], който инициализира средата, зарежда конфигурацията и създава DI контейнер.
+
+Нека сега разгледаме отделните поддиректории по-подробно.
+
+
+Презентери и шаблони
+====================
+
+Презентационната част на приложението имаме в директорията `app/Presentation`. Алтернатива е краткото `app/UI`. Това е мястото за всички презентери, техните шаблони и евентуални помощни класове.
+
+Този слой организираме по домейни. В сложен проект, който комбинира електронен магазин, блог и API, структурата би изглеждала така:
+
+/--pre
+app/Presentation/
+├── Shop/ ← електронен магазин frontend
+│ ├── Product/
+│ ├── Cart/
+│ └── Order/
+├── Blog/ ← блог
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← администрация
+│ ├── Dashboard/
+│ └── Products/
+└── Api/ ← API endpoints
+ └── V1/
+\--
+
+Напротив, при прост блог бихме използвали разделяне:
+
+/--pre
+app/Presentation/
+├── Front/ ← frontend на уебсайта
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← администрация
+│ ├── Dashboard/
+│ └── Posts/
+├── Error/
+└── Export/ ← RSS, sitemaps и т.н.
+\--
+
+Папки като `Home/` или `Dashboard/` съдържат презентери и шаблони. Папки като `Front/`, `Admin/` или `Api/` наричаме **модули**. Технически това са обикновени директории, които служат за логическо разделяне на приложението.
+
+Всяка папка с презентер съдържа едноименен презентер и неговите шаблони. Например папка `Dashboard/` съдържа:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← презентер
+└── default.latte ← шаблон
+\--
+
+Тази директорийна структура се отразява в именните пространства на класовете. Например `DashboardPresenter` се намира в именното пространство `App\Presentation\Admin\Dashboard` (виж [#Мапиране на презентери]):
+
+```php
+namespace App\Presentation\Admin\Dashboard;
+
+class DashboardPresenter extends Nette\Application\UI\Presenter
+{
+ // ...
+}
+```
+
+Към презентера `Dashboard` вътре в модула `Admin` се обръщаме в приложението с помощта на нотация с двоеточие като към `Admin:Dashboard`. Към неговото действие `default` след това като към `Admin:Dashboard:default`. В случай на вложени модули използваме повече двоеточия, например `Shop:Order:Detail:default`.
+
+
+Гъвкаво развитие на структурата
+-------------------------------
+
+Едно от големите предимства на тази структура е колко елегантно се адаптира към растящите нужди на проекта. Като пример да вземем частта, генерираща XML фийдове. В началото имаме проста форма:
+
+/--pre
+Export/
+├── ExportPresenter.php ← един презентер за всички експорти
+├── sitemap.latte ← шаблон за sitemap
+└── feed.latte ← шаблон за RSS feed
+\--
+
+С времето се добавят други типове фийдове и се нуждаем от повече логика за тях... Няма проблем! Папката `Export/` просто става модул:
+
+/--pre
+Export/
+├── Sitemap/
+│ ├── SitemapPresenter.php
+│ └── sitemap.latte
+└── Feed/
+ ├── FeedPresenter.php
+ ├── zbozi.latte ← фийд за Zboží.cz
+ └── heureka.latte ← фийд за Heureka.cz
+\--
+
+Тази трансформация е напълно плавна - достатъчно е да се създадат нови подпапки, да се раздели кодът в тях и да се актуализират връзките (напр. от `Export:feed` на `Export:Feed:zbozi`). Благодарение на това можем постепенно да разширяваме структурата според нуждите, нивото на влагане не е никак ограничено.
+
+Ако например в администрацията имате много презентери, свързани с управлението на поръчки, като `OrderDetail`, `OrderEdit`, `OrderDispatch` и т.н., можете за по-добра организираност на това място да създадете модул (папка) `Order`, в който ще бъдат (папки за) презентерите `Detail`, `Edit`, `Dispatch` и други.
+
+
+Местоположение на шаблоните
+---------------------------
+
+В предишните примери видяхме, че шаблоните са разположени директно в папката с презентера:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← презентер
+├── DashboardTemplate.php ← незадължителен клас за шаблона
+└── default.latte ← шаблон
+\--
+
+Това местоположение на практика се оказва най-удобно - всички свързани файлове са ви веднага под ръка.
+
+Алтернативно можете да поставите шаблоните в подпапка `templates/`. Nette поддържа и двата варианта. Дори можете да поставите шаблоните изцяло извън папката `Presentation/`. Всичко за възможностите за разполагане на шаблони ще намерите в главата [Търсене на шаблони |templates#Търсене на шаблони].
+
+
+Помощни класове и компоненти
+----------------------------
+
+Към презентерите и шаблоните често принадлежат и други помощни файлове. Разполагаме ги логично според тяхната област на действие:
+
+1. **Директно при презентера** в случай на специфични компоненти за дадения презентер:
+
+/--pre
+Product/
+├── ProductPresenter.php
+├── ProductGrid.php ← компонент за извеждане на продукти
+└── FilterForm.php ← формуляр за филтриране
+\--
+
+2. **За модула** - препоръчваме да използвате папка `Accessory`, която се поставя прегледно веднага в началото на азбуката:
+
+/--pre
+Front/
+├── Accessory/
+│ ├── NavbarControl.php ← компоненти за frontend
+│ └── TemplateFilters.php
+├── Product/
+└── Cart/
+\--
+
+3. **За цялото приложение** - в `Presentation/Accessory/`:
+/--pre
+app/Presentation/
+├── Accessory/
+│ ├── LatteExtension.php
+│ └── TemplateFilters.php
+├── Front/
+└── Admin/
+\--
+
+Или можете да поставите помощни класове като `LatteExtension.php` или `TemplateFilters.php` в инфраструктурната папка `app/Core/Latte/`. А компонентите в `app/Components`. Изборът зависи от навиците на екипа.
+
+
+Модел - сърцето на приложението
+===============================
+
+Моделът съдържа цялата бизнес логика на приложението. За неговата организация важи отново правилото - структурираме по домейни:
+
+/--pre
+app/Model/
+├── Payment/ ← всичко около плащанията
+│ ├── PaymentFacade.php ← основна входна точка
+│ ├── PaymentRepository.php
+│ ├── Payment.php ← ентитит
+├── Order/ ← всичко около поръчките
+│ ├── OrderFacade.php
+│ ├── OrderRepository.php
+│ ├── Order.php
+└── Shipping/ ← всичко около доставката
+\--
+
+В модела типично ще срещнете тези типове класове:
+
+**Фасади**: представляват основната входна точка към конкретен домейн в приложението. Действат като оркестратор, който координира сътрудничеството между различни сървиси с цел имплементиране на пълни use-cases (като "създай поръчка" или "обработи плащане"). Под своя оркестрационен слой фасадата скрива имплементационните детайли от останалата част на приложението, като по този начин предоставя чист интерфейс за работа с дадения домейн.
+
+```php
+class OrderFacade
+{
+ public function createOrder(Cart $cart): Order
+ {
+ // валидация
+ // създаване на поръчка
+ // изпращане на имейл
+ // записване в статистики
+ }
+}
+```
+
+**Сървиси**: фокусират се върху специфична бизнес операция в рамките на домейна. За разлика от фасадата, която оркестрира цели use-cases, сървисът имплементира конкретна бизнес логика (като изчисления на цени или обработка на плащания). Сървисите са типично безсъстоянийни и могат да бъдат използвани или от фасади като строителни блокове за по-сложни операции, или директно от други части на приложението за по-прости задачи.
+
+```php
+class PricingService
+{
+ public function calculateTotal(Order $order): Money
+ {
+ // изчисление на цена
+ }
+}
+```
+
+**Репозиторита**: осигуряват цялата комуникация с хранилището на данни, типично база данни. Неговата задача е зареждане и съхраняване на ентитита и имплементиране на методи за тяхното търсене. Репозиторият изолира останалата част от приложението от имплементационните детайли на базата данни и предоставя обектно-ориентиран интерфейс за работа с данни.
+
+```php
+class OrderRepository
+{
+ public function find(int $id): ?Order
+ {
+ }
+
+ public function findByCustomer(int $customerId): array
+ {
+ }
+}
+```
+
+**Ентитита**: обекти, представляващи основните бизнес концепции в приложението, които имат своя идентичност и се променят във времето. Типично става въпрос за класове, мапнати към таблици в базата данни с помощта на ORM (като Nette Database Explorer или Doctrine). Ентититата могат да съдържат бизнес правила, свързани с техните данни и валидационна логика.
+
+```php
+// Ентитит, мапнат към таблицата orders в базата данни
+class Order extends Nette\Database\Table\ActiveRow
+{
+ public function addItem(Product $product, int $quantity): void
+ {
+ $this->related('order_items')->insert([
+ 'product_id' => $product->id,
+ 'quantity' => $quantity,
+ 'unit_price' => $product->price,
+ ]);
+ }
+}
+```
+
+**Value обекти**: неизменни обекти, представляващи стойности без собствена идентичност - например парична сума или имейл адрес. Две инстанции на value обект със същите стойности се считат за идентични.
+
+
+Инфраструктурен код
+===================
+
+Папката `Core/` (или също `Infrastructure/`) е домът на техническата основа на приложението. Инфраструктурният код типично включва:
+
+/--pre
+app/Core/
+├── Router/ ← маршрутизация и управление на URL
+│ └── RouterFactory.php
+├── Security/ ← автентикация и авторизация
+│ ├── Authenticator.php
+│ └── Authorizator.php
+├── Logging/ ← логване и мониторинг
+│ ├── SentryLogger.php
+│ └── FileLogger.php
+├── Cache/ ← кеширащ слой
+│ └── FullPageCache.php
+└── Integration/ ← интеграция с външни сървиси
+ ├── Slack/
+ └── Stripe/
+\--
+
+При по-малки проекти, разбира се, е достатъчно плоско разделяне:
+
+/--pre
+Core/
+├── RouterFactory.php
+├── Authenticator.php
+└── QueueMailer.php
+\--
+
+Става въпрос за код, който:
+
+- Решава техническата инфраструктура (маршрутизация, логване, кеширане)
+- Интегрира външни сървиси (Sentry, Elasticsearch, Redis)
+- Предоставя основни сървиси за цялото приложение (поща, база данни)
+- Е предимно независим от конкретния домейн - кешът или логерът работи еднакво за електронен магазин или блог.
+
+Чудите се дали определен клас принадлежи тук, или към модела? Ключовата разлика е в това, че кодът в `Core/`:
+
+- Не знае нищо за домейна (продукти, поръчки, статии)
+- Е предимно възможно да се пренесе в друг проект
+- Решава "как работи" (как да се изпрати имейл), а не "какво прави" (какъв имейл да се изпрати)
+
+Пример за по-добро разбиране:
+
+- `App\Core\MailerFactory` - създава инстанции на клас за изпращане на имейли, решава SMTP настройките
+- `App\Model\OrderMailer` - използва `MailerFactory` за изпращане на имейли за поръчки, знае техните шаблони и кога трябва да се изпратят
+
+
+Командни скриптове
+==================
+
+Приложенията често трябва да извършват дейности извън обичайните HTTP заявки - било то обработка на данни във фонов режим, поддръжка или периодични задачи. За стартиране служат прости скриптове в директорията `bin/`, самата имплементационна логика след това поставяме в `app/Tasks/` (евентуално `app/Commands/`).
+
+Пример:
+
+/--pre
+app/Tasks/
+├── Maintenance/ ← скриптове за поддръжка
+│ ├── CleanupCommand.php ← изтриване на стари данни
+│ └── DbOptimizeCommand.php ← оптимизация на базата данни
+├── Integration/ ← интеграция с външни системи
+│ ├── ImportProducts.php ← импорт от доставчикова система
+│ └── SyncOrders.php ← синхронизация на поръчки
+└── Scheduled/ ← редовни задачи
+ ├── NewsletterCommand.php ← разпращане на бюлетини
+ └── ReminderCommand.php ← нотификации към клиенти
+\--
+
+Какво принадлежи към модела и какво към командните скриптове? Например логиката за изпращане на един имейл е част от модела, масовото разпращане на хиляди имейли вече принадлежи към `Tasks/`.
+
+Задачите обикновено [стартираме от командния ред |https://blog.nette.org/en/cli-scripts-in-nette-application] или чрез cron. Могат да се стартират и чрез HTTP заявка, но е необходимо да се мисли за сигурността. Презентерът, който стартира задачата, трябва да бъде защитен, например само за влезли потребители или със силен токен и достъп от разрешени IP адреси. При дълги задачи е необходимо да се увеличи времевият лимит на скрипта и да се използва `session_write_close()`, за да не се заключва сесията.
+
+
+Други възможни директории
+=========================
+
+Освен споменатите основни директории, можете според нуждите на проекта да добавите други специализирани папки. Да разгледаме най-често срещаните от тях и тяхното използване:
+
+/--pre
+app/
+├── Api/ ← логика за API, независима от презентационния слой
+├── Database/ ← миграционни скриптове и seeders за тестови данни
+├── Components/ ← споделени визуални компоненти в цялото приложение
+├── Event/ ← полезно, ако използвате event-driven архитектура
+├── Mail/ ← имейл шаблони и свързана логика
+└── Utils/ ← помощни класове
+\--
+
+За споделени визуални компоненти, използвани в презентерите в цялото приложение, може да се използва папка `app/Components` или `app/Controls`:
+
+/--pre
+app/Components/
+├── Form/ ← споделени формулярни компоненти
+│ ├── SignInForm.php
+│ └── UserForm.php
+├── Grid/ ← компоненти за извеждане на данни
+│ └── DataGrid.php
+└── Navigation/ ← навигационни елементи
+ ├── Breadcrumbs.php
+ └── Menu.php
+\--
+
+Тук принадлежат компоненти, които имат по-сложна логика. Ако искате да споделяте компоненти между няколко проекта, е препоръчително да ги изнесете в отделен composer пакет.
+
+В директорията `app/Mail` можете да поставите управлението на имейл комуникацията:
+
+/--pre
+app/Mail/
+├── templates/ ← имейл шаблони
+│ ├── order-confirmation.latte
+│ └── welcome.latte
+└── OrderMailer.php
+\--
+
+
+Мапиране на презентери
+======================
+
+Мапирането дефинира правила за извеждане на името на класа от името на презентера. Специфицираме ги в [конфигурацията|configuration] под ключа `application › mapping`.
+
+На тази страница показахме, че поставяме презентерите в папка `app/Presentation` (евентуално `app/UI`). Тази конвенция трябва да съобщим на Nette в конфигурационния файл. Достатъчен е един ред:
+
+```neon
+application:
+ mapping: App\Presentation\*\**Presenter
+```
+
+Как работи мапирането? За по-добро разбиране първо си представете приложение без модули. Искаме класовете на презентерите да попадат в именното пространство `App\Presentation`, така че презентерът `Home` да се мапира към класа `App\Presentation\HomePresenter`. Което постигаме с тази конфигурация:
+
+```neon
+application:
+ mapping: App\Presentation\*Presenter
+```
+
+Мапирането работи така, че името на презентера `Home` замества звездичката в маската `App\Presentation\*Presenter`, с което получаваме крайния име на класа `App\Presentation\HomePresenter`. Просто!
+
+Както обаче виждате в примерите в тази и други глави, класовете на презентерите поставяме в едноименни поддиректории, например презентерът `Home` се мапира към класа `App\Presentation\Home\HomePresenter`. Това постигаме с удвояване на двоеточието (изисква Nette Application 3.2):
+
+```neon
+application:
+ mapping: App\Presentation\**Presenter
+```
+
+Сега ще пристъпим към мапиране на презентери в модули. За всеки модул можем да дефинираме специфично мапиране:
+
+```neon
+application:
+ mapping:
+ Front: App\Presentation\Front\**Presenter
+ Admin: App\Presentation\Admin\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Според тази конфигурация презентерът `Front:Home` се мапира към класа `App\Presentation\Front\Home\HomePresenter`, докато презентерът `Api:OAuth` към класа `App\Api\OAuthPresenter`.
+
+Тъй като модулите `Front` и `Admin` имат подобен начин на мапиране и такива модули най-вероятно ще бъдат повече, е възможно да се създаде общо правило, което да ги замени. В маската на класа така ще се добави нова звездичка за модула:
+
+```neon
+application:
+ mapping:
+ *: App\Presentation\*\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Това работи и за по-дълбоко вложени директорийни структури, като например презентер `Admin:User:Edit`, сегментът със звездичка се повтаря за всяко ниво и резултатът е клас `App\Presentation\Admin\User\Edit\EditPresenter`.
+
+Алтернативен запис е вместо низ да се използва масив, състоящ се от три сегмента. Този запис е еквивалентен на предходния:
+
+```neon
+application:
+ mapping:
+ *: [App\Presentation, *, **Presenter]
+ Api: [App\Api, '', *Presenter]
+```
diff --git a/application/bg/how-it-works.texy b/application/bg/how-it-works.texy
index 6f267f3b26..2015bc5145 100644
--- a/application/bg/how-it-works.texy
+++ b/application/bg/how-it-works.texy
@@ -3,99 +3,101 @@
-В момента четете основния документ на Nette. Ще научите всички принципи на работа на уеб приложенията. Всички подробности от А до Я, от момента на раждането до последния дъх на PHP скрипта. След като я прочетете, ще разберете:
+Току-що прочетохте основния документ на документацията на Nette. Ще научите целия принцип на работа на уеб приложенията. От А до Я, от момента на създаването до последния дъх на PHP скрипта. След като прочетете, ще знаете:
-- Как работи всичко това.
-- какво представляват контейнерите Bootstrap, Presenter и DI
-- как изглежда структурата на директорията
+- как работи всичко
+- какво е Bootstrap, Presenter и DI контейнер
+- как изглежда директорийната структура
-Структура на директорията .[#toc-directory-structure]
-=====================================================
+Директорийна структура
+======================
-Отворете пример за скелет на уеб приложение, наречено [WebProject |https://github.com/nette/web-project], и можете да наблюдавате как се записват файловете.
+Отворете примера за скелет на уеб приложение, наречен [WebProject|https://github.com/nette/web-project], и докато четете, можете да разглеждате файловете, за които става въпрос.
-Структурата на директорията изглежда по следния начин:
+Директорийната структура изглежда приблизително така:
/--pre
web-project/
-├── app/ ← каталог с приложением
-│ ├── Presenters/ ← классы презентеров
-│ │ ├── HomePresenter.php ← Класс презентера главной страницы
-│ │ └── templates/ ← директория шаблонов
-│ │ ├── @layout.latte ← шаблон общего макета
-│ │ └── Home/ ← шаблоны презентера главной страницы
-│ │ └── default.latte ← шаблон действия `default`
-│ ├── Router/ ← конфигурация URL-адресов
-│ └── Bootstrap.php ← загрузочный класс Bootstrap
-├── bin/ ← скрипты командной строки
-├── config/ ← файлы конфигурации
+├── app/ ← директория с приложението
+│ ├── Core/ ← основни класове, необходими за работа
+│ │ └── RouterFactory.php ← конфигурация на URL адреси
+│ ├── Presentation/ ← презентери, шаблони и др.
+│ │ ├── @layout.latte ← шаблон на лейаута
+│ │ └── Home/ ← директория на презентера Home
+│ │ ├── HomePresenter.php ← клас на презентера Home
+│ │ └── default.latte ← шаблон на действието default
+│ └── Bootstrap.php ← зареждащ клас Bootstrap
+├── assets/ ← ресурси (SCSS, TypeScript, изходни изображения)
+├── bin/ ← скриптове, стартирани от командния ред
+├── config/ ← конфигурационни файлове
│ ├── common.neon
-│ └── local.neon
-├── log/ ← журналы ошибок
-├── temp/ ← временные файлы, кэш, …
-├── vendor/ ← библиотеки, установленные через Composer
+│ └── services.neon
+├── log/ ← логвани грешки
+├── temp/ ← временни файлове, кеш, …
+├── vendor/ ← библиотеки, инсталирани от Composer
│ ├── ...
-│ └── autoload.php ← автозагрузчик библиотек, установленных через Composer
-├── www/ ← публичный корневой каталог проекта
-│ ├── .htaccess ← правила mod_rewrite и т. д.
-│ └── index.php ← начальный файл, запускающий приложение
-└── .htaccess ← запрещает доступ ко всем каталогам, кроме www
+│ └── autoload.php ← autoloading на всички инсталирани пакети
+├── www/ ← публична директория или document-root на проекта
+│ ├── assets/ ← компилирани статични файлове (CSS, JS, изображения, ...)
+│ ├── .htaccess ← правила mod_rewrite
+│ └── index.php ← първоначален файл, с който се стартира приложението
+└── .htaccess ← забранява достъпа до всички директории освен www
\--
-Можете да променяте структурата на директориите по всякакъв начин, да преименувате или премествате папки и след това просто да редактирате пътищата до `log/` и `temp/` във файла `Bootstrap.php` и пътя до този файл в `composer.json` в раздела `autoload`. Нищо друго, никакво сложно преконфигуриране, никакви постоянни промени. Nette има [интелигентно автоматично откриване |bootstrap#development-vs-production-mode].
+Директорийната структура можете да променяте както искате, да преименувате или премествате папки, тя е напълно гъвкава. Nette освен това разполага с умна автодетекция и автоматично разпознава местоположението на приложението, включително неговата URL основа.
-За малко по-големи приложения можем да разделим главната папка и папките с шаблони на подпапки (на диска) и пространства от имена (в кода), които наричаме [модули |modules].
+При малко по-големи приложения можем [да разделим папките с презентери и шаблони на поддиректории |directory-structure#Презентери и шаблони] и класовете на именни пространства, които наричаме модули.
-Публичната директория `www/` може да бъде променена, без да се налага да инсталирате нещо друго. Всъщност често се случва, че поради спецификата на вашия хостинг ще трябва да я преименувате или да инсталирате т.нар. document-root към тази директория в конфигурацията на хостинга. Ако хостингът ви не позволява да създавате папки на едно ниво над публичната директория, предлагаме ви да потърсите друга хостинг услуга. В противен случай ще се изложите на значителен риск за сигурността.
+Директорията `www/` представлява т.нар. публична директория или document-root на проекта. Можете да я преименувате без нужда от каквото и да било друго настройване от страна на приложението. Само е необходимо [да конфигурирате хостинга |nette:troubleshooting#Как да промените или премахнете директорията www от URL адреса] така, че document-root да сочи към тази директория.
-Можете също така да качвате WebProject директно, включително Nette, с помощта на [Composer |best-practices:composer]:
+WebProject можете също така директно да изтеглите, включително Nette, с помощта на [Composer |best-practices:composer]:
```shell
composer create-project nette/web-project
```
-В Linux или macOS задайте [разрешения за запис |nette:troubleshooting#Setting-Directory-Permissions] за директориите `log/` и `temp/`.
+На Linux или macOS задайте на директориите `log/` и `temp/` [права за запис |nette:troubleshooting#Настройка на правата на директориите].
-Приложението WebProject е готово за работа, не е необходимо да конфигурирате нищо друго и можете да го видите директно в браузъра си, като отворите папката `www/`.
+Приложението WebProject е готово за стартиране, не е необходимо изобщо нищо да се конфигурира и можете директно да го покажете в браузъра, като достъпите папката `www/`.
-HTTP заявка .[#toc-http-request]
-================================
+HTTP заявка
+===========
-Всичко започва с това, че потребителят отваря страница в браузъра и браузърът подава HTTP заявка към сървъра. Заявката се изпраща към PHP файл, разположен в публичната директория `www/`, който се нарича `index.php`. Нека предположим, че това е заявка към `https://example.com/product/123` и ще бъде изпълнен.
+Всичко започва в момента, когато потребителят отвори страница в браузъра. Тоест, когато браузърът почука на сървъра с HTTP заявка. Заявката сочи към единствен PHP файл, който се намира в публичната директория `www/`, и това е `index.php`. Да кажем, че става въпрос за заявка към адреса `https://example.com/product/123`. Благодарение на подходящо [настройване на сървъра |nette:troubleshooting#Как да настроите сървъра за красиви URL адреси], и този URL се мапва към файла `index.php` и той се изпълнява.
-Задачата му е следната:
+Неговата задача е:
-1) инициализиране на средата
-2) получаване на фабрика
-3) стартиране на приложението Nette, което обработва заявката
+1) да инициализира средата
+2) да получи фабриката
+3) да стартира Nette приложението, което ще обработи заявката
-Какъв вид фабрика? Ние не произвеждаме трактори, а уебсайтове! Изчакайте, след малко ще бъде обяснено.
+Каква фабрика? Не произвеждаме трактори, а уеб страници! Изчакайте, веднага ще се изясни.
-Под "инициализиране на средата" разбираме например активирането на услугата [Tracy |tracy:], която е невероятен инструмент за регистриране или визуализиране на грешки. Той регистрира грешките на производствения сървър и ги показва директно на сървъра за разработка. Затова по време на инициализацията трябва да решите дали сайтът ще работи в производствен режим или в режим за разработчици. Nette използва автоматично откриване за това: ако стартирате сайта на localhost, той се стартира в режим за разработчици. Не е необходимо да конфигурирате каквото и да било и приложението е готово както за разработка, така и за внедряване в производството. Тези стъпки се следват и са описани подробно в главата [Bootstrap |bootstrap].
+С думите „инициализация на средата“ имаме предвид например това, че се активира [Tracy|tracy:], което е страхотен инструмент за логване или визуализация на грешки. На продукционен сървър той логва грешки, на сървър за разработка ги показва директно. Следователно към инициализацията принадлежи и решението дали уебсайтът работи в продукционна или развойна среда. За това Nette използва [умна автодетекция |bootstrapping#Режим за разработка срещу продукционен режим]: ако стартирате уебсайта на localhost, той работи в развойна среда. Не е необходимо нищо да конфигурирате и приложението е веднага готово както за разработка, така и за реално внедряване. Тези стъпки се извършват и са подробно описани в главата за [клас Bootstrap|bootstrapping].
-Третата точка (да, пропуснахме втората, но ще се върнем към нея) е да стартирате приложението. Класът `Nette\Application\Application` (наричан по-нататък `Application`) обработва HTTP заявките в Nette, така че когато казваме "стартиране на приложение", имаме предвид извикване на метод с име `run()` върху обект от този клас.
+Третата точка (да, прескочихме втората, но ще се върнем към нея) е стартирането на приложението. Обработката на HTTP заявки в Nette се извършва от класа `Nette\Application\Application` (наричан по-нататък `Application`), така че когато казваме стартиране на приложението, имаме предвид конкретно извикване на метода със знаковото име `run()` върху обекта на този клас.
-Nette е наставник, който ви напътства да пишете чисти приложения според доказани методологии. Най-проверяваният от тях се нарича **имплементиране на зависимости**, накратко DI. На този етап не искаме да ви натоварваме с обяснение на DI, тъй като това е разгледано в [отделна глава |dependency-injection:introduction], важното тук е, че ключовите обекти обикновено се създават от фабрика за обекти, наречена **DI контейнер** (съкратено DIC). Да, това е същата фабрика, която беше спомената преди време. Освен това той създава обекта `Application` за нас, така че първо се нуждаем от контейнер. Получаваме го с класа `Configurator` и му позволяваме да създаде обекта `Application`, да извика метода `run()` и това стартира приложението Nette. Точно това се случва във файла [index.php |bootstrap#index-php].
+Nette е ментор, който ви води към писането на чисти приложения според доказани методики. И една от тези абсолютно най-доказани се нарича **dependency injection**, съкратено DI. В този момент не искаме да ви натоварваме с обяснение на DI, за това има [отделна глава|dependency-injection:introduction], същественото последствие е, че ключовите обекти обикновено ще ни ги създава фабрика за обекти, която се нарича **DI контейнер** (съкратено DIC). Да, това е фабриката, за която стана дума преди малко. И тя ще ни произведе и обекта `Application`, затова първо се нуждаем от контейнера. Получаваме го с помощта на класа `Configurator` и го караме да произведе обекта `Application`, извикваме върху него метода `run()` и така се стартира Nette приложението. Точно това се случва във файла [index.php |bootstrapping#index.php].
-Приложението Nette .[#toc-nette-application]
-============================================
+Nette Application
+=================
-Класът Application има една единствена задача: да отговори на HTTP заявка.
+Класът Application има една-единствена задача: да отговори на HTTP заявка.
-Приложенията, написани на Nette, са разделени на много така наречени презентатори (в други фреймуъркове може да срещнете термина *контролер*, което е същото нещо), които представляват класове, представящи определена страница на уебсайт: например начална страница; продукт в електронен магазин; регистрационна форма; rss-карта и т.н. В едно приложение може да има между един и хиляда презентатори.
+Приложенията, написани на Nette, се разделят на много т.нар. презентери (в други фреймуърци може да срещнете термина controller, става въпрос за същото), които са класове, всеки от които представлява някаква конкретна страница на уебсайта: напр. начална страница; продукт в електронен магазин; формуляр за вход; sitemap feed и т.н. Приложението може да има от един до хиляди презентери.
-Приложението започва с искане към т.нар. маршрутизатор да реши на кой от презентаторите да изпрати текущата заявка за обработка. Маршрутизаторът решава чия е отговорността. Той разглежда входния URL адрес `https://example.com/product/123`, който иска продукт `показать` с `id: 123` като действие. Добър навик е да записвате двойките водещ + действие, разделени с двоеточие: `Продукт:показать`.
+Application започва с това, че моли т.нар. рутер да реши на кой от презентерите да предаде текущата заявка за обработка. Рутерът решава чия е отговорността. Поглежда входния URL `https://example.com/product/123` и въз основа на това как е настроен, решава, че това е работа напр. за **презентера** `Product`, от който ще иска като **действие** показване (`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 да създаде презентатора, тъй като създаването на обекти е негова работа.
+Да продължим нататък. Application вече знае името на презентера и може да продължи напред. Като произведе обект от класа `ProductPresenter`, което е кодът на презентера `Product`. По-точно казано, моли DI контейнера да произведе презентера, защото производството е негова работа.
-Водещият може да изглежда по следния начин:
+Презентерът може да изглежда например така:
```php
class ProductPresenter extends Nette\Application\UI\Presenter
@@ -113,92 +115,86 @@ class ProductPresenter extends Nette\Application\UI\Presenter
}
```
-Заявката се обработва от водещия. И задачата е ясна: да се изпълни действието `show` с `id: 123`. На езика preenter това означава да се извика методът `renderShow()` с параметър `$id`, равен на `123`.
+Обработката на заявката се поема от презентера. И задачата е ясна: извърши действието `show` с `id: 123`. Което на езика на презентерите означава, че се извиква методът `renderShow()` и в параметъра `$id` получава `123`.
-Презентаторът може да извършва няколко действия, т.е. да има няколко метода `render
-Научете как да създавате презентатори и шаблони в Nette. След като прочетете тази статия, ще знаете.
+Ще се запознаем с това как се пишат презентери и шаблони в Nette. След като прочетете, ще знаете:
-- Как работи водещият
-- какво представляват фиксираните параметри
-- Как да визуализирате шаблон
+- как работи презентерът
+- какво са персистентните параметри
+- как се рендират шаблони
-[Вече знаем, |how-it-works#Nette-Application] че презентаторът е клас, който представлява определена страница на уеб приложение, например началната страница, страницата на продукта в онлайн магазин, формата за вход, картата на сайта и т.н. Едно приложение може да има от един до хиляди презентатори. В други рамки те са известни и като контролери.
+[Вече знаем |how-it-works#Nette Application], че презентерът е клас, който представлява някаква конкретна страница на уеб приложение, напр. начална страница; продукт в електронен магазин; формуляр за вход; sitemap feed и т.н. Приложението може да има от един до хиляди презентери. В други фреймуърци те се наричат и контролери.
-Обикновено терминът *presenter* се отнася до наследника на класа [api:Nette\Application\UI\Presenter], който е подходящ за уеб интерфейси. Ще обсъдим този клас в останалата част на тази глава. В общ смисъл презентатор е всеки обект, който реализира интерфейса [api:Nette\Application\IPresenter].
+Обикновено под понятието презентер се разбира наследник на клас [api:Nette\Application\UI\Presenter], който е подходящ за генериране на уеб интерфейси и на който ще се посветим в останалата част от тази глава. В общ смисъл презентерът е всеки обект, имплементиращ интерфейса [api:Nette\Application\IPresenter].
-Жизнен цикъл на водещия .[#toc-life-cycle-of-presenter]
-=======================================================
+Жизнен цикъл на презентера
+==========================
-Задачата на водещия е да обработи заявката и да върне отговор (това може да бъде HTML страница, изображение, пренасочване и т.н.).
+Задачата на презентера е да обработи заявка и да върне отговор (който може да бъде HTML страница, изображение, пренасочване и т.н.).
-Така че в началото има молба. Това не е самата HTTP заявка, а обектът [api:Nette\Application\Request], в който HTTP заявката е преобразувана от маршрутизатора. Обикновено не се сблъскваме с този обект, тъй като водещият умело делегира обработката на заявката на специални методи, които ще видим след малко.
+Следователно в началото му се предава заявка. Това не е директно HTTP заявка, а обект [api:Nette\Application\Request], в който HTTP заявката е била трансформирана с помощта на рутера. С този обект обикновено не влизаме в контакт, тъй като презентерът умно делегира обработката на заявката на други методи, които сега ще покажем.
-[* lifecycle.svg *] *** *Предварително въвеждане на жизнения цикъл* .<>
+[* lifecycle.svg *] *** *Жизнен цикъл на презентера* .<>
-На фигурата е показан списък с методи, които се извикват последователно отгоре надолу, ако съществуват. Всички те не са задължителни, можем да имаме напълно празен презентатор без нито един метод и да изградим прост статичен уеб върху него.
+Изображението представлява списък с методи, които се извикват последователно отгоре надолу, ако съществуват. Никой от тях не е задължителен, можем да имаме напълно празен презентер без нито един метод и да изградим върху него прост статичен уебсайт.
`__construct()`
---------------
-Конструкторът не е от значение за жизнения цикъл на презентатора, тъй като се извиква в момента на създаване на обекта. Но го споменаваме поради важността му, тъй като се използва за предаване на зависимости.
+Конструкторът не принадлежи съвсем към жизнения цикъл на презентера, защото се извиква в момента на създаване на обекта. Но го споменаваме поради важността му. Конструкторът (заедно с [метода inject|best-practices:inject-method-attribute]) служи за предаване на зависимости.
-На водещия не се налага да се грижи за бизнес логиката на приложението, да записва и чете от базата данни, да извършва изчисления и т.н. Това е задача за класовете от слоя, който наричаме модел. Например класът `ArticleRepository` може да отговаря за зареждането и запазването на статии. За да може презентаторът да я използва, тя [се предава чрез имплементация на зависимост |dependency-injection:passing-dependencies]:
+Презентерът не трябва да се занимава с бизнес логиката на приложението, да записва и чете от база данни, да извършва изчисления и т.н. За това са класовете от слоя, който наричаме модел. Например класът `ArticleRepository` може да отговаря за зареждането и съхраняването на статии. За да може презентерът да работи с него, той си го [изисква чрез dependency injection |dependency-injection:passing-dependencies]:
```php
@@ -50,44 +50,44 @@ class ArticlePresenter extends Nette\Application\UI\Presenter
`startup()`
-----------
-Веднага след получаване на заявка се извиква методът `startup()`. Можете да го използвате за инициализиране на свойства, проверка на привилегиите на потребителите и т.н. Необходимо е винаги да се извиква предшественикът `parent::startup()`.
+Веднага след получаване на заявката се извиква методът `startup()`. Можете да го използвате за инициализация на свойства, проверка на потребителски права и т.н. Изисква се методът винаги да извиква родителя `parent::startup()`.
`actionHello
'; @@ -425,10 +446,55 @@ $this->sendResponse(new Responses\CallbackResponse($callback)); ``` -Допълнително четене .[#toc-further-reading] -=========================================== +Ограничаване на достъпа с `#[Requires]` .{data-version:3.2.2} +------------------------------------------------------------- + +Атрибутът `#[Requires]` предоставя разширени възможности за ограничаване на достъпа до презентери и техните методи. Може да се използва за специфициране на HTTP методи, изискване на AJAX заявка, ограничаване до същия произход (same origin) и достъп само чрез пренасочване (forward). Атрибутът може да се прилага както към класове на презентери, така и към отделни методи `action
-Маршрутизаторът ще се погрижи за всичко, свързано с URL адресите, така че повече няма да ви се налага да мислите за тях. Нека ви покажем:
+Рутерът отговаря за всичко около URL адресите, за да не се налага вие да мислите за тях. Ще покажем:
-- как да настроите маршрутизатора така, че URL адресите да са такива, каквито искате да бъдат
-- Как да настроите SEO и пренасочвания.
-- как да напишете собствен маршрутизатор
+- как да настроим рутера, така че URL адресите да са според представите ни
+- ще поговорим за SEO и пренасочване
+- и ще покажем как да напишем собствен рутер
-По-човешките URL адреси (или готините или красивите URL адреси) са по-използваеми, по-добре запомнящи се и имат положително въздействие върху SEO. Nette взема това предвид и напълно удовлетворява желанията на разработчиците. Можете да проектирате структурата на URL адресите на приложението си точно по желания от вас начин.
-Можете да го проектирате дори след като приложението е готово, тъй като това може да стане без промени в кода или шаблона. Тя е дефинирана елегантно на едно [място |#Integration], в маршрутизатора, а не е разпръсната под формата на анотации навсякъде из презентаторите.
+По-човешките URL адреси (или също cool или pretty URL) са по-използваеми, по-лесно запомнящи се и допринасят положително за SEO. Nette мисли за това и излиза напълно в помощ на разработчиците. Можете да проектирате за своето приложение точно такава структура на URL адресите, каквато искате. Можете да я проектирате дори когато приложението вече е готово, защото това става без намеса в кода или шаблоните. Дефинира се по елегантен начин на едно [единствено място |#Включване в приложението], в рутера, и не е разпръснато под формата на анотации във всички презентери.
-Маршрутизаторът в Nette е специален, защото е **двупосочен** - той може да декодира URL адресите на HTTP заявките и да създава връзки. Ето защо той играе важна роля в [приложението Nette |how-it-works#Nette-Application], тъй като той решава кой главен потребител и действие ще изпълни текущата заявка, а също така се използва за [генериране на URL адреси |creating-links] в шаблона и т.н.
+Рутерът в Nette е изключителен с това, че е **двупосочен.** Той може както да декодира URL в HTTP заявка, така и да създава връзки. Следователно играе ключова роля в [Nette Application |how-it-works#Nette Application], защото от една страна решава кой презентер и действие ще изпълняват текущата заявка, но също така се използва за [генериране на URL |creating-links] в шаблон и т.н.
-Маршрутизаторът обаче не се ограничава само до това приложение, можете да го използвате в приложения, в които презентаторите изобщо не се използват, за REST API и т.н. За повече подробности вижте раздела за [разделно използване |#separated-usage].
+Въпреки това, рутерът не е ограничен само до тази употреба, можете да го използвате в приложения, където изобщо не се използват презентери, за REST API и т.н. Повече в частта [#Самостоятелно използване].
-Събиране на маршрути .[#toc-route-collection]
-=============================================
+Колекция от маршрути
+====================
-Най-красивият начин за дефиниране на URL адреси в приложението е класът [api:Nette\Application\Routers\RouteList]. Дефиницията се състои от списък с така наречените маршрути, т.е. URL маски и свързани с тях преемници и действия, използващи прост API. Не е необходимо да назоваваме маршрутите.
+Най-приятният начин за дефиниране на формата на URL адресите в приложението предлага класът [api:Nette\Application\Routers\RouteList]. Дефиницията се състои от списък с т.нар. маршрути, т.е. маски на URL адреси и към тях асоциирани презентери и действия с помощта на просто API. Не е необходимо да именуваме маршрутите по никакъв начин.
```php
$router = new Nette\Application\Routers\RouteList;
@@ -32,180 +31,180 @@ $router->addRoute('article/Главная страница
+Homepage
... {/block} ``` -Той дефинира блок `content`, който се вмъква вместо `{include content}` в оформлението, и замества блока `title`, който презаписва `{block title}` в оформлението. Опитайте се да си представите резултата. +Той дефинира блок `content`, който се вмъква на мястото на `{include content}` в лейаута, и също така ре-дефинира блок `title`, с който презаписва `{block title}` в лейаута. Опитайте да си представите резултата. -Търсене на шаблони .[#toc-search-for-templates] ------------------------------------------------ +Търсене на шаблони +------------------ -Пътят към шаблоните се определя от главния модул с помощта на проста логика. Той ще се опита да провери дали има някой от тези файлове, разположен спрямо главната директория на класа, където `
-Moderní webové aplikace dnes běží napůl na serveru, napůl v prohlížeči. AJAX je tím klíčovým spojovacím prvkem. Jakou podporu nabízí Nette Framework?
-- posílání výřezů šablony (tzv. snippety)
+V éře moderních webových aplikací, kde se často rozkládá funkcionalita mezi serverem a prohlížečem, je AJAX nezbytným spojovacím prvkem. Jaké možnosti nám v této oblasti nabízí Nette Framework?
+- odesílání částí šablony, tzv. snippetů
- předávání proměnných mezi PHP a JavaScriptem
-- debugování AJAXových aplikací
+- nástroje pro debugování AJAXových požadavků
-AJAXový požadavek lze detekovat metodou služby [zapouzdřující HTTP požadavek |http:request] `$httpRequest->isAjax()` (detekuje podle HTTP hlavičky `X-Requested-With`). Uvnitř presenteru je k dispozici "zkratka" v podobě metody `$this->isAjax()`.
-AJAXový požadavek se nijak neliší od klasického požadavku - je zavolán presenter s určitým view a parametry. Je také věcí presenteru, jak bude na něj reagovat: může použít vlastní rutinu, která vrátí nějaký fragment HTML kódu (HTML snippet), XML dokument, JSON objekt nebo kód v JavaScriptu.
+AJAXový požadavek
+=================
-Pro odesílání dat prohlížeči ve formátu JSON lze využít předpřipravený objekt `payload`:
+AJAXový požadavek se v zásadě neliší od klasického HTTP požadavku. Zavolá se presenter s určitými parametry. A je na presenteru, jakým způsobem bude na požadavek reagovat - může vrátit data ve formátu JSON, odeslat část HTML kódu, XML dokument, atd.
-```php
-public function actionDelete(int $id): void
-{
- if ($this->isAjax()) {
- $this->payload->message = 'Success';
- }
- // ...
-}
+Na straně prohlížeče inicializujeme AJAXový požadavek pomocí funkce `fetch()`:
+
+```js
+fetch(url, {
+ headers: {'X-Requested-With': 'XMLHttpRequest'},
+})
+.then(response => response.json())
+.then(payload => {
+ // zpracování odpovědi
+});
```
-Pokud potřebujete plnou kontrolu nad odeslaným JSONem, použijte metodu `sendJson` v presenteru. Tím ihned ukončíte činnost presenteru a obejdete se i bez šablony:
+Na straně serveru rozpoznáme AJAXový požadavek metodou `$httpRequest->isAjax()` služby [zapouzdřující HTTP požadavek |http:request]. K detekci používá HTTP hlavičku `X-Requested-With`, proto je důležité ji odesílat. V rámci presenteru lze použít metodu `$this->isAjax()`.
+
+Chcete-li odeslat data ve formátu JSON, použijte metodu [`sendJson()` |presenters#Odeslání odpovědi]. Metoda rovněž ukončí činnost presenteru.
```php
-$this->sendJson(['key' => 'value', /* ... */]);
+public function actionExport(): void
+{
+ $this->sendJson($this->model->getData);
+}
```
-Když chceme odeslat HTML, můžeme jednak zvolit speciální šablonu pro AJAX:
+Máte-li v plánu odpovědět pomocí speciální šablony určené pro AJAX, můžete to udělat následovně:
```php
public function handleClick($param): void
@@ -45,10 +52,20 @@ public function handleClick($param): void
```
+Snippety
+========
+
+Nejsilnější prostředek, který nabízí Nette pro propojení serveru s klientem, představují snippety. Díky nim můžete z obyčejné aplikace udělat AJAXovou jen s minimálním úsilím a několika řádky kódu. Jak to celé funguje demonstruje příklad Fifteen, jehož kód najdete na [GitHubu |https://github.com/nette-examples/fifteen].
+
+Snippety, nebo-li výstřižky, umožnují aktualizovat jen části stránky, místo toho, aby se celá stránka znovunačítala. Jednak je to rychlejší a efektivnější, ale poskytuje to také komfortnější uživatelský zážitek. Snippety vám mohou připomínat Hotwire pro Ruby on Rails nebo Symfony UX Turbo. Zajímavé je, že Nette představilo snippety již o 14 let dříve.
+
+Jak snippety fungují? Při prvním načtení stránky (ne-AJAXovém požadavku) se načte celá stránka včetně všech snippetů. Když uživatel interaguje se stránkou (např. klikne na tlačítko, odešle formulář, atd.), místo načtení celé stránky se vyvolá AJAXový požadavek. Kód v presenteru provede akci a rozhodne, které snippety je třeba aktualizovat. Nette tyto snippety vykreslí a odešle ve formě pole ve formátu JSON. Obslužný kód v prohlížeči získané snippety vloží zpět do stránky. Přenáší se tedy jen kód změněných snippetů, což šetří šířku pásma a zrychluje načítání oproti přenášení obsahu celé stránky.
+
+
Naja
-====
+----
-K obsluze AJAXových požadavků na straně prohlížeče slouží [knihovna Naja |https://naja.js.org]. Tu [nainstalujte |https://naja.js.org/#/guide/01-install-setup-naja] jako node.js balíček (pro použití s aplikacemi Webpack, Rollup, Vite, Parcel a dalšími):
+K obsluze snippetů na straně prohlížeče slouží [knihovna Naja |https://naja.js.org]. Tu [nainstalujte |https://naja.js.org/#/guide/01-install-setup-naja] jako node.js balíček (pro použití s aplikacemi Webpack, Rollup, Vite, Parcel a dalšími):
```shell
npm install naja
@@ -60,59 +77,55 @@ npm install naja
```
+Nejprve je potřeba knihovnu [inicializovat |https://naja.js.org/#/guide/01-install-setup-naja?id=initialization]:
-Snippety
-========
+```js
+naja.initialize();
+```
-Daleko silnější nástroj představuje vestavěná podpora AJAXových snippetů. Díky ní lze udělat z obyčejné aplikace AJAXovou prakticky několika řádky kódu. Jak to celé funguje, demonstruje příklad Fifteen, jehož kód najdete na [GitHubu |https://github.com/nette-examples/fifteen].
+Aby se z obyčejného odkazu (signálu) nebo odeslání formuláře vytvořil AJAXový požadavek, stačí označit příslušný odkaz, formulář nebo tlačítko třídou `ajax`:
-Snippety fungují tak, že při prvotním (tedy neAJAXovém) požadavku se přenese celá stránka a poté se při každém již AJAXovém [subrequestu |components#Signál] (= požadavku na stejný presenter a view) přenáší pouze kód změněných částí ve zmíněném úložišti `payload`. K tomu slouží dva mechanismy: invalidace a renderování snippetů.
+```html
+Go
-Snippety vám mohou připomínat Hotwire pro Ruby on Rails nebo Symfony UX Turbo, nicméně Nette s nimi přišlo už o čtrnáct let dříve.
+
+nebo
-Invalidace snippetů
-===================
+
+```
+
+
+Překreslení snippetů
+--------------------
-Každý objekt třídy [Control |components] (což je i samotný Presenter) si umí zapamatovat, jestli při signálu došlo ke změnám, které si vyžadují jej překreslit. K tomu slouží dvojice metod `redrawControl()` a `isControlInvalid()`. Příklad:
+Každý objekt třídy [Control |components] (včetně samotného Presenteru) eviduje, zda došlo ke změnám vyžadujícím jeho překreslení. K tomu slouží metoda `redrawControl()`:
```php
public function handleLogin(string $user): void
{
- // po přihlášení uživatele se musí objekt překreslit
+ // po přihlášení je potřeba překreslit relevantní část
$this->redrawControl();
// ...
}
```
-Nette však nabízí ještě jemnější rozlišení, než na úrovni komponent. Uvedené metody mohou totiž jako argument přijímat název tzv. "snippetu", nebo-li výstřižku. Lze tedy invalidovat (rozuměj: vynutit překreslení) na úrovni těchto snippetů (každý objekt může mít libovolné množství snippetů). Pokud se invaliduje celá komponenta, tak se i každý snippet překreslí. Komponenta je "invalidní" i tehdy, pokud je invalidní některá její subkomponenta.
-```php
-$this->isControlInvalid(); // -> false
-
-$this->redrawControl('header'); // invaliduje snippet 'header'
-$this->isControlInvalid('header'); // -> true
-$this->isControlInvalid('footer'); // -> false
-$this->isControlInvalid(); // -> true, alespoň jeden snippet je invalid
+Nette umožňuje ještě jemnější kontrolu toho, co se má překreslit. Uvedená metoda totiž může jako argument přijímat název snippetu. Lze tedy invalidovat (rozuměj: vynutit překreslení) na úrovni částí šablony. Pokud se invaliduje celá komponenta, tak se překreslí i každý její snippet:
-$this->redrawControl(); // invaliduje celou komponentu, každý snippet
-$this->isControlInvalid('footer'); // -> true
+```php
+// invaliduje snippet 'header'
+$this->redrawControl('header');
```
-Komponenta, která přijímá signál, je automaticky označena za invalidní.
-
-Díky invalidaci snippetů přesně víme, které části kterých prvků bude potřeba překreslit.
-
-Tagy `{snippet} … {/snippet}` .{toc: Tag snippet}
-=================================================
+Snippety v Latte
+----------------
-Vykreslování stránky probíhá velmi podobně jako při běžném požadavku: načtou se stejné šablony atd. Podstatné však je vynechání částí, které se nemají dostat na výstup; ostatní části se přiřadí k identifikátoru a pošlou se uživateli ve formátu srozumitelném pro obslužný program JavaScriptu.
-
-
-Syntaxe
--------
-
-Pokud se uvnitř šablony nachází control nebo snippet, musíme jej obalit párovou značkou `{snippet} ... {/snippet}` - ty totiž zajistí, že se vykreslený snippet vystřihne a pošle do prohlížeče. Také jej obalí pomocnou značkou `` s vygenerovaným `id`. V uvedeném příkladě je snippet pojmenován jako `header` a může představovat i například šablonu controlu:
+Používání snippetů v Latte je nesmírně snadné. Chcete-li definovat část šablony jako snippet, obalte ji jednoduše značkami `{snippet}` a `{/snippet}`:
```latte
{snippet header}
@@ -120,7 +133,9 @@ Pokud se uvnitř šablony nachází control nebo snippet, musíme jej obalit pá
{/snippet}
```
-Snippetu jiného typu než `
` nebo snippetu s dalšími HTML atributy docílíme použitím atributové varianty:
+Snippet vytvoří v HTML stránce element `/addRoute('/[/]', [
@@ -225,7 +224,7 @@ $router->addRoute('/[/]', [
]);
```
-Nebo můžeme použít tuto formu, všimněte si přepisu validačního regulárního výrazu:
+Pro detailnější specifikaci lze použít ještě rozšířenější formu, kde kromě výchozích hodnot můžeme nastavit i další vlastnosti parametrů, jako třeba validační regulární výraz (viz parametr `id`):
```php
use Nette\Routing\Route;
@@ -243,7 +242,7 @@ $router->addRoute('/[/]', [
]);
```
-Tyto upovídanější formáty se hodí pro doplnění dalších metadat.
+Je důležité poznamenat, že pokud parametry definované v poli nejsou uvedeny v masce cesty, jejich hodnoty nelze změnit, ani pomocí query parametrů uvedených za otazníkem v URL.
Filtry a překlady
@@ -307,7 +306,7 @@ Parametry `presenter`, `action` a `module` už mají předdefinované filtry, kt
Obecné filtry
-------------
-Vedle filtrů určených pro konkrétní parametry můžeme definovat též obecné filtry, které obdrží asociativní pole všech parametrů, které mohou jakkoliv modifikovat a poté je vrátí. Obecné filtry definujeme pod klíčem `null`.
+Vedle filtrů určených pro konkrétní parametry můžeme definovat též obecné filtry, které obdrží asociativní pole všech parametrů, které mohou jakkoliv modifikovat a poté je vrátí. Obecné filtry definujeme pod prázdným klíčem.
```php
use Nette\Routing\Route;
@@ -315,7 +314,7 @@ use Nette\Routing\Route;
$router->addRoute('/', [
'presenter' => 'Home',
'action' => 'default',
- null => [
+ '' => [
Route::FilterIn => function (array $params): array { /* ... */ },
Route::FilterOut => function (array $params): array { /* ... */ },
],
@@ -342,10 +341,33 @@ $router->addRoute('product/', 'Product:detail');
Při přístupu na starou URL presenter automaticky přesměruje na nové URL, takže vám tyto stránky vyhledávače nezaindexují dvakrát (viz [#SEO a kanonizace]).
+Dynamické routování s callbacky
+-------------------------------
+
+Dynamické routování s callbacky vám umožňuje přiřadit routám přímo funkce (callbacky), které se vykonají, když je daná cesta navštívena. Tato flexibilní funkčnost vám umožní rychle a efektivně vytvářet různé koncové body (endpoints) pro vaši aplikaci:
+
+```php
+$router->addRoute('test', function () {
+ echo 'jste na adrese /test';
+});
+```
+
+Můžete také definovat v masce parametry, které se automaticky předají do vašeho callbacku:
+
+```php
+$router->addRoute('', function (string $lang) {
+ echo match ($lang) {
+ 'cs' => 'Vítejte na české verzi našeho webu!',
+ 'en' => 'Welcome to the English version of our website!',
+ };
+});
+```
+
+
Moduly
------
-Pokud máme více rout, které spadají do společného [modulu |modules], využijeme `withModule()`:
+Pokud máme více rout, které spadají do společného [modulu |directory-structure#Presentery a šablony], využijeme `withModule()`:
```php
$router = new RouteList;
@@ -454,10 +476,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;
@@ -476,7 +498,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]:
@@ -522,7 +544,7 @@ Framework přispívá k SEO (optimalizaci nalezitelnosti na internetu) tím, že
Tomuto procesu se říká kanonizace. Kanonickou URL je ta, kterou vygeneruje router, tj. první vyhovující routa v kolekci bez příznaku OneWay. Proto v kolekci uvádíme **primární routy jako první**.
-Kanonizaci provádí presenter, více v kapitole [kanonizace|presenters#kanonizace].
+Kanonizaci provádí presenter, více v kapitole [kanonizace |presenters#Kanonizace].
HTTPS
@@ -606,8 +628,7 @@ class MyRouter implements Nette\Routing\Router
}
```
-Metoda `match` zpracuje aktuální požadavek [$httpRequest |http:request], ze kterého lze získat nejen URL, ale i hlavičky atd., do pole obsahující název presenteru a jeho parametry. Pokud požadavek zpracovat neumí, vrátí null.
-Při zpracování požadavku musíme vrátit minimálně presenter a akci. Název presenteru je úplný a obsahuje i případné moduly:
+Metoda `match` zpracuje aktuální požadavek [$httpRequest |http:request], ze kterého lze získat nejen URL, ale i hlavičky atd., do pole obsahující název presenteru a jeho parametry. Pokud požadavek zpracovat neumí, vrátí null. Při zpracování požadavku musíme vrátit minimálně presenter a akci. Název presenteru je úplný a obsahuje i případné moduly:
```php
[
@@ -640,7 +661,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;
@@ -671,7 +692,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/cs/templates.texy b/application/cs/templates.texy
index 3630e00ee4..568b40837e 100644
--- a/application/cs/templates.texy
+++ b/application/cs/templates.texy
@@ -37,27 +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, je odpovědí [chyba 404|presenters#Chyba 404 a spol.].
+/--pre
+app/
+└── Presentation/
+ └── Home/
+ ├── HomePresenter.php
+ └── default.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')`.
+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`:
+
+/--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ů:
-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`.
+/--pre
+app/
+└── Presentation/
+ ├── @layout.latte ← společný layout
+ └── Home/
+ ├── @layout.latte ← jen pro presenter Home
+ ├── HomePresenter.php
+ └── default.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.
+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, bude se dohledávat i o další adresářové úrovně výš, podle zanoření modulu.
+
+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')`.
+
+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ů.
@@ -66,15 +114,48 @@ Soubory, kde se dohledávají šablony layoutu, lze změnit překrytím metody [
Proměnné v šabloně
------------------
-Proměnné do šablony předáváme tak, že je zapíšeme do `$this->template` a potom je máme k dispozici v šabloně jako lokální proměnné:
+Proměnné do šablony předáváme zápisem do `$this->template`. V šabloně jsou pak dostupné jako lokální proměnné:
```php
$this->template->article = $this->articles->getById($id);
```
-Takto jednoduše můžeme do šablon předat jakékoliv proměnné. Při vývoji robustních aplikací ale bývá užitečnější se omezit. Například tak, že explicitně nadefinujeme výčet proměnných, které šablona očekává, a jejich typů. Díky tomu nám bude moci PHP kontrolovat typy, IDE správně našeptávat a statická analýza odhalovat chyby.
+Pokud chcete, aby se hodnota určité property automaticky předala do šablony jako proměnná, označte ji atributem `#[TemplateVariable]` a viditelností public nebo protected: .{data-version:3.2.9}
+
+```php
+use Nette\Application\Attributes\TemplateVariable;
+
+class ArticlePresenter extends Nette\Application\UI\Presenter
+{
+ #[TemplateVariable]
+ public string $siteName = 'Můj blog';
+}
+```
+
+Pokud do šablony vložíte proměnnou se stejným názvem, `#[TemplateVariable]` ji nepřepíše.
+
+
+Výchozí proměnné
+----------------
+
+Presentery a komponenty předávají do šablon několik užitečných proměnných automaticky:
+
+- `$basePath` je absolutní URL cesta ke kořenovému adresáři (např. `/eshop`)
+- `$baseUrl` je absolutní URL ke kořenovému adresáři (např. `http://localhost/eshop`)
+- `$user` je objekt [reprezentující uživatele |security:authentication]
+- `$presenter` je aktuální presenter
+- `$control` je aktuální komponenta nebo presenter
+- `$flashes` pole [zpráv |presenters#Flash zprávy] zaslaných funkcí `flashMessage()`
+
+Pokud používáte vlastní třídu šablony, tyto proměnné se předají, pokud pro ně vytvoříte property.
-A jak takový výčet nadefinujeme? Jednoduše v podobě třídy a její properties. Pojmenujeme ji podobně jako presenter, jen s `Template` na konci:
+
+Typově bezpečné šablony
+-----------------------
+
+Při vývoji robustních aplikací je užitečné explicitně nadefinovat, jaké proměnné šablona očekává a jakého jsou typu. Získáte tak typovou kontrolu v PHP, chytré našeptávání v IDE a schopnost statické analýzy odhalovat chyby.
+
+Jak takový výčet nadefinovat? Jednoduše v podobě třídy s properties reprezentujícími proměnné šablony. Pojmenujeme ji podobně jako presenter, jen s `Template` na konci:
```php
/**
@@ -93,22 +174,22 @@ class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template
}
```
-Objekt `$this->template` v presenteru bude nyní instancí třídy `ArticleTemplate`. Takže PHP bude při zápisu kontrolovat deklarované typy. A počínaje verzí PHP 8.2 upozorní i na zápis do neexistující proměnné, v předchozích verzích lze téhož dosáhnout použitím traity [Nette\SmartObject |utils:smartobject].
+Objekt `$this->template` v presenteru bude nyní instancí třídy `ArticleTemplate`. PHP tak bude při zápisu kontrolovat deklarované typy.
-Anotace `@property-read` je určená pro IDE a statickou analýzu, díky ní bude fungovat našeptávání, viz "PhpStorm and code completion for $this->template":https://blog.nette.org/en/phpstorm-and-code-completion-for-this-template.
+Anotace `@property-read` slouží pro IDE a statickou analýzu, díky ní bude fungovat našeptávání, viz "PhpStorm and code completion for $this->template":https://blog.nette.org/en/phpstorm-and-code-completion-for-this-template.
[* phpstorm-completion.webp *]
-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:
+Našeptávání můžete využít i přímo v šablonách. Stačí do PhpStorm nainstalovat plugin pro Latte a uvést na začátek šablony název třídy parametrů šablony, 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\Presentation\Article\ArticleTemplate}
...
```
-Takto fungují i šablony v komponentách, stačí jen dodržet jmennou konvenci a pro komponentu např. `FifteenControl` vytvořit třídu šablony `FifteenTemplate`.
+Totéž platí i pro komponenty. Stačí dodržet jmennou konvenci a pro komponentu např. `FifteenControl` vytvořit třídu parametrů `FifteenTemplate`.
-Pokud potřebujete vytvořit `$template` jako instanci jiné třídy, využijte metodu `createTemplate()`:
+Pokud potřebujete použít jinou třídu parametrů, využijte metodu `createTemplate()`:
```php
public function renderDefault(): void
@@ -121,21 +202,6 @@ public function renderDefault(): void
```
-Výchozí proměnné
-----------------
-
-Presentery a komponenty předávají do šablon několik užitečných proměnných automaticky:
-
-- `$basePath` je absolutní URL cesta ke kořenovému adresáři (např. `/eshop`)
-- `$baseUrl` je absolutní URL ke kořenovému adresáři (např. `http://localhost/eshop`)
-- `$user` je objekt [reprezentující uživatele |security:authentication]
-- `$presenter` je aktuální presenter
-- `$control` je aktuální komponenta nebo presenter
-- `$flashes` pole [zpráv |presenters#flash zprávy] zaslaných funkcí `flashMessage()`
-
-Pokud používáte vlastní třídu šablony, tyto proměnné se předají, pokud pro ně vytvoříte property.
-
-
Vytváření odkazů
----------------
@@ -157,24 +223,70 @@ Více informací najdete v kapitole [Vytváření odkazů URL|creating-links].
Vlastní filtry, značky apod.
----------------------------
-Šablonovací systém Latte lze rozšířit o vlastní filtry, funkce, značky apod. Lze tak učinit přímo v metodě `render` nebo `beforeRender()`:
+Šablonovací systém Latte lze rozšířit o vlastní filtry, funkce, značky a další prvky. K dispozici jsou tři způsoby, jak to udělat, od nejrychlejších ad-hoc řešení až po architektonický přístup pro celou aplikaci.
+
+**Ad-hoc v metodách presenteru**
+
+Nejrychlejší způsob je přidat filtr nebo funkci přímo v kódu presenteru či komponenty. V presenteru je k tomu vhodná metoda `beforeRender()` nebo `render()`:
```php
-public function beforeRender(): void
+protected function beforeRender(): void
{
// přidání filtru
- $this->template->addFilter('foo', /* ... */);
+ $this->template->addFilter('money', fn($val) => round($val) . ' Kč');
- // nebo konfigurujeme přímo objekt Latte\Engine
+ // přidání funkce
+ $this->template->addFunction('isWeekend', fn($date) => $date->format('N') >= 6);
+}
+```
+
+V šabloně pak:
+
+```latte
+
` se speciálním vygenerovaným `id`. Při překreslení snippetu se pak aktulizuje obsah tohoto elementu. Proto je nutné, aby při prvotním vykreslení stránky se vykreslily také všechny snippety, byť mohou být třeba na začátku prázdné.
+
+Můžete vytvořit i snippet s jiným elementem než `(args...)` .{toc: action()}
--------------------------------------------------
-Obdoba metody `render()`. Zatímco `render()` je určená k tomu, aby připravila data pro konkrétní šablonu, která se následně vykreslí, tak v `action()` se zpracovává požadavek bez návaznosti na vykreslování šablony. Například se zpracují data, přihlásí či odhlásí uživatel, a tak podobně, a poté [přesměruje jinam|#Přesměrování].
+Obdoba metody `render()`. Zatímco `render()` je určená k tomu, aby připravila data pro konkrétní šablonu, která se následně vykreslí, tak v `action()` se zpracovává požadavek bez návaznosti na vykreslování šablony. Například se zpracují data, přihlásí či odhlásí uživatel, a tak podobně, a poté [přesměruje jinam |#Přesměrování].
Důležité je, že `action()` se volá dříve než `render()`, takže v ní můžeme případně změnit další běh dějin, tj. změnit šablonu, která se bude kreslit, a také metodu `render()`, která se bude volat. A to pomocí `setView('jineView')`.
-Metodě se předávají parametry z požadavku. Je možné a doporučené uvést parametrům typy, např. `actionShow(int $id, string $slug = null)` - pokud bude parametr `id` chybět nebo pokud nebude integer, presenter vrátí [chybu 404|#Chyba 404 a spol.] a ukončí činnost.
+Metodě se předávají parametry z požadavku. Je možné a doporučené uvést parametrům typy, např. `actionShow(int $id, ?string $slug = null)` - pokud bude parametr `id` chybět nebo pokud nebude integer, presenter vrátí [chybu 404 |#Chyba 404 a spol] a ukončí činnost.
`handle(args...)` .{toc: handle()}
@@ -115,13 +115,15 @@ Odpovědí presenteru je zpravidla [vykreslení šablony s HTML stránkou|templa
Kdykoliv během životního cyklu můžeme některou z následujících metod odeslat odpověď a zároveň tak ukončit presenter:
-- `redirect()`, `redirectPermanent()`, `redirectUrl()` a `forward()` [přesměruje|#přesměrování]
-- `error()` ukončí presenter [kvůli chybě|#Chyba 404 a spol.]
+- `redirect()`, `redirectPermanent()`, `redirectUrl()` a `forward()` [přesměruje |#Přesměrování]
+- `error()` ukončí presenter [kvůli chybě |#Chyba 404 a spol]
- `sendJson($data)` presenter ukončí a [odešle data |#Odeslání JSON] ve formátu JSON
- `sendTemplate()` presenter ukončí a ihned [vykreslí šablonu |templates]
-- `sendResponse($response)` presenter ukončí a odešle [vlastní odpověď|#Odpovědi]
+- `sendResponse($response)` presenter ukončí a odešle [vlastní odpověď |#Odpovědi]
- `terminate()` presenter ukončí bez odpovědi
+Každá z těchto metod okamžitě ukončí činnost presenteru vyhozením tzv. tiché ukončovací výjimky `Nette\Application\AbortException`.
+
Pokud žádnou z těchto metod nezavoláte, presenter automaticky přistoupí k vykreslí šablony. 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.
@@ -158,7 +160,7 @@ Metoda `forward()` přejde na nový presenter okamžitě bez HTTP přesměrován
$this->forward('Product:show');
```
-Příklad tzv. dočasného přesměrování s HTTP kódem 302 nebo 303:
+Příklad tzv. dočasného přesměrování s HTTP kódem 302 (nebo 303, je-li metoda aktuálního požadavku POST):
```php
$this->redirect('Product:show', $id);
@@ -170,7 +172,7 @@ Permanentní přesměrování s HTTP kódem 301 docílíte takto:
$this->redirectPermanent('Product:show', $id);
```
-Na jinou URL mimo aplikaci lze přesměrovat metodou `redirectUrl()`:
+Na jinou URL mimo aplikaci lze přesměrovat metodou `redirectUrl()`. Jako druhý parametr lze uvést HTTP kód, výchozí je 302 (nebo 303, je-li metoda aktuálního požadavku POST):
```php
$this->redirectUrl('https://nette.org');
@@ -178,7 +180,7 @@ $this->redirectUrl('https://nette.org');
Přesměrování okamžitě ukončí činnost presenteru vyhozením tzv. tiché ukončovací výjimky `Nette\Application\AbortException`.
-Před přesměrováním lze odeslat [flash message |#flash zprávy], tedy zprávy, které budou po přesměrování zobrazeny v šabloně.
+Před přesměrováním lze odeslat [flash message |#Flash zprávy], tedy zprávy, které budou po přesměrování zobrazeny v šabloně.
Flash zprávy
@@ -205,7 +207,7 @@ $this->redirect(/* ... */); // a přesměrujeme
Chyba 404 a spol.
=================
-Pokud nelze splnit požadavek, třeba z důvodu, že článek který chceme zobrazit neexistuje v databázi, vyhodíme chybu 404 metodou `error(string $message = null, int $httpCode = 404)`.
+Pokud nelze splnit požadavek, třeba z důvodu, že článek který chceme zobrazit neexistuje v databázi, vyhodíme chybu 404 metodou `error(?string $message = null, int $httpCode = 404)`.
```php
public function renderShow(int $id): void
@@ -218,8 +220,7 @@ public function renderShow(int $id): void
}
```
-HTTP kód chyby lze předat jako druhý parametr, výchozí je 404. Metoda funguje tak, že vyhodí výjimku `Nette\Application\BadRequestException`, načež `Application` předá řízení error-presenteru. Což je presenter, jehož úkolem je zobrazit stránku informující o nastalé chybě.
-Nastavení error-preseteru se provádí v [konfiguraci application|configuration].
+HTTP kód chyby lze předat jako druhý parametr, výchozí je 404. Metoda funguje tak, že vyhodí výjimku `Nette\Application\BadRequestException`, načež `Application` předá řízení error-presenteru. Což je presenter, jehož úkolem je zobrazit stránku informující o nastalé chybě. Nastavení error-preseteru se provádí v [konfiguraci application|configuration].
Odeslání JSON
@@ -236,6 +237,32 @@ public function actionData(): void
```
+Parametry požadavku .{data-version:3.1.14}
+==========================================
+
+Presenter a také každá komponenta získává z HTTP požadavku své parametry. Jejich hodnotu zjistíte metodou `getParameter($name)` nebo `getParameters()`. Hodnoty jsou řetězce či pole řetězců, jde v podstatě o surové data získané přímo z URL.
+
+Pro větší pohodlí doporučujeme parametry zpřístupnit přes property. Stačí je označit atributem `#[Parameter]`:
+
+```php
+use Nette\Application\Attributes\Parameter; // tento řádek je důležitý
+
+class HomePresenter extends Nette\Application\UI\Presenter
+{
+ #[Parameter]
+ public string $theme; // musí být public
+}
+```
+
+U property doporučujeme uvádět i datový typ (např. `string`) a Nette podle něj hodnotu automaticky přetypuje. Hodnoty parametrů lze také [validovat |#Validace parametrů].
+
+Při vytváření odkazu lze parametrům hodnotu přímo nastavit:
+
+```latte
+click
+```
+
+
Persistentní parametry
======================
@@ -257,7 +284,7 @@ class ProductPresenter extends Nette\Application\UI\Presenter
Pokud bude `$this->lang` mít hodnotu například `'en'`, tak i odkazy vytvořené pomocí `link()` nebo `n:href` budou obsahovat parameter `lang=en`. A po kliknutí na odkaz bude opět `$this->lang = 'en'`.
-U property doporučujeme uvádět i datový typ (např. `string`) a můžete uvést i výchozí hodnotu. Hodnoty parametrů lze [validovat |#Validace persistentních parametrů].
+U property doporučujeme uvádět i datový typ (např. `string`) a můžete uvést i výchozí hodnotu. Hodnoty parametrů lze [validovat |#Validace parametrů].
Persistentní parametry se standardně přenášejí mezi všemi akcemi daného presenteru. Aby se přenášely i mezi více presentery, je potřeba je definovat buď:
@@ -307,18 +334,12 @@ Jdeme do hloubky
S tím, co jsme si dosud v této kapitole ukázali, si nejspíš úplně vystačíte. Následující řádky jsou určeny těm, kdo se zajímají o presentery do hloubky a chtějí vědět úplně všechno.
-Požadavek a parametry
----------------------
-
-Požadavek, který vyřizuje presenter, je objekt [api:Nette\Application\Request] a vrací ho metoda presenteru `getRequest()`. Jeho součástí je pole parametrů a každý z nich patří buď některé z komponent, nebo přímo presenteru (což je vlastně také komponenta, byť speciální). Nette tedy parametry přerozdělí a předá mezi jednotlivé komponenty (a presenter) zavoláním metody `loadState(array $params)`. Získat parametry lze metodu `getParameters(): array`, jednotlivě pomocí `getParameter($name)`. Hodnoty parametrů jsou řetězce či pole řetězců, jde v podstatě o surové data získané přímo z URL.
-
+Validace parametrů
+------------------
-Validace persistentních parametrů
----------------------------------
+Hodnoty [parametrů požadavku |#Parametry požadavku] a [persistentních parametrů |#Persistentní parametry] přijatých z URL zapisuje do properties metoda `loadState()`. Ta také kontroluje, zda odpovídá datový typ uvedený u property, jinak odpoví chybou 404 a stránka se nezobrazí.
-Hodnoty [persistentních parametrů |#Persistentní parametry] přijatých z URL zapisuje do properties metoda `loadState()`. Ta také kontroluje, zda odpovídá datový typ uvedený u property, jinak odpoví chybou 404 a stránka se nezobrazí.
-
-Nikdy slepě nevěřte persistentním parametrům, protože mohou být snadno uživatelem přepsány v URL. Takto například ověříme, zda je jazyk `$this->lang` mezi podporovanými. Vhodnou cestou je přepsat zmíněnou metodu `loadState()`:
+Nikdy slepě nevěřte parametrům, protože mohou být snadno uživatelem přepsány v URL. Takto například ověříme, zda je jazyk `$this->lang` mezi podporovanými. Vhodnou cestou je přepsat zmíněnou metodu `loadState()`:
```php
class ProductPresenter extends Nette\Application\UI\Presenter
@@ -341,6 +362,8 @@ class ProductPresenter extends Nette\Application\UI\Presenter
Uložení a obnovení požadavku
----------------------------
+Požadavek, který vyřizuje presenter, je objekt [api:Nette\Application\Request] a vrací ho metoda presenteru `getRequest()`.
+
Aktuální požadavek lze uložit do session nebo naopak z ní obnovit a nechat jej presenter znovu vykonat. To se hodí například v situaci, když uživatel vyplňuje formulář a vyprší mu přihlášení. Aby o data nepřišel, před přesměrováním na přihlašovací stránku aktuální požadavek uložíme do session pomocí `$reqId = $this->storeRequest()`, které vrátí jeho identifikátor v podobě krátkého řetězce a ten předáme jako parameter přihlašovacímu presenteru.
Po přihlášení zavoláme metodu `$this->restoreRequest($reqId)`, která požadavek vyzvedne ze session a forwarduje na něj. Metoda přitom ověří, že požadavek vytvořil stejný uživatel, jako se nyní přihlásil. Pokud by se přihlásil jiný uživatel nebo klíč byl neplatný, neudělá nic a program pokračuje dál.
@@ -362,7 +385,7 @@ K přesměrování nedojde při AJAXovém nebo POST požadavku, protože by doš
Kanonizaci můžete vyvolat i manuálně pomocí metody `canonicalize()`, které se podobně jako metodě `link()` předá presenter, akce a parametry. Vyrobí odkaz a porovná ho s aktuální URL adresou. Pokud se liší, tak přesměruje na vygenerovaný odkaz.
```php
-public function actionShow(int $id, string $slug = null): void
+public function actionShow(int $id, ?string $slug = null): void
{
$realSlug = $this->facade->getSlugForId($id);
// přesměruje, pokud $slug se liší od $realSlug
@@ -374,7 +397,7 @@ public function actionShow(int $id, string $slug = null): void
Události
--------
-Kromě metod `startup()`, `beforeRender()` a `shutdown()`, které se volají jako součást životního cyklu presenteru, lze definovat ještě další funkce, které se mají automaticky zavolat. Presenter definuje tzv. [událost|nette:glossary#Události], jejichž handlery přidáte do polí `$onStartup`, `$onRender` a `$onShutdown`.
+Kromě metod `startup()`, `beforeRender()` a `shutdown()`, které se volají jako součást životního cyklu presenteru, lze definovat ještě další funkce, které se mají automaticky zavolat. Presenter definuje tzv. [událost |nette:glossary#události], jejichž handlery přidáte do polí `$onStartup`, `$onRender` a `$onShutdown`.
```php
class ArticlePresenter extends Nette\Application\UI\Presenter
@@ -425,6 +448,59 @@ $this->sendResponse(new Responses\CallbackResponse($callback));
```
+Omezení přístupu pomocí `#[Requires]` .{data-version:3.2.2}
+-----------------------------------------------------------
+
+Atribut `#[Requires]` poskytuje pokročilé možnosti pro omezení přístupu k presenterům a jejich metodám. Lze jej použít pro specifikaci HTTP metod, vyžadování AJAXového požadavku, omezení na stejný původ (same origin), a přístup pouze přes forwardování. Atribut lze aplikovat jak na třídy presenterů, tak na jednotlivé metody `action()`, `render()`, `handle()` a `createComponent()`.
+
+Můžete určit tyto omezení:
+- na HTTP metody: `#[Requires(methods: ['GET', 'POST'])]`
+- vyžadování AJAXového požadavku: `#[Requires(ajax: true)]`
+- přístup pouze ze stejného původu: `#[Requires(sameOrigin: true)]`
+- přístup pouze přes forward: `#[Requires(forward: true)]`
+- omezení na konkrétní akce: `#[Requires(actions: 'default')]`
+
+Podrobnosti najdete v návodu [Jak používat atribut Requires |best-practices:attribute-requires].
+
+
+Kontrola HTTP metody
+--------------------
+
+Presentery v Nette automaticky ověřují HTTP metodu každého příchozího požadavku. Důvodem pro tuto kontrolu je především bezpečnost. Standardně jsou povoleny metody `GET`, `POST`, `HEAD`, `PUT`, `DELETE`, `PATCH`.
+
+Chcete-li povolit navíc například metodu `OPTIONS`, použijte k tomu atribut `#[Requires]` (od Nette Application v3.2):
+
+```php
+#[Requires(methods: ['GET', 'POST', 'HEAD', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'])]
+class MyPresenter extends Nette\Application\UI\Presenter
+{
+}
+```
+
+Ve verzi 3.1 se ověření provádí v `checkHttpMethod()`, která zjišťuje, zda je metoda specifikovaná v požadavku obsažena v poli `$presenter->allowedMethods`. Přidání metody udělejte takto:
+
+```php
+class MyPresenter extends Nette\Application\UI\Presenter
+{
+ protected function checkHttpMethod(): void
+ {
+ $this->allowedMethods[] = 'OPTIONS';
+ parent::checkHttpMethod();
+ }
+}
+```
+
+Je důležité zdůraznit, že pokud povolíte metodu `OPTIONS`, musíte ji následně také patřičně obsloužit v rámci svého presenteru. Metoda je často používána jako tzv. preflight request, který prohlížeč automaticky odesílá před skutečným požadavkem, když je potřeba zjistit, zda je požadavek povolený z hlediska CORS (Cross-Origin Resource Sharing) politiky. Pokud metodu povolíte, ale neimplementujete správnou odpověď, může to vést k nekonzistencím a potenciálním bezpečnostním problémům.
+
+
+Označení zastaralých akcí .{data-version:3.2.3}
+-----------------------------------------------
+
+Atribut `#[Deprecated]` slouží k označení akcí, signálů nebo celých presenterů, které jsou zastaralé a měly by být v budoucnu odstraněny. Při generování odkazů na takto označené části aplikace Nette vyhodí varování, které vývojáře upozorní.
+
+Atribut lze aplikovat jak na celou třídu presenteru, tak na jednotlivé metody `action()`, `render()` a `handle()`.
+
+
Další četba
===========
diff --git a/application/cs/routing.texy b/application/cs/routing.texy
index 816436fac4..3a2e753731 100644
--- a/application/cs/routing.texy
+++ b/application/cs/routing.texy
@@ -12,10 +12,9 @@ Router má na starosti vše okolo URL adres, aby vy už jste nad nimi nemuseli p
-Lidštější URL (nebo taky cool či pretty URL) jsou použitelnější, zapamatovatelnější a pozitivně přispívají k SEO. Nette na to myslí a vychází vývojářům plně vstříc. Můžete si pro svou aplikaci navrhnout přesně takovou strukturu URL adres, jakou budete chtít.
-Můžete ji navrhnout dokonce až ve chvíli, když už je aplikace hotová, protože se to obejde bez zásahů do kódu či šablon. Definuje se totiž elegantním způsobem na jednom [jediném místě |#Začlenění do aplikace], v routeru, a není tak roztroušen ve formě anotací ve všech presenterech.
+Lidštější URL (nebo taky cool či pretty URL) jsou použitelnější, zapamatovatelnější a pozitivně přispívají k SEO. Nette na to myslí a vychází vývojářům plně vstříc. Můžete si pro svou aplikaci navrhnout přesně takovou strukturu URL adres, jakou budete chtít. Můžete ji navrhnout dokonce až ve chvíli, když už je aplikace hotová, protože se to obejde bez zásahů do kódu či šablon. Definuje se totiž elegantním způsobem na jednom [jediném místě |#Začlenění do aplikace], v routeru, a není tak roztroušen ve formě anotací ve všech presenterech.
-Router v Nette je mimořádný tím, že je **obousměrný.** Umí jak dekódovat URL v HTTP požadavku, tak i odkazy vytvářet. Hraje tedy zásadní roli v [Nette Application|how-it-works#Nette Application], protože jednak rozhoduje o tom, který presenter a action bude vykonávat aktuální požadavek, ale také se využívá pro [generování URL |creating-links] v šabloně atd.
+Router v Nette je mimořádný tím, že je **obousměrný.** Umí jak dekódovat URL v HTTP požadavku, tak i odkazy vytvářet. Hraje tedy zásadní roli v [Nette Application |how-it-works#Nette Application], protože jednak rozhoduje o tom, který presenter a action bude vykonávat aktuální požadavek, ale také se využívá pro [generování URL |creating-links] v šabloně atd.
Ovšem router není limitován jen pro tohle využití, můžete jej použít v aplikacích, kde se vůbec presentery nepoužívají, pro REST API, atd. Více v části [#samostatné použití].
@@ -216,7 +215,7 @@ $router->addRoute('//www.%sld%.%tld%/%basePath%/` pomocí n:attributu:
```latte
@@ -129,138 +144,112 @@ Snippetu jiného typu než `()` nebo `action()` metody. Takže pokud jsme na stránce `Product:show` a `id: 123`, odkaz na `this` předá i tento parameter.
+Zároveň se přenáší i všechny parametry uvedené v signatuře metody `action()` nebo `render()`, pokud není `action()` definovaná. Takže pokud jsme na stránce `Product:show` a `id: 123`, odkaz na `this` předá i tento parameter.
Samozřejmě je možné parametry specifikovat přímo:
@@ -179,10 +181,25 @@ Pro zjištění, zda jsme v určitém modulu nebo jeho submodulu, použijeme met
```
+Změna základu pro odkazy .{data-version:v3.2.7}
+===============================================
+
+Ve výchozím stavu se relativní odkazy odvíjejí od aktuálního presenteru. To lze změnit pomocí `{linkBase}`:
+
+```latte
+{linkBase Admin:Dashboard}
+detail produktu
+```
+
+Odkaz povede na `Admin:Dashboard:Product:show`. Ovlivněny jsou pouze relativní odkazy - absolutní odkazy začínající dvojtečkou a odkazy na aktuální presenter (`this`, `show`) zůstávají nezměněny.
+
+`{linkBase}` platí pro celou šablonu a je užitečné zejména v šablonách layoutu, kde zajistí konzistentní odkazy nezávisle na volajícím presenteru.
+
+
Odkazy na signál
================
-Cílem odkazu nemusí být jen presenter a akce, ale také [signál|components#Signál] (volají metodu `handle()`). Pak je syntaxe následující:
+Cílem odkazu nemusí být jen presenter a akce, ale také [signál |components#Signál] (volají metodu `handle()`). Pak je syntaxe následující:
```
[//] [sub-component:]signal! [#fragment]
@@ -213,7 +230,7 @@ Protože [komponenty|components] jsou samostatné znovupoužitelné celky, kter
Pokud bychom chtěli v šabloně komponenty odkazovat na presentery, použijeme k tomu značku `{plink}`:
```latte
-úvod
+úvod
```
nebo v kódu
@@ -223,6 +240,30 @@ $this->getPresenter()->link('Home:default')
```
+Aliasy .{data-version:v3.2.2}
+=============================
+
+Občas se může hodit přiřadit dvojici Presenter:akce snadno zapamatovatelný alias. Například úvodní stránku `Front:Home:default` pojmenovat jednoduše jako `home` nebo `Admin:Dashboard:default` jako `admin`.
+
+Aliasy se definují v [konfiguraci|configuration] pod klíčem `application › aliases`:
+
+```neon
+application:
+ aliases:
+ home: Front:Home:default
+ admin: Admin:Dashboard:default
+ sign: Front:Sign:in
+```
+
+V odkazech se pak zapisují pomocí zavináče, například:
+
+```latte
+administrace
+```
+
+Podporované jsou i ve všech metodách pracujících s odkazy, jako je `redirect()` a podobně.
+
+
Neplatné odkazy
===============
@@ -257,6 +298,6 @@ Jak vytvářet odkazy s podobným komfortem jako má metoda `link()`, ale bez p
LinkGenerátor je služba, kterou si můžete nechat předat přes konstruktor a poté vytvářet odkazy jeho metodou `link()`.
-Oproti presenterům je tu rozdíl. LinkGenerator vytváří všechny odkazy rovnou jako absolutní URL. A dále neexistuje žádný "aktuální presenter", takže nelze jako cíl uvést jen název akce `link('default')` nebo uvádět relativní cesty k [modulům |modules].
+Oproti presenterům je tu rozdíl. LinkGenerator vytváří všechny odkazy rovnou jako absolutní URL. A dále neexistuje žádný "aktuální presenter", takže nelze jako cíl uvést jen název akce `link('default')` nebo uvádět relativní cesty k modulům.
Neplatné odkazy vždy vyhazují `Nette\Application\UI\InvalidLinkException`.
diff --git a/application/cs/directory-structure.texy b/application/cs/directory-structure.texy
new file mode 100644
index 0000000000..3e3f48918a
--- /dev/null
+++ b/application/cs/directory-structure.texy
@@ -0,0 +1,526 @@
+Adresářová struktura aplikace
+*****************************
+
+Presenters/
-├── Modules/ ← adresář s moduly
-│ ├── Admin/ ← modul Admin
-│ │ ├── Presenters/ ← jeho presentery
-│ │ │ ├── DashboardPresenter.php
-│ │ │ └── templates/
-│ └── Front/ ← modul Front
-│ └── Presenters/ ← jeho presentery
-│ └── ...
-\--
-
-Tuto adresářovou strukturu budou reflektovat jmenné prostory tříd, takže třeba `DashboardPresenter` bude v prostoru `App\Modules\Admin\Presenters`:
-
-```php
-namespace App\Modules\Admin\Presenters;
-
-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.
-
-Moduly mohou kromě presenterů a šablon samozřejmě obsahovat všechny další součásti, jako jsou třeba komponenty, modelové třídy, atd.
-
-
-Vnořené moduly
---------------
-
-Moduly nemusí tvořit jen plochou strukturu, lze vytvářet i submoduly, například:
-
-/--pre
-app/
-├── Modules/ ← adresář s moduly
-│ ├── Blog/ ← modul Blog
-│ │ ├── Admin/ ← submodul Admin
-│ │ │ ├── Presenters/
-│ │ │ └── ...
-│ │ └── 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`.
-
-Zanořování může pokračovat libovolně hluboko, lze tedy vytvářet sub-submoduly.
-
-
-Vytváření odkazů
-----------------
-
-Odkazy v šablonách presenterů jsou relativní vůči aktuálnímu modulu. Tedy odkaz `Foo:default` vede na presenter `Foo` v tomtéž modulu, v jakém je aktuální presenter. Pokud je aktuální modul například `Front`, pak odkaz vede takto:
-
-```latte
-odkaz na Front:Product:show
-```
-
-Odkaz je relativní i pokud je jeho součástí název modulu, ten se pak považuje za submodul:
-
-```latte
-odkaz na Front:Shop:Product:show
-```
-
-Absolutní odkazy zapisujeme analogicky k absolutním cestám na disku, jen místo lomítek jsou dvojtečky. Tedy absolutní odkaz začíná dvojtečkou:
-
-```latte
-odkaz na Admin:Product:show
-```
-
-Pro zjištění, zda jsme v určitém modulu nebo jeho submodulu, použijeme funkci `isModuleCurrent(moduleName)`.
-
-```latte
-
- ...
-
-```
-
-
-Routování
----------
-
-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`.
-
-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í:
-
-```neon
-application:
- mapping:
- *: App\Presenters\*Presenter
-```
-
-Název presenteru se nahradí za hvezdičku v masce třídy a výsledkem je název třídy. Snadné!
-
-Pokud presentery členíme do modulů, můžeme pro každý modul mít vlastní mapování:
-
-```neon
-application:
- mapping:
- Front: App\Modules\Front\Presenters\*Presenter
- Admin: App\Modules\Admin\Presenters\*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`.
-
-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:
-
-```neon
-application:
- mapping:
- *: App\Modules\*\Presenters\*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`.
-
-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]
-```
-
-Výchozí hodnotou je `*: *Module\*Presenter`.
diff --git a/application/cs/multiplier.texy b/application/cs/multiplier.texy
index 864e157001..4bd4c80f76 100644
--- a/application/cs/multiplier.texy
+++ b/application/cs/multiplier.texy
@@ -1,13 +1,15 @@
Multiplier: dynamické komponenty
********************************
-Nástroj na dynamickou tvorbu interaktivních komponent .[perex]
+.[perex]
+Nástroj na dynamickou tvorbu interaktivních komponent
Vyjděme od typického příkladu: mějme seznam zboží v eshopu, přičemž u každého budeme chtít vypsat formulář pro přidání zboží do košíku. Jednou z možných variant je obalit celý výpis do jednoho formuláře. Mnohem pohodlnější způsob nám však nabízí [api:Nette\Application\UI\Multiplier].
Multiplier umožňuje pohodlně definovat továrničku pro více komponent. Funguje na principu vnořených komponent - každá komponenta dědící od [api:Nette\ComponentModel\Container] může obsahovat další komponenty.
-Viz kapitola o [komponentovém modelu|components#komponenty-do-hloubky] v dokumentaci či [přednáška od Honzy Tvrdíka|https://www.youtube.com/watch?v=8y3LLexWu-I]. .[tip]
+.[tip]
+Viz kapitola o [komponentovém modelu |components#Komponenty do hloubky] v dokumentaci či [přednáška od Honzy Tvrdíka|https://www.youtube.com/watch?v=8y3LLexWu-I].
Podstatou Multiplieru je, že vystupuje v pozici rodiče, který si své potomky dokáže vytvářet dynamicky pomocí callbacku předaného v konstruktoru. Viz příklad:
diff --git a/application/cs/presenters.texy b/application/cs/presenters.texy
index be5356e816..04cd942e32 100644
--- a/application/cs/presenters.texy
+++ b/application/cs/presenters.texy
@@ -11,7 +11,7 @@ Seznámíme se s tím, jak se v Nette píší presentery a šablony. Po přečte
-[Už víme |how-it-works#nette-application], že presenter je třída, která představuje nějakou konkrétní stránku webové aplikace, např. homepage; produkt v e-shopu; přihlašovací formulář; sitemap feed atd. Aplikace může mít od jednoho po tisíce presenterů. V jiných frameworcích se jim také říká controllery.
+[Už víme |how-it-works#Nette Application], že presenter je třída, která představuje nějakou konkrétní stránku webové aplikace, např. homepage; produkt v e-shopu; přihlašovací formulář; sitemap feed atd. Aplikace může mít od jednoho po tisíce presenterů. V jiných frameworcích se jim také říká controllery.
Obvykle se pod pojmem presenter myslí potomek třídy [api:Nette\Application\UI\Presenter], který je vhodný pro generování webových rozhraní a kterému se budeme věnovat ve zbytku této kapitoly. V obecném smyslu je presenter jakýkoliv objekt implementující rozhraní [api:Nette\Application\IPresenter].
@@ -56,11 +56,11 @@ Ihned po obdržení požadavku se zavolá metoda `startup()`. Můžete ji využ
`action` nebo snippetu s dalšími HTML atributy docí
```
-Dynamické snippety
-==================
+Oblasti snippetů
+----------------
-Nette také umožňuje používání snippetů, jejichž název se vytvoří až za běhu - tj. dynamicky. Hodí se to pro různé seznamy, kde při změně jednoho řádku nechceme přenášet AJAXem celý seznam, ale stačí onen samotný řádek. Příklad:
+Názvy snippetů mohou být také výrazy:
```latte
-{$item}
+{/foreach}
```
-Zde máme statický snippet `itemsContainer`, obsahující několik dynamických snippetů `item-0`, `item-1` atd.
+Takto nám vznikne několik snippetů `item-0`, `item-1` atd. Pokud bychom přímo invalidovali dynamický snippet (například `item-1`), nepřekreslilo by se nic. Důvod je ten, že snippety opravdu fungují jako výstřižky a vykreslují se jen přímo ony samotné. Jenže v šabloně fakticky žádný snippet pojmenovaný `item-1` není. Ten vznikne až vykonáváním kódu v okolí snippetu, tedy cyklu foreach. Označíme proto část šablony, která se má vykonat pomocí značky `{snippetArea}`:
-Dynamické snippety nelze invalidovat přímo (invalidace `item-1` neudělá vůbec nic), musíte invalidovat jim nadřazený statický snippet (zde snippet `itemsContainer`). Potom dojde k tomu, že se provede celý kód toho kontejneru, ale prohlížeči se pošlou jenom jeho sub-snippety. Pokud chcete, aby prohlížeč dostal pouze jediný z nich, musíte upravit vstup toho kontejneru tak, aby ostatní negeneroval.
+```latte
+
-Díky [obousměrnému routování |routing] nebudete nikdy muset do šablon či kódu zapisovat navrdo URL adresy vaší aplikace, které se mohou později měnit, nebo je komplikovaně skládat. V odkazu stačí uvést presenter a akci, předat případné parametry a framework už URL vygeneruje sám. Vlastně je to velice podobné, jako když voláte funkci. To se vám bude líbit.
+Díky [obousměrnému routování |routing] nebudete nikdy muset do šablon či kódu zapisovat natvrdo URL adresy vaší aplikace, které se mohou později měnit, nebo je komplikovaně skládat. V odkazu stačí uvést presenter a akci, předat případné parametry a framework už URL vygeneruje sám. Vlastně je to velice podobné, jako když voláte funkci. To se vám bude líbit.
V šabloně presenteru
@@ -24,7 +24,7 @@ Nejčastěji vytváříme odkazy v šablonách a skvělým pomocníkem je atribu
detail
```
-Všimněte si, že místo HTML atributu `href` jsme použili [n:atribut |latte:syntax#n-atributy] `n:href`. Jeho hodnotou pak není URL, jak by tomu bylo v případě atributu `href`, ale název presenteru a akce.
+Všimněte si, že místo HTML atributu `href` jsme použili [n:atribut |latte:syntax#n:atributy] `n:href`. Jeho hodnotou pak není URL, jak by tomu bylo v případě atributu `href`, ale název presenteru a akce.
Kliknutí na odkaz je, zjednodušeně řečeno, něco jako zavolání metody `ProductPresenter::renderShow()`. A pokud má ve své signatuře parametry, můžeme ji volat s argumenty:
@@ -38,7 +38,7 @@ Je možné předávat i pojmenované parametry. Následující odkaz předává
detail produktu
```
-Pokud metoda `ProductPresenter::renderShow()` nemá `$lang` ve své signatuře, může si hodnotu parametru zjistit pomocí `$lang = $this->getParameter('lang')`.
+Pokud metoda `ProductPresenter::renderShow()` nemá `$lang` ve své signatuře, může si hodnotu parametru zjistit pomocí `$lang = $this->getParameter('lang')` nebo z [property |presenters#Parametry požadavku].
Pokud jsou parametry uložené v poli, lze je rozvinout operátorem `...` (v Latte 2.x operátorem `(expand)`):
@@ -47,7 +47,7 @@ Pokud jsou parametry uložené v poli, lze je rozvinout operátorem `...` (v Lat
detail produktu
```
-V odkazech se také automaticky předávají tzv. [persistentní parametry|presenters#persistentní parametry].
+V odkazech se také automaticky předávají tzv. [persistentní parametry |presenters#Persistentní parametry].
Atribut `n:href` je velmi šikovný pro HTML značky ``. Chceme-li odkaz vypsat jinde, například v textu, použijeme `{link}`:
@@ -103,14 +103,14 @@ Pokud je cílem akce `default`, můžeme ji vynechat, ale dvojtečka musí zůst
úvodní stránka
```
-Odkazy mohou také směřovat do jiných [modulů |modules]. Zde se odkazy rozlišují na relativní do zanořeného submodulu, nebo absolutní. Princip je analogický k cestám na disku, jen místo lomítek jsou dvojtečky. Předpokládejme, že aktuální presenter je součástí modulu `Front`, potom zapíšeme:
+Odkazy mohou také směřovat do jiných [modulů |directory-structure#Presentery a šablony]. Zde se odkazy rozlišují na relativní do zanořeného submodulu, nebo absolutní. Princip je analogický k cestám na disku, jen místo lomítek jsou dvojtečky. Předpokládejme, že aktuální presenter je součástí modulu `Front`, potom zapíšeme:
```latte
odkaz na Front:Shop:Product:show
odkaz na Admin:Product:show
```
-Speciálním případem je odkaz [na sebe sama|#Odkaz na aktuální stránku], kdy jako cíl uvedeme `this`.
+Speciálním případem je odkaz [na sebe sama |#Odkaz na aktuální stránku], kdy jako cíl uvedeme `this`.
```latte
refresh
@@ -130,6 +130,8 @@ Odkazy generované pomocí `link()` nebo `n:href` jsou vždy absolutní cesty (t
Pro vygenerování absolutní URL přidejte na začátek dvě lomítka (např. `n:href="//Home:"`). Nebo lze přepnout presenter, aby generoval jen absolutní odkazy nastavením `$this->absoluteUrls = true`.
+V šabloně lze také použít filtr `|absoluteUrl`, který relativní cestu převede na absolutní.
+
Odkaz na aktuální stránku
=========================
@@ -140,7 +142,7 @@ Cíl `this` vytvoří odkaz na aktuální stránku:
refresh
```
-Zároveň se přenáší i všechny parametry uvedené v signatuře `render-
- {foreach $list as $id => $item}
-
- {$item} update - {/foreach} -
-
+ {foreach $items as $id => $item}
+
- {$item} + {/foreach} +
-
- {foreach $list as $id => $item}
-
- {$item} update - {/foreach} -
-
-Bootstrap je zaváděcí kód, který inicializuje prostředí, vytvoří dependency injection (DI) kontejner a spustí aplikaci. Řekneme si:
-
-- jak se konfiguruje pomocí NEON souborů
-- jak rozlišit produkční a vývojářský režim
-- jak vytvořit DI kontejner
-
-
-
-
-Aplikace, ať už jde o ty webové nebo skripty spouštěné z příkazové řádky, začínají svůj běh nějakou formou inicializace prostředí. V dávných dobách to míval na starosti soubor s názvem třeba `include.inc.php`, který prvotní soubor inkludoval.
-V moderních Nette aplikacích jej nahradila třída `Bootstrap`, kterou jakožto součást aplikace najdete v souboru `app/Bootstrap.php`. Může vypadat kupříkladu takto:
-
-```php
-use Nette\Bootstrap\Configurator;
-
-class Bootstrap
-{
- public static function boot(): Configurator
- {
- $appDir = dirname(__DIR__);
- $configurator = new Configurator;
- //$configurator->setDebugMode('secret@23.75.345.200');
- $configurator->enableTracy($appDir . '/log');
- $configurator->setTempDirectory($appDir . '/temp');
- $configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
- $configurator->addConfig($appDir . '/config/common.neon');
- return $configurator;
- }
-}
-```
-
-
-index.php
-=========
-
-Prvotní soubor je v případě webových aplikací `index.php`, který se nachází ve veřejném adresáři `www/`. Ten si nechá od třídy Bootstrap inicializovat prostředí a vrátit `$configurator` a následně vyrobí DI kontejner. Poté z něj získá službu `Application`, kterou spustí webovou aplikaci:
-
-```php
-// inicializace prostředí + získání objektu Configurator
-$configurator = App\Bootstrap::boot();
-// vytvoření DI kontejneru
-$container = $configurator->createContainer();
-// DI kontejner vytvoří objekt Nette\Application\Application
-$application = $container->getByType(Nette\Application\Application::class);
-// spuštění Nette aplikace
-$application->run();
-```
-
-Jak vidno, s nastavením prostředí a vytvořením dependency injection (DI) kontejneru pomáhá třída [api:Nette\Bootstrap\Configurator], kterou si nyní blíže představíme.
-
-
-Vývojářský vs produkční režim
-=============================
-
-Nette rozlišuje dva základní režimy, ve kterých se požadavek vykoná: vývojářský a produkční. Vývojářský je zaměřen na maximální pohodlí programátora, zobrazuje se Tracy, automaticky se aktualizuje cache při změně šablon nebo konfigurace DI kontejneru, atd. Produkční je zaměřený na výkon a ostré nasazení, Tracy chyby pouze loguje a změny šablon a dalších souborů se netestují.
-
-Volba režimu se provádí autodetekcí, takže obvykle není potřeba nic konfigurovat nebo ručně přepínat. Režim je vývojářský tehdy, pokud je aplikace spuštěna na localhostu (tj. IP adresa `127.0.0.1` nebo `::1`) a není přitomna proxy (tj. její HTTP hlavička). Jinak běží v produkčním režimu.
-
-Pokud chceme vývojářský režim povolit i v dalších případech, například programátorům přistupujícím z konkrétní IP adresy, použijeme `setDebugMode()`:
-
-```php
-$configurator->setDebugMode('23.75.345.200'); // lze uvést i pole IP adres
-```
-
-Rozhodně doporučujeme kombinovat IP adresu s cookie. Do cookie `nette-debug` uložíme tajný token, např. `secret1234`, a tímto způsobem aktivujeme vývojářský režim pro programátory přistupující z konkrétní IP adresy a zároveň mající v cookie zmíněný token:
-
-```php
-$configurator->setDebugMode('secret1234@23.75.345.200');
-```
-
-Vývojářský režim můžeme také vypnout úplně, i pro localhost:
-
-```php
-$configurator->setDebugMode(false);
-```
-
-Pozor, hodnota `true` zapne vývojářský režim natvrdo, což se nikdy nesmí stát na produkčním serveru.
-
-
-Debugovací nástroj Tracy
-========================
-
-Pro snadné debugování ještě zapneme skvělý nástroj [Tracy |tracy:]. Ve vývojářském režimu chyby vizualizuje a v produkčním režimu chyby loguje do uvedeného adresáře:
-
-```php
-$configurator->enableTracy($appDir . '/log');
-```
-
-
-Dočasné soubory
-===============
-
-Nette využívá cache pro DI kontejner, RobotLoader, šablony atd. Proto je nutné nastavit cestu k adresáři, kam se bude cache ukládat:
-
-```php
-$configurator->setTempDirectory($appDir . '/temp');
-```
-
-Na Linuxu nebo macOS nastavte adresářům `log/` a `temp/` [práva pro zápis |nette:troubleshooting#Nastavení práv adresářů].
-
-
-RobotLoader
-===========
-
-Zpravidla budeme chtít automaticky načítat třídy pomocí [RobotLoaderu |robot-loader:], musíme ho tedy nastartovat a necháme jej načítat třídy z adresáře, kde je umístěný `Bootstrap.php` (tj. `__DIR__`), a všech podadresářů:
-
-```php
-$configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
-```
-
-Alternativní přístup je nechat třídy načítat pouze přes [Composer |best-practices:composer] při dodržení PSR-4.
-
-
-Timezone
-========
-
-Přes konfigurátor můžete nastavit výchozí časovou zónu.
-
-```php
-$configurator->setTimeZone('Europe/Prague');
-```
-
-
-Konfigurace DI kontejneru
-=========================
-
-Součástí bootovacího procesu je vytvoření DI kontejneru neboli továrny na objekty, což je srdce celé aplikace. Jde vlastně o PHP třídu, kterou vygeneruje Nette a uloží do adresáře s cache. Továrna vyrábí klíčové objekty aplikace a pomocí konfiguračních souborů jí instruujeme, jak je má vytvářet a nastavovat, čímž ovlivňujeme chování celé aplikace.
-
-Konfigurační soubory se obvykle zapisují ve formátu [NEON |neon:format]. V samostatné kapitole se dočtete, [co vše lze konfigurovat |nette:configuring].
-
-.[tip]
-Ve vývojářském režimu se kontejner automaticky aktualizuje při každé změně kódu nebo konfiguračních souborů. V produkčním režimu se vygeneruje jen jednou a změny se kvůli maximalizaci výkonu nekontrolují.
-
-Konfigurační soubory načteme pomocí `addConfig()`:
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-```
-
-Pokud chceme přidat více konfiguračních souborů, můžeme funkci `addConfig()` zavolat vícekrát.
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-$configurator->addConfig($appDir . '/config/local.neon');
-if (PHP_SAPI === 'cli') {
- $configurator->addConfig($appDir . '/config/cli.php');
-}
-```
-
-Název `cli.php` není překlep, konfigurace může být zapsaná také v PHP souboru, který ji vrátí jako pole.
-
-Také můžeme přidat další konfigurační soubory v [sekci `includes` |dependency-injection:configuration#Vkládání souborů].
-
-Pokud se v konfiguračních souborech objeví prvky se stejnými klíči, budou přepsány, nebo v případě [polí sloučeny |dependency-injection:configuration#Slučování]. Později vkládaný soubor má vyšší prioritu než předchozí. Soubor, ve kterém je sekce `includes` uvedena, má vyšší prioritu než v něm inkludované soubory.
-
-
-Statické parametry
-------------------
-
-Parametry používané v konfiguračních souborech můžeme definovat [v sekci `parameters`|dependency-injection:configuration#parametry] a také je předávat (či přepisovat) metodou `addStaticParameters()` (má alias `addParameters()`). Důležité je, že různé hodnoty parametrů způsobí vygenerování dalších DI kontejnerů, tedy dalších tříd.
-
-```php
-$configurator->addStaticParameters([
- 'projectId' => 23,
-]);
-```
-
-Na parametr `projectId` se lze v konfiguraci odkázat obvyklým zápisem `%projectId%`. Třída Configurator automaticky přidává parametry `appDir`, `wwwDir`, `tempDir`, `vendorDir`, `debugMode` a `consoleMode`.
-
-
-Dynamické parametry
--------------------
-
-Do kontejneru můžeme přidat i dynamické parametry, jejichž různé hodnoty na rozdíl od statických parameterů nezpůsobí generování nových DI kontejnerů.
-
-```php
-$configurator->addDynamicParameters([
- 'remoteIp' => $_SERVER['REMOTE_ADDR'],
-]);
-```
-
-Jednoduše tak můžeme přidat např. environmentální proměnné, na které se pak lze v konfiguraci odkázat zápisem `%env.variable%`.
-
-```php
-$configurator->addDynamicParameters([
- 'env' => getenv(),
-]);
-```
-
-
-Importované služby
-------------------
-
-Nyní už jdeme hlouběji. Ačkoliv je smyslem DI kontejneru objekty vyrábet, výjimečně může vzniknout potřeba do kontejneru existující objekt vložit. Uděláme to tak, že službu definujeme s příznakem `imported: true`.
-
-```neon
-services:
- myservice:
- type: App\Model\MyCustomService
- imported: true
-```
-
-A v bootstrapu do kontejneru vložíme objekt:
-
-```php
-$configurator->addServices([
- 'myservice' => new App\Model\MyCustomService('foobar'),
-]);
-```
-
-
-Odlišné prostředí
-=================
-
-Nebojte se upravit třídu Bootstrap podle svých potřeb. Metodě `boot()` můžete přidat parametry pro rozlišení webových projektů nebo doplnit další metody, například `bootForTests()`, která inicializuje prostředí pro jednotkové testy, `bootForCli()` pro skripty volané z příkazové řádky atd.
-
-```php
-public static function bootForTests(): Configurator
-{
- $configurator = self::boot();
- Tester\Environment::setup(); // inicializace Nette Testeru
- return $configurator;
-}
-```
diff --git a/application/cs/bootstrapping.texy b/application/cs/bootstrapping.texy
new file mode 100644
index 0000000000..2b4a2dec58
--- /dev/null
+++ b/application/cs/bootstrapping.texy
@@ -0,0 +1,298 @@
+Bootstrapping
+*************
+
+
+
+Bootstrapping je proces inicializace prostředí aplikace, vytvoření kontejneru pro dependency injection (DI) a spuštění aplikace. Budeme probírat:
+
+- jak třída Bootstrap inicializuje prostředí
+- jak jsou aplikace konfigurovány pomocí NEON souborů
+- jak rozlišovat mezi produkčním a vývojářským režimem
+- jak vytvořit a nakonfigurovat DI kontejner
+
+
+
+
+Aplikace, ať už jde o ty webové nebo skripty spouštěné z příkazové řádky, začínají svůj běh nějakou formou inicializace prostředí. V dávných dobách to míval na starosti soubor s názvem třeba `include.inc.php`, který prvotní soubor inkludoval. V moderních Nette aplikacích jej nahradila třída `Bootstrap`, kterou jakožto součást aplikace najdete v souboru `app/Bootstrap.php`. Může vypadat kupříkladu takto:
+
+```php
+use Nette\Bootstrap\Configurator;
+
+class Bootstrap
+{
+ private Configurator $configurator;
+ private string $rootDir;
+
+ public function __construct()
+ {
+ $this->rootDir = dirname(__DIR__);
+ // Konfigurátor je zodpovědný za nastavení prostředí aplikace a služeb.
+ $this->configurator = new Configurator;
+ // Nastaví adresář pro dočasné soubory generované Nette (např. zkompilované šablony)
+ $this->configurator->setTempDirectory($this->rootDir . '/temp');
+ }
+
+ public function bootWebApplication(): Nette\DI\Container
+ {
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+ }
+
+ private function initializeEnvironment(): void
+ {
+ // Nette je chytré a vývojový režim se zapíná automaticky,
+ // nebo jej můžete povolit pro konkrétní IP adresu odkomentováním následujícího řádku:
+ // $this->configurator->setDebugMode('secret@23.75.345.200');
+
+ // Aktivuje Tracy: ultimátní "švýcarský nůž" pro ladění.
+ $this->configurator->enableTracy($this->rootDir . '/log');
+
+ // RobotLoader: automaticky načítá všechny třídy ve zvoleném adresáři
+ $this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+ }
+
+ private function setupContainer(): void
+ {
+ // Načte konfigurační soubory
+ $this->configurator->addConfig($this->rootDir . '/config/common.neon');
+ }
+}
+```
+
+
+index.php
+=========
+
+Prvotní soubor je v případě webových aplikací `index.php`, který se nachází ve [veřejném adresáři |directory-structure#Veřejný adresář www] `www/`. Ten si nechá od třídy Bootstrap inicializovat prostředí a vyrobit DI kontejner. Poté z něj získá službu `Application`, která spustí webovou aplikaci:
+
+```php
+$bootstrap = new App\Bootstrap;
+// Inicializace prostředí + vytvoření DI kontejneru
+$container = $bootstrap->bootWebApplication();
+// DI kontejner vytvoří objekt Nette\Application\Application
+$application = $container->getByType(Nette\Application\Application::class);
+// Spuštění aplikace Nette a zpracování příchozího požadavku
+$application->run();
+```
+
+Jak vidno, s nastavením prostředí a vytvořením dependency injection (DI) kontejneru pomáhá třída [api:Nette\Bootstrap\Configurator], kterou si nyní blíže představíme.
+
+
+Vývojářský vs produkční režim
+=============================
+
+Nette se chová různě podle toho, zda běží na vývojářském nebo produkčním serveru:
+
+🛠️ Vývojářský režim (Development):
+ - Zobrazuje Tracy debugbar s užitečnými informacemi (SQL dotazy, čas vykonání, použitá paměť)
+ - Při chybě zobrazí detailní chybovou stránku s voláním funkcí a obsahem proměnných
+ - Automaticky obnovuje cache při změně Latte šablon, úpravě konfiguračních souborů atd.
+
+
+🚀 Produkční režim (Production):
+ - Nezobrazuje žádné ladící informace, všechny chyby zapisuje do logu
+ - Při chybě zobrazí ErrorPresenter nebo obecnou stránku "Server Error"
+ - Cache se nikdy automaticky neobnovuje!
+ - Optimalizovaný pro rychlost a bezpečnost
+
+
+Volba režimu se provádí autodetekcí, takže obvykle není potřeba nic konfigurovat nebo ručně přepínat:
+
+- vývojářský režim: na localhostu (IP adresa `127.0.0.1` nebo `::1`) pokud není přítomná proxy (tj. její HTTP hlavička)
+- produkční režim: všude jinde
+
+Pokud chceme vývojářský režim povolit i v dalších případech, například programátorům přistupujícím z konkrétní IP adresy, použijeme `setDebugMode()`:
+
+```php
+$this->configurator->setDebugMode('23.75.345.200'); // lze uvést i pole IP adres
+```
+
+Rozhodně doporučujeme kombinovat IP adresu s cookie. Do cookie `nette-debug` uložíme tajný token, např. `secret1234`, a tímto způsobem aktivujeme vývojářský režim pro programátory přistupující z konkrétní IP adresy a zároveň mající v cookie zmíněný token:
+
+```php
+$this->configurator->setDebugMode('secret1234@23.75.345.200');
+```
+
+Vývojářský režim můžeme také vypnout úplně, i pro localhost:
+
+```php
+$this->configurator->setDebugMode(false);
+```
+
+Pozor, hodnota `true` zapne vývojářský režim natvrdo, což se nikdy nesmí stát na produkčním serveru.
+
+
+Debugovací nástroj Tracy
+========================
+
+Pro snadné debugování ještě zapneme skvělý nástroj [Tracy |tracy:]. Ve vývojářském režimu chyby vizualizuje a v produkčním režimu chyby loguje do uvedeného adresáře:
+
+```php
+$this->configurator->enableTracy($this->rootDir . '/log');
+```
+
+
+Dočasné soubory
+===============
+
+Nette využívá cache pro DI kontejner, RobotLoader, šablony atd. Proto je nutné nastavit cestu k adresáři, kam se bude cache ukládat:
+
+```php
+$this->configurator->setTempDirectory($this->rootDir . '/temp');
+```
+
+Na Linuxu nebo macOS nastavte adresářům `log/` a `temp/` [práva pro zápis |nette:troubleshooting#Nastavení práv adresářů].
+
+
+RobotLoader
+===========
+
+Zpravidla budeme chtít automaticky načítat třídy pomocí [RobotLoaderu |robot-loader:], musíme ho tedy nastartovat a necháme jej načítat třídy z adresáře, kde je umístěný `Bootstrap.php` (tj. `__DIR__`), a všech podadresářů:
+
+```php
+$this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+```
+
+Alternativní přístup je nechat třídy načítat pouze přes [Composer |best-practices:composer] při dodržení PSR-4.
+
+
+Timezone
+========
+
+Přes konfigurátor můžete nastavit výchozí časovou zónu.
+
+```php
+$this->configurator->setTimeZone('Europe/Prague');
+```
+
+
+Konfigurace DI kontejneru
+=========================
+
+Součástí bootovacího procesu je vytvoření DI kontejneru neboli továrny na objekty, což je srdce celé aplikace. Jde vlastně o PHP třídu, kterou vygeneruje Nette a uloží do adresáře s cache. Továrna vyrábí klíčové objekty aplikace a pomocí konfiguračních souborů jí instruujeme, jak je má vytvářet a nastavovat, čímž ovlivňujeme chování celé aplikace.
+
+Konfigurační soubory se obvykle zapisují ve formátu [NEON |neon:format]. V samostatné kapitole se dočtete, [co vše lze konfigurovat |nette:configuring].
+
+.[tip]
+Ve vývojářském režimu se kontejner automaticky aktualizuje při každé změně kódu nebo konfiguračních souborů. V produkčním režimu se vygeneruje jen jednou a změny se kvůli maximalizaci výkonu nekontrolují.
+
+Konfigurační soubory načteme pomocí `addConfig()`:
+
+```php
+$this->configurator->addConfig($this->rootDir . '/config/common.neon');
+```
+
+Pokud chceme přidat více konfiguračních souborů, můžeme funkci `addConfig()` zavolat vícekrát.
+
+```php
+$configDir = $this->rootDir . '/config';
+$this->configurator->addConfig($configDir . '/common.neon');
+$this->configurator->addConfig($configDir . '/services.neon');
+if (PHP_SAPI === 'cli') {
+ $this->configurator->addConfig($configDir . '/cli.php');
+}
+```
+
+Název `cli.php` není překlep, konfigurace může být zapsaná také v PHP souboru, který ji vrátí jako pole.
+
+Také můžeme přidat další konfigurační soubory v [sekci `includes` |dependency-injection:configuration#Vkládání souborů].
+
+Pokud se v konfiguračních souborech objeví prvky se stejnými klíči, budou přepsány, nebo v případě [polí sloučeny |dependency-injection:configuration#Slučování]. Později vkládaný soubor má vyšší prioritu než předchozí. Soubor, ve kterém je sekce `includes` uvedena, má vyšší prioritu než v něm inkludované soubory.
+
+
+Statické parametry
+------------------
+
+Parametry používané v konfiguračních souborech můžeme definovat [v sekci `parameters` |dependency-injection:configuration#Parametry] a také je předávat (či přepisovat) metodou `addStaticParameters()` (má alias `addParameters()`). Důležité je, že různé hodnoty parametrů způsobí vygenerování dalších DI kontejnerů, tedy dalších tříd.
+
+```php
+$this->configurator->addStaticParameters([
+ 'projectId' => 23,
+]);
+```
+
+Na parametr `projectId` se lze v konfiguraci odkázat obvyklým zápisem `%projectId%`.
+
+
+Dynamické parametry
+-------------------
+
+Do kontejneru můžeme přidat i dynamické parametry, jejichž různé hodnoty na rozdíl od statických parameterů nezpůsobí generování nových DI kontejnerů.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'remoteIp' => $_SERVER['REMOTE_ADDR'],
+]);
+```
+
+Jednoduše tak můžeme přidat např. environmentální proměnné, na které se pak lze v konfiguraci odkázat zápisem `%env.variable%`.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'env' => getenv(),
+]);
+```
+
+
+Výchozí parametry
+-----------------
+
+V konfiguračních souborech můžete využít tyto statické parametry:
+
+- `%appDir%` je absolutní cesta k adresáři se souborem `Bootstrap.php`
+- `%wwwDir%` je absolutní cesta k adresáři se vstupním souborem `index.php`
+- `%tempDir%` je absolutní cesta k adresáři pro dočasné soubory
+- `%vendorDir%` je absolutní cesta k adresáři, kam Composer instaluje knihovny
+- `%rootDir%` je absolutní cesta ke kořenovému adresáři projektu
+- `%baseUrl%` je absolutní URL ke kořenovému adresáři
+- `%debugMode%` udává, zda je aplikace v debugovacím režimu
+- `%consoleMode%` udává, zda request přišel přes příkazovou řádku
+
+
+Importované služby
+------------------
+
+Nyní už jdeme hlouběji. Ačkoliv je smyslem DI kontejneru objekty vyrábet, výjimečně může vzniknout potřeba do kontejneru existující objekt vložit. Uděláme to tak, že službu definujeme s příznakem `imported: true`.
+
+```neon
+services:
+ myservice:
+ type: App\Model\MyCustomService
+ imported: true
+```
+
+A v bootstrapu do kontejneru vložíme objekt:
+
+```php
+$this->configurator->addServices([
+ 'myservice' => new App\Model\MyCustomService('foobar'),
+]);
+```
+
+
+Odlišné prostředí
+=================
+
+Nebojte se upravit třídu Bootstrap podle svých potřeb. Metodě `bootWebApplication()` můžete přidat parametry pro rozlišení webových projektů. Nebo můžeme doplnit další metody, například `bootTestEnvironment()`, která inicializuje prostředí pro jednotkové testy, `bootConsoleApplication()` pro skripty volané z příkazové řádky atd.
+
+```php
+public function bootTestEnvironment(): Nette\DI\Container
+{
+ Tester\Environment::setup(); // inicializace Nette Testeru
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+
+public function bootConsoleApplication(): Nette\DI\Container
+{
+ $this->configurator->setDebugMode(false);
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+```
diff --git a/application/cs/components.texy b/application/cs/components.texy
index b9a22c0f5e..7d433ab890 100644
--- a/application/cs/components.texy
+++ b/application/cs/components.texy
@@ -87,7 +87,7 @@ class PollControl extends Control
Vykreslení
==========
-Už víme, že k vykreslení komponenty se používá značka `{control componentName}`. Ta vlastně zavolá metodu `render()` komponenty, ve které se postáráme o vykreslení. K dispozici máme, úplně stejně jako v presenteru, [Latte|latte:] šablonu v proměnné `$this->template`, do které předáme parametry. Na rozdíl od presenteru musíme uvést soubor se šablonou a nechat ji vykreslit:
+Už víme, že k vykreslení komponenty se používá značka `{control componentName}`. Ta vlastně zavolá metodu `render()` komponenty, ve které se postáráme o vykreslení. K dispozici máme, úplně stejně jako v presenteru, [Latte šablonu|templates] v proměnné `$this->template`, do které předáme parametry. Na rozdíl od presenteru musíme uvést soubor se šablonou a nechat ji vykreslit:
```php .{file:PollControl.php}
public function render(): void
@@ -175,7 +175,7 @@ Komponenty, stejně jako presentery, předávají do šablon několik užitečn
- `$user` je objekt [reprezentující uživatele |security:authentication]
- `$presenter` je aktuální presenter
- `$control` je aktuální komponenta
-- `$flashes` pole [zpráv |#flash zprávy] zaslaných funkcí `flashMessage()`
+- `$flashes` pole [zpráv |#Flash zprávy] zaslaných funkcí `flashMessage()`
Signál
@@ -192,13 +192,13 @@ public function handleClick(int $x, int $y): void
}
```
-Odkaz, který zavolá signál, vytvoříme obvyklým způsobem, tedy v šabloně atributem `n:href` nebo značkou `{link}`, v kódu metodou `link()`. Více v kapitole [Vytváření odkazů URL|creating-links#Odkazy na signál].
+Odkaz, který zavolá signál, vytvoříme obvyklým způsobem, tedy v šabloně atributem `n:href` nebo značkou `{link}`, v kódu metodou `link()`. Více v kapitole [Vytváření odkazů URL |creating-links#Odkazy na signál].
```latte
click here
```
-Signál se vždy volá na aktuálním presenteru a view, tudíž není možné jej vyvolat na jiném presenteru nebo view.
+Signál se vždy volá na aktuálním presenteru a action, není možné jej vyvolat na jiném presenteru nebo jiné action.
Signál tedy způsobí znovunačtení stránky úplně stejně jako při původním požadavku, jen navíc zavolá obslužnou metodu signálu s příslušnými parametry. Pokud metoda neexistuje, vyhodí se výjimka [api:Nette\Application\UI\BadSignalException], která se uživateli zobrazí jako chybová stránka 403 Forbidden.
@@ -230,6 +230,28 @@ $this->redirect(/* ... */); // a přesměrujeme
```
+Přesměrování po signálu
+=======================
+
+Po zpracování signálu komponenty často následuje přesměrování. Je to podobná situace jako u formulářů - po jejich odeslání také přesměrováváme, aby při obnovení stránky v prohlížeči nedošlo k opětovnému odeslání dat.
+
+```php
+$this->redirect('this') // přesměruje na aktuální presenter a action
+```
+
+Protože komponenta je znovupoužitelný prvek a obvykle by neměla mít přímou vazbu na konkrétní presentery, metody `redirect()` a `link()` automaticky interpretují parametr jako signál komponenty:
+
+```php
+$this->redirect('click') // přesměruje na signál 'click' téže komponenty
+```
+
+Pokud potřebujete přesměrovat na jiný presenter či akci, můžete to udělat prostřednictvím presenteru:
+
+```php
+$this->getPresenter()->redirect('Product:show'); // přesměruje na jiný presenter/action
+```
+
+
Persistentní parametry
======================
@@ -310,7 +332,7 @@ class PollControl extends Control
public function handleVote(int $voteId): void
{
- $this->facade->vote($id, $voteId);
+ $this->facade->vote($this->id, $voteId);
// ...
}
}
@@ -347,7 +369,7 @@ services:
a nakonec ji použijeme v našem presenteru:
```php
-class PollPresenter extends Nette\UI\Application\Presenter
+class PollPresenter extends Nette\Application\UI\Presenter
{
public function __construct(
private PollControlFactory $pollControlFactory,
@@ -380,12 +402,12 @@ Komponenty do hloubky
Komponenty v Nette Application představují znovupoužitelné součásti webové aplikace, které vkládáme do stránek a kterým se ostatně věnuje celá tato kapitola. Jaké přesně schopnosti taková komponenta má?
1) je vykreslitelná v šabloně
-2) ví, kterou svou část má vykreslit při [AJAXovém požadavku |ajax#invalidace] (snippety)
+2) ví, [kterou svou část |ajax#Snippety] má vykreslit při AJAXovém požadavku (snippety)
3) má schopnost ukládat svůj stav do URL (persistentní parametry)
4) má schopnost reagovat na uživatelské akce (signály)
5) vytváří hierarchickou strukturu (kde kořenem je presenter)
-Každou z těchto funkcí obstarává některá z tříd dědičné linie. Vykreslování (1 + 2) má na starosti [api:Nette\Application\UI\Control], začlenění do [životního cyklu |presenters#zivotni-cyklus-presenteru] (3, 4) třída [api:Nette\Application\UI\Component] a vytváření hierachické struktury (5) třídy [Container a Component |component-model:].
+Každou z těchto funkcí obstarává některá z tříd dědičné linie. Vykreslování (1 + 2) má na starosti [api:Nette\Application\UI\Control], začlenění do [životního cyklu |presenters#Životní cyklus presenteru] (3, 4) třída [api:Nette\Application\UI\Component] a vytváření hierachické struktury (5) třídy [Container a Component |component-model:].
```
Nette\ComponentModel\Component { IComponent }
@@ -400,10 +422,10 @@ Nette\ComponentModel\Component { IComponent }
```
-Životní cyklus componenty
+Životní cyklus komponenty
-------------------------
-[* lifecycle-component.svg *] *** *Životní cyklus componenty* .<>
+[* lifecycle-component.svg *] *** *Životní cyklus komponenty* .<>
Validace persistentních parametrů
@@ -430,7 +452,7 @@ class PaginatingControl extends Control
}
```
-Opačný proces, tedy sesbírání hodnot z persistentních properites, má na starosti metoda `saveState()`.
+Opačný proces, tedy sesbírání hodnot z persistentních properties, má na starosti metoda `saveState()`.
Signály do hloubky
@@ -444,7 +466,7 @@ Signál může přijímat jakákoliv komponenta, presenter nebo objekt, který i
Mezi hlavní příjemce signálů budou patřit `Presentery` a vizuální komponenty dědící od `Control`. Signál má sloužit jako znamení pro objekt, že má něco udělat – anketa si má započítat hlas od uživatele, blok s novinkami se má rozbalit a zobrazit dvakrát tolik novinek, formulář byl odeslán a má zpracovat data a podobně.
-URL pro signál vytváříme pomocí metody [Component::link() |api:Nette\Application\UI\Component::link()]. Jako parametr `$destination` předáme řetězec `{signal}!` a jako `$args` pole argumentů, které chceme signálu předat. Signál se vždy volá na aktuální view s aktuálními parametry, parametry signálu se jen přidají. Navíc se přidává hned na začátku **parametr `?do`, který určuje signál**.
+URL pro signál vytváříme pomocí metody [Component::link() |api:Nette\Application\UI\Component::link()]. Jako parametr `$destination` předáme řetězec `{signal}!` a jako `$args` pole argumentů, které chceme signálu předat. Signál se vždy volá na aktuálním presenteru a action s aktuálními parametry, parametry signálu se jen přidají. Navíc se přidává hned na začátku **parametr `?do`, který určuje signál**.
Jeho formát je buď `{signal}`, nebo `{signalReceiver}-{signal}`. `{signalReceiver}` je název komponenty v presenteru. Proto nemůže být v názvu komponenty pomlčka – používá se k oddělení názvu komponenty a signálu, je ovšem možné takto zanořit několik komponent.
@@ -461,16 +483,3 @@ if ($this->isSignalReceiver($this, 'paging') || $this->isSignalReceiver($this, '
```
Tím je signál provedený předčasně a už se nebude znovu volat.
-
-
-/--comment
- /** @var callable[]&(callable(Component $sender): void)[]; Occurs when component is attached to presenter */
- public $onAnchor;
-
- /**
- * Returns destination as Link object.
- * @param string $destination in format "[homepage] [[[module:]presenter:]action | signal! | this] [#fragment]"
- * @param array|mixed $args
- */
- public function lazyLink(string $destination, $args = []): Link
-\--
diff --git a/application/cs/configuration.texy b/application/cs/configuration.texy
index fe28676b92..b105f5154e 100644
--- a/application/cs/configuration.texy
+++ b/application/cs/configuration.texy
@@ -14,10 +14,14 @@ application:
debugger: ... # (bool) výchozí je true
# bude se při chybě volat error-presenter?
- catchExceptions: ... # (bool) výchozí je true v produkčním režimu
+ # má efekt pouze ve vývojářském režimu
+ catchExceptions: ... # (bool) výchozí je true
# název error-presenteru
- errorPresenter: Error # (string) výchozí je 'Nette:Error'
+ errorPresenter: Error # (string|array) výchozí je 'Nette:Error'
+
+ # definuje aliasy pro presentery a akce
+ aliases: ...
# definuje pravidla pro překlad názvu presenteru na třídu
mapping: ...
@@ -27,11 +31,20 @@ application:
silentLinks: ... # (bool) výchozí je false
```
-Protože ve vývojovém režimu se error-presentery standardně nevolají a chybu zobrazí až Tracy, změnou hodnoty `catchExceptions` na `true` můžeme při vývoji ověřit jejich správnou funkčnost.
+Od `nette/application` verze 3.2 lze definovat dvojici error-presenterů:
+
+```neon
+application:
+ errorPresenter:
+ 4xx: Error4xx # pro výjimku Nette\Application\BadRequestException
+ 5xx: Error5xx # pro ostatní výjimky
+```
+
+Volba `silentLinks` určuje, jak se Nette zachová ve vývojářském režimu, když selže generování odkazu (třeba proto, že neexistuje presenter, atd). Výchozí hodnota `false` znamená, že Nette vyhodí `E_USER_WARNING` chybu. Nastavením na `true` dojde k potlačení této chybové hlášky. V produkčním prostředí se `E_USER_WARNING` vyvolá vždy. Toto chování můžeme také ovlivnit nastavením proměnné presenteru [$invalidLinkMode |creating-links#Neplatné odkazy].
-Volba `silentLinks` určuje, jak se Nette zachová ve vývojářském režimu, když selže generování odkazu (třeba proto, že neexistuje presenter, atd). Výchozí hodnota `false` znamená, že Nette vyhodí `E_USER_WARNING` chybu. Nastavením na `true` dojde k potlačení této chybové hlášky. V produkčním prostředí se `E_USER_WARNING` vyvolá vždy. Toto chování můžeme také ovlivnit nastavením proměnné presenteru [$invalidLinkMode|creating-links#neplatne-odkazy].
+[Aliasy zjednodušují odkazování |creating-links#Aliasy] na často používané presentery.
-[Mapování definuje pravidla |modules#mapování], podle kterých se z názvu presenteru odvodí název třídy.
+[Mapování definuje pravidla |directory-structure#Mapování presenterů], podle kterých se z názvu presenteru odvodí název třídy.
Automatická registrace presenterů
@@ -76,16 +89,25 @@ latte:
# generuje šablony s hlavičkou declare(strict_types=1)
strictTypes: ... # (bool) výchozí je false
+ # zapne režim [striktního parseru |latte:develop#striktní režim]
+ strictParsing: ... # (bool) výchozí je false
+
+ # aktivuje [kontrolu vygenerovaného kódu |latte:develop#Kontrola vygenerovaného kódu]
+ phpLinter: ... # (string) výchozí je null
+
+ # nastaví locale
+ locale: cs_CZ # (string) výchozí je null
+
# třída objektu $this->template
templateClass: App\MyTemplateClass # výchozí je Nette\Bridges\ApplicationLatte\DefaultTemplate
```
-Pokud používáte Latte verze 3, můžete přidávat nové [rozšíření |latte:creating-extension] pomocí:
+Pokud používáte Latte verze 3, můžete přidávat nové [rozšíření |latte:extending-latte#Latte Extension] pomocí:
```neon
latte:
extensions:
- - Latte\Essential\TranslatorExtension
+ - Latte\Essential\TranslatorExtension(@Nette\Localization\Translator)
```
Pokud používáte Latte verze 2, můžete registrovat nové tagy (makra) buď uvedením jména třídy, nebo referencí na službu. Jako výchozí je zavolána metoda `install()`, ale to lze změnit tím, že uvedeme jméno jiné metody:
@@ -152,3 +174,18 @@ Nastavení direktiv PHP. Přehled všech direktiv naleznete na [php.net |https:/
php:
date.timezone: Europe/Prague
```
+
+
+Služby DI
+=========
+
+Tyto služby se přidávají do DI kontejneru:
+
+| Název | Typ | Popis
+|----------------------------------------------------------
+| `application.application` | [api:Nette\Application\Application] | [spouštěč celé aplikace |how-it-works#Nette Application]
+| `application.linkGenerator` | [api:Nette\Application\LinkGenerator] | [LinkGenerator |creating-links#LinkGenerator]
+| `application.presenterFactory` | [api:Nette\Application\PresenterFactory] | továrna na presentery
+| `application.###` | [api:Nette\Application\UI\Presenter] | jednotlivé presentery
+| `latte.latteFactory` | [api:Nette\Bridges\ApplicationLatte\LatteFactory] | továrna objektu `Latte\Engine`
+| `latte.templateFactory` | [api:Nette\Application\UI\TemplateFactory] | továrna pro [`$this->template` |templates]
diff --git a/application/cs/creating-links.texy b/application/cs/creating-links.texy
index a21c986098..8658cb3646 100644
--- a/application/cs/creating-links.texy
+++ b/application/cs/creating-links.texy
@@ -12,7 +12,7 @@ Tvořit odkazy v Nette je jednoduché, jako ukazovat prstem. Stačí jen namíř
+
+Jak navrhnout přehlednou a škálovatelnou adresářovou strukturu pro projekty v Nette Framework? Ukážeme si osvědčené postupy, které vám pomohou s organizací kódu. Dozvíte se:
+
+- jak **logicky rozčlenit** aplikaci do adresářů
+- jak strukturu navrhnout tak, aby **dobře škálovala** s růstem projektu
+- jaké jsou **možné alternativy** a jejich výhody či nevýhody
+
+
+
+
+Důležité je zmínit, že Nette Framework samotný na žádné konkrétní struktuře nelpí. Je navržen tak, aby se dal snadno přizpůsobit jakýmkoliv potřebám a preferencím.
+
+
+Základní struktura projektu
+===========================
+
+Přestože Nette Framework nediktuje žádnou pevnou adresářovou strukturu, existuje osvědčené výchozí uspořádání v podobě [Web Project|https://github.com/nette/web-project]:
+
+/--pre
+web-project/
+├── app/ ← adresář s aplikací
+├── assets/ ← soubory SCSS, JS, obrázky..., alternativně resources/
+├── bin/ ← skripty pro příkazovou řádku
+├── config/ ← konfigurace
+├── log/ ← logované chyby
+├── temp/ ← dočasné soubory, cache
+├── tests/ ← testy
+├── vendor/ ← knihovny instalované Composerem
+└── www/ ← veřejný adresář (document-root)
+\--
+
+Tuto strukturu můžete libovolně upravovat podle svých potřeb - složky přejmenovat či přesouvat. Poté stačí pouze upravit relativní cesty k adresářům v souboru `Bootstrap.php` a případně `composer.json`. Nic víc není potřeba, žádná složitá rekonfigurace, žádné změny konstant. Nette disponuje chytrou autodetekcí a automaticky rozpozná umístění aplikace včetně její URL základny.
+
+
+Principy organizace kódu
+========================
+
+Když poprví prozkoumáváte nový projekt, měli byste se v něm rychle zorientovat. Představte si, že rozkliknete adresář `app/Model/` a uvidíte tuto strukturu:
+
+/--pre
+app/Model/
+├── Services/
+├── Repositories/
+└── Entities/
+\--
+
+Z ní vyčtete jen to, že projekt používá nějaké služby, repozitáře a entity. O skutečném účelu aplikace se nedozvíte vůbec nic.
+
+Podívejme se na jiný přístup - **organizaci podle domén**:
+
+/--pre
+app/Model/
+├── Cart/
+├── Payment/
+├── Order/
+└── Product/
+\--
+
+Tady je to jiné - na první pohled je jasné, že jde o e-shop. Už samotné názvy adresářů prozrazují, co aplikace umí - pracuje s platbami, objednávkami a produkty.
+
+První přístup (organizace podle typu tříd) přináší v praxi řadu problémů: kód, který spolu logicky souvisí, je roztříštěný do různých složek a musíte mezi nimi přeskakovat. Proto budeme organizovat podle domén.
+
+
+Jmenné prostory
+---------------
+
+Je zvykem, že adresářová struktura koresponduje se jmennými prostory v aplikaci. To znamená, že fyzické umístění souborů odpovídá jejich namespace. Například třída umístěná v `app/Model/Product/ProductRepository.php` by měla mít namespace `App\Model\Product`. Tento princip pomáhá v orientaci v kódu a zjednodušuje autoloading.
+
+
+Jednotné vs množné číslo v názvech
+----------------------------------
+
+Všimněte si, že u hlavních adresářů aplikace používáme jednotné číslo: `app`, `config`, `log`, `temp`, `www`. Stejně tak i uvnitř aplikace: `Model`, `Core`, `Presentation`. Je to proto, že každý z nich představuje jeden ucelený koncept.
+
+Podobně třeba `app/Model/Product` reprezentuje vše kolem produktů. Nenazveme to `Products`, protože nejde o složku plnou produktů (to by tam byly soubory `nokia.php`, `samsung.php`). Je to namespace obsahující třídy pro práci s produkty - `ProductRepository.php`, `ProductService.php`.
+
+Složka `app/Tasks` je v množném čísle proto, že obsahuje sadu samostatných spustitelných skriptů - `CleanupTask.php`, `ImportTask.php`. Každý z nich je samostatnou jednotkou.
+
+Pro konzistenci doporučujeme používat:
+- Jednotné číslo pro namespace reprezentující funkční celek (byť pracující s více entitami)
+- Množné číslo pro kolekce samostatných jednotek
+- V případě nejistoty nebo pokud nad tím nechcete přemýšlet, zvolte jednotné číslo
+
+
+Veřejný adresář `www/`
+======================
+
+Tento adresář je jediný přístupný z webu (tzv. document-root). Často se můžete setkat i s názvem `public/` místo `www/` - je to jen otázka konvence a na funkčnost rostlináře to nemá vliv. Adresář obsahuje:
+- [Vstupní bod |bootstrapping#index.php] aplikace `index.php`
+- Soubor `.htaccess` s pravidly pro mod_rewrite (u Apache)
+- Statické soubory (CSS, JavaScript, obrázky)
+- Uploadované soubory
+
+Pro správné zabezpečení aplikace je zásadní mít správně [nakonfigurovaný document-root |nette:troubleshooting#Jak změnit či ostranit z URL adresář www].
+
+.[note]
+Nikdy neumisťujte do tohoto adresáře složku `node_modules/` - obsahuje tisíce souborů, které mohou být spustitelné a neměly by být veřejně dostupné.
+
+
+Aplikační adresář `app/`
+========================
+
+Toto je hlavní adresář s aplikačním kódem. Základní struktura:
+
+/--pre
+app/
+├── Core/ ← infrastrukturní záležitosti
+├── Model/ ← business logika
+├── Presentation/ ← presentery a šablony
+├── Tasks/ ← příkazové skripty
+└── Bootstrap.php ← zaváděcí třída aplikace
+\--
+
+`Bootstrap.php` je [startovací třída aplikace|bootstrapping], která inicializuje prostředí, načítá konfiguraci a vytváří DI kontejner.
+
+Pojďme se nyní podívat na jednotlivé podadresáře podrobněji.
+
+
+Presentery a šablony
+====================
+
+Prezentační část aplikace máme v adresáři `app/Presentation`. Alternativou je krátké `app/UI`. Je to místo pro všechny presentery, jejich šablony a případné pomocné třídy.
+
+Tuto vrstvu organizujeme podle domén. V komplexním projektu, který kombinuje e-shop, blog a API, by struktura vypadala takto:
+
+/--pre
+app/Presentation/
+├── Shop/ ← e-shop frontend
+│ ├── Product/
+│ ├── Cart/
+│ └── Order/
+├── Blog/ ← blog
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← administrace
+│ ├── Dashboard/
+│ └── Products/
+└── Api/ ← API endpointy
+ └── V1/
+\--
+
+Naopak u jednoduchého blogu bychom použili členění:
+
+/--pre
+app/Presentation/
+├── Front/ ← frontend webu
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← administrace
+│ ├── Dashboard/
+│ └── Posts/
+├── Error/
+└── Export/ ← RSS, sitemapy atd.
+\--
+
+Složky jako `Home/` nebo `Dashboard/` obsahují presentery a šablony. Složky jako `Front/`, `Admin/` nebo `Api/` nazýváme **moduly**. Technicky jde o běžné adresáře, které slouží k logickému členění aplikace.
+
+Každá složka s presenterem obsahuje stejně pojmenovaný presenter a jeho šablony. Například složka `Dashboard/` obsahuje:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← presenter
+└── default.latte ← šablona
+\--
+
+Tato adresářová struktura se odráží ve jmenných prostorech tříd. Například `DashboardPresenter` se nachází ve jmenném prostoru `App\Presentation\Admin\Dashboard` (viz [#mapování presenterů]):
+
+```php
+namespace App\Presentation\Admin\Dashboard;
+
+class DashboardPresenter extends Nette\Application\UI\Presenter
+{
+ // ...
+}
+```
+
+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`. V případě zanořených modulů používáme více dvojteček, například `Shop:Order:Detail:default`.
+
+
+Flexibilní vývoj struktury
+--------------------------
+
+Jednou z velkých výhod této struktury je, jak elegantně se přizpůsobuje rostoucím potřebám projektu. Jako příklad si vezměme část generující XML feedy. Na začátku máme jednoduchou podobu:
+
+/--pre
+Export/
+├── ExportPresenter.php ← jeden presenter pro všechny exporty
+├── sitemap.latte ← šablona pro sitemapu
+└── feed.latte ← šablona pro RSS feed
+\--
+
+Časem přibydou další typy feedů a potřebujeme pro ně více logiky... Žádný problém! Složka `Export/` se jednoduše stane modulem:
+
+/--pre
+Export/
+├── Sitemap/
+│ ├── SitemapPresenter.php
+│ └── sitemap.latte
+└── Feed/
+ ├── FeedPresenter.php
+ ├── zbozi.latte ← feed pro Zboží.cz
+ └── heureka.latte ← feed pro Heureka.cz
+\--
+
+Tato transformace je naprosto plynulá - stačí vytvořit nové podsložky, rozdělit do nich kód a aktualizovat odkazy (např. z `Export:feed` na `Export:Feed:zbozi`). Díky tomu můžeme strukturu postupně rozšiřovat podle potřeby, úroveň zanoření není nijak omezena.
+
+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 v tomto místě vytvořit modul (složku) `Order`, ve kterém budou (složky pro) presentery `Detail`, `Edit`, `Dispatch` a další.
+
+
+Umístění šablon
+---------------
+
+V předchozích ukázkách jsme viděli, že šablony jsou umístěny přímo ve složce s presenterem:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← presenter
+├── DashboardTemplate.php ← volitelná třída pro šablonu
+└── default.latte ← šablona
+\--
+
+Toto umístění se v praxi ukazuje jako nejpohodlnější - všechny související soubory máte hned po ruce.
+
+Alternativně můžete šablony umístit do podsložky `templates/`. Nette podporuje obě varianty. Dokonce můžete šablony umístit i úplně mimo `Presentation/` složku. Vše o možnostech umístění šablon najdete v kapitole [Hledání šablon |templates#Hledání šablon].
+
+
+Pomocné třídy a komponenty
+--------------------------
+
+K prezenterům a šablonám často patří i další pomocné soubory. Umístíme je logicky podle jejich působnosti:
+
+1. **Přímo u presenteru** v případě specifických komponent pro daný presenter:
+
+/--pre
+Product/
+├── ProductPresenter.php
+├── ProductGrid.php ← komponenta pro výpis produktů
+└── FilterForm.php ← formulář pro filtrování
+\--
+
+2. **Pro modul** - doporučujeme využít složku `Accessory`, která se umístí přehledně hned na začátku abecedy:
+
+/--pre
+Front/
+├── Accessory/
+│ ├── NavbarControl.php ← komponenty pro frontend
+│ └── TemplateFilters.php
+├── Product/
+└── Cart/
+\--
+
+3. **Pro celou aplikaci** - v `Presentation/Accessory/`:
+/--pre
+app/Presentation/
+├── Accessory/
+│ ├── LatteExtension.php
+│ └── TemplateFilters.php
+├── Front/
+└── Admin/
+\--
+
+Nebo můžete pomocné třídy jako `LatteExtension.php` nebo `TemplateFilters.php` umístit do infrastrukturní složky `app/Core/Latte/`. A komponenty do `app/Components`. Volba závisí na zvyklostech týmu.
+
+
+Model - srdce aplikace
+======================
+
+Model obsahuje veškerou business logiku aplikace. Pro jeho organizaci platí opět pravidlo - strukturujeme podle domén:
+
+/--pre
+app/Model/
+├── Payment/ ← vše kolem plateb
+│ ├── PaymentFacade.php ← hlavní vstupní bod
+│ ├── PaymentRepository.php
+│ ├── Payment.php ← entita
+├── Order/ ← vše kolem objednávek
+│ ├── OrderFacade.php
+│ ├── OrderRepository.php
+│ ├── Order.php
+└── Shipping/ ← vše kolem dopravy
+\--
+
+V modelu se typicky setkáte s těmito typy tříd:
+
+**Fasády**: představují hlavní vstupní bod do konkrétní domény v aplikaci. Působí jako orchestrátor, který koordinuje spolupráci mezi různými službami za účelem implementace kompletních use-cases (jako "vytvoř objednávku" nebo "zpracuj platbu"). Pod svojí orchestrační vrstvou fasáda skrývá implementační detaily před zbytkem aplikace, čímž poskytuje čisté rozhraní pro práci s danou doménou.
+
+```php
+class OrderFacade
+{
+ public function createOrder(Cart $cart): Order
+ {
+ // validace
+ // vytvoření objednávky
+ // odeslání e-mailu
+ // zapsání do statistik
+ }
+}
+```
+
+**Služby**: zaměřují se na specifickou business operaci v rámci domény. Na rozdíl od fasády, která orchestruje celé use-cases, služba implementuje konkrétní byznys logiku (jako výpočty cen nebo zpracování plateb). Služby jsou typicky bezstavové a mohou být použity buď fasádami jako stavební bloky pro komplexnější operace, nebo přímo jinými částmi aplikace pro jednodušší úkony.
+
+```php
+class PricingService
+{
+ public function calculateTotal(Order $order): Money
+ {
+ // výpočet ceny
+ }
+}
+```
+
+**Repozitáře**: zajišťují veškerou komunikaci s datovým úložištěm, typicky databází. Jeho úkolem je načítání a ukládání entit a implementace metod pro jejich vyhledávání. Repozitář odstiňuje zbytek aplikace od implementačních detailů databáze a poskytuje objektově orientované rozhraní pro práci s daty.
+
+```php
+class OrderRepository
+{
+ public function find(int $id): ?Order
+ {
+ }
+
+ public function findByCustomer(int $customerId): array
+ {
+ }
+}
+```
+
+**Entity**: objekty reprezentující hlavní byznys koncepty v aplikaci, které mají svou identitu a mění se v čase. Typicky jde o třídy mapované na databázové tabulky pomocí ORM (jako Nette Database Explorer nebo Doctrine). Entity mohou obsahovat business pravidla týkající se jejich dat a validační logiku.
+
+```php
+// Entita mapovaná na databázovou tabulku orders
+class Order extends Nette\Database\Table\ActiveRow
+{
+ public function addItem(Product $product, int $quantity): void
+ {
+ $this->related('order_items')->insert([
+ 'product_id' => $product->id,
+ 'quantity' => $quantity,
+ 'unit_price' => $product->price,
+ ]);
+ }
+}
+```
+
+**Value objekty**: neměnné objekty reprezentující hodnoty bez vlastní identity - například peněžní částka nebo e-mailová adresa. Dvě instance value objektu se stejnými hodnotami jsou považovány za identické.
+
+
+Infrastrukturní kód
+===================
+
+Složka `Core/` (nebo také `Infrastructure/`) je domovem pro technický základ aplikace. Infrastrukturní kód typicky zahrnuje:
+
+/--pre
+app/Core/
+├── Router/ ← routování a URL management
+│ └── RouterFactory.php
+├── Security/ ← autentizace a autorizace
+│ ├── Authenticator.php
+│ └── Authorizator.php
+├── Logging/ ← logování a monitoring
+│ ├── SentryLogger.php
+│ └── FileLogger.php
+├── Cache/ ← cachovací vrstva
+│ └── FullPageCache.php
+└── Integration/ ← integrace s ext. službami
+ ├── Slack/
+ └── Stripe/
+\--
+
+U menších projektů pochopitelně stačí ploché členění:
+
+/--pre
+Core/
+├── RouterFactory.php
+├── Authenticator.php
+└── QueueMailer.php
+\--
+
+Jde o kód, který:
+
+- Řeší technickou infrastrukturu (routování, logování, cachování)
+- Integruje externí služby (Sentry, Elasticsearch, Redis)
+- Poskytuje základní služby pro celou aplikaci (mail, databáze)
+- Je většinou nezávislý na konkrétní doméně - cache nebo logger funguje stejně pro eshop či blog.
+
+Tápete, jestli určitá třída patří sem, nebo do modelu? Klíčový rozdíl je v tom, že kód v `Core/`:
+
+- Neví nic o doméně (produkty, objednávky, články)
+- Je většinou možné ho přenést do jiného projektu
+- Řeší "jak to funguje" (jak poslat mail), nikoliv "co to dělá" (jaký mail poslat)
+
+Příklad pro lepší pochopení:
+
+- `App\Core\MailerFactory` - vytváří instance třídy pro odesílání e-mailů, řeší SMTP nastavení
+- `App\Model\OrderMailer` - používá `MailerFactory` k odesílání e-mailů o objednávkách, zná jejich šablony a ví, kdy se mají poslat
+
+
+Příkazové skripty
+=================
+
+Aplikace často potřebují vykonávat činnosti mimo běžné HTTP požadavky - ať už jde o zpracování dat v pozadí, údržbu, nebo periodické úlohy. Pro spouštění slouží jednoduché skripty v adresáři `bin/`, samotnou implementační logiku pak umisťujeme do `app/Tasks/` (případně `app/Commands/`).
+
+Příklad:
+
+/--pre
+app/Tasks/
+├── Maintenance/ ← údržbové skripty
+│ ├── CleanupCommand.php ← mazání starých dat
+│ └── DbOptimizeCommand.php ← optimalizace databáze
+├── Integration/ ← integrace s externími systémy
+│ ├── ImportProducts.php ← import z dodavatelského systému
+│ └── SyncOrders.php ← synchronizace objednávek
+└── Scheduled/ ← pravidelné úlohy
+ ├── NewsletterCommand.php ← rozesílání newsletterů
+ └── ReminderCommand.php ← notifikace zákazníkům
+\--
+
+Co patří do modelu a co do příkazových skriptů? Například logika pro odeslání jednoho e-mailu je součástí modelu, hromadná rozesílka tisíců e-mailů už patří do `Tasks/`.
+
+Úlohy obvykle [spouštíme z příkazového řádku |https://blog.nette.org/cs/cli-skripty-v-nette-aplikaci] nebo přes cron. Lze je spouštět i přes HTTP požadavek, ale je nutné myslet na bezpečnost. Presenter, který úlohu spustí, je potřeba zabezpečit, například jen pro přihlášené uživatele nebo silným tokenem a přístupem z povolených IP adres. U dlouhých úloh je nutné zvýšit časový limit skriptu a použít `session_write_close()`, aby se nezamykala session.
+
+
+Další možné adresáře
+====================
+
+Kromě zmíněných základních adresářů můžete podle potřeb projektu přidat další specializované složky. Podívejme se na nejčastější z nich a jejich použití:
+
+/--pre
+app/
+├── Api/ ← logika pro API nezávislá na prezentační vrstvě
+├── Database/ ← migrační skripty a seedery pro testovací data
+├── Components/ ← sdílené vizuální komponenty napříč celou aplikací
+├── Event/ ← užitečné pokud používáte event-driven architekturu
+├── Mail/ ← e-mailové šablony a související logika
+└── Utils/ ← pomocné třídy
+\--
+
+Pro sdílené vizuální komponenty používané v presenterech napříč aplikací lze použít složku `app/Components` nebo `app/Controls`:
+
+/--pre
+app/Components/
+├── Form/ ← sdílené formulářové komponenty
+│ ├── SignInForm.php
+│ └── UserForm.php
+├── Grid/ ← komponenty pro výpisy dat
+│ └── DataGrid.php
+└── Navigation/ ← navigační prvky
+ ├── Breadcrumbs.php
+ └── Menu.php
+\--
+
+Sem patří komponenty, které mají komplexnější logiku. Pokud chcete komponenty sdílet mezi více projekty, je vhodné je vyčlenit do samostatného composer balíčku.
+
+Do adresáře `app/Mail` můžete umístit správu e-mailové komunikace:
+
+/--pre
+app/Mail/
+├── templates/ ← e-mailové šablony
+│ ├── order-confirmation.latte
+│ └── welcome.latte
+└── OrderMailer.php
+\--
+
+
+Mapování presenterů
+===================
+
+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`.
+
+Na této stránce jsme si ukázali, že presentery umísťujeme do složky `app/Presentation` (případně `app/UI`). Tuto konvenci musíme Nette sdělit v konfiguračním souboru. Stačí jeden řádek:
+
+```neon
+application:
+ mapping: App\Presentation\*\**Presenter
+```
+
+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\Presentation`, aby se presenter `Home` mapoval na třídu `App\Presentation\HomePresenter`. Což dosáhneme touto konfigurací:
+
+```neon
+application:
+ mapping: App\Presentation\*Presenter
+```
+
+Mapování funguje tak, že název presenteru `Home` nahradí hvězdičku v masce `App\Presentation\*Presenter`, čímž získáme výsledný název třídy `App\Presentation\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\Presentation\Home\HomePresenter`. Toho dosáhneme zdvojením dvojtečky (vyžaduje Nette Application 3.2):
+
+```neon
+application:
+ mapping: App\Presentation\**Presenter
+```
+
+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\Presentation\Front\**Presenter
+ Admin: App\Presentation\Admin\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Podle této konfigurace se presenter `Front:Home` mapuje na třídu `App\Presentation\Front\Home\HomePresenter`, zatímco presenter `Api:OAuth` na třídu `App\Api\OAuthPresenter`.
+
+Protože moduly `Front` i `Admin` mají podobný způsob mapování a takových modulů bude nejspíš více, 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\Presentation\*\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Funguje to i pro hlouběji zanořené adresářové struktury, 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\Presentation\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\Presentation, *, **Presenter]
+ Api: [App\Api, '', *Presenter]
+```
diff --git a/application/cs/how-it-works.texy b/application/cs/how-it-works.texy
index b0025a12a0..f3c4b84a03 100644
--- a/application/cs/how-it-works.texy
+++ b/application/cs/how-it-works.texy
@@ -22,32 +22,34 @@ 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
+│ ├── Presentation/ ← 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
+├── assets/ ← zdroje (SCSS, TypeScript, zdrojové obrázky)
├── bin/ ← skripty spouštěné z příkazové řádky
├── config/ ← konfigurační soubory
│ ├── common.neon
-│ └── local.neon
+│ └── services.neon
├── log/ ← logované chyby
├── temp/ ← dočasné soubory, cache, …
├── vendor/ ← knihovny instalované Composerem
│ ├── ...
│ └── autoload.php ← autoloading všech nainstalovaných balíčků
├── www/ ← veřejný adresář neboli document-root projektu
+│ ├── assets/ ← zkompilované statické soubory (CSS, JS, obrázky, …)
│ ├── .htaccess ← pravidla mod_rewrite
│ └── index.php ← prvotní soubor, kterým se aplikace spouští
└── .htaccess ← zakazuje přístup do všech adresářů krom www
\--
-Adresářovou strukturu můžete jakkoliv měnit, složky přejmenovat či přesunout, a poté pouze upravit cesty k `log/` a `temp/` v souboru `Bootstrap.php` a dále cestu k tomuto souboru v `composer.json` v sekci `autoload`. Nic víc, žádná složitá rekonfigurace, žádné změny konstant. Nette totiž disponuje [chytrou autodetekcí|bootstrap#vyvojarsky-vs-produkcni-rezim].
+Adresářovou strukturu můžete jakkoliv měnit, složky přejmenovat či přesunout, je zcela flexibilní. Nette navíc disponuje chytrou autodetekcí a automaticky rozpozná umístění aplikace včetně její URL základny.
-U trošku větších aplikací můžeme složky s presentery a šablonami rozčlenit na disku do podadresářů a třídy do jmenných prostorů, kterým říkáme [moduly |modules].
+U trošku větších aplikací můžeme složky s presentery a šablonami [rozčlenit do podadresářů |directory-structure#Presentery a šablony] a třídy do jmenných prostorů, kterým říkáme moduly.
Adresář `www/` představuje tzv. veřejný adresář neboli document-root projektu. Můžete jej přejmenovat bez nutnosti cokoliv dalšího nastavovat na straně aplikace. Jen je potřeba [nakonfigurovat hosting |nette:troubleshooting#Jak změnit či ostranit z URL adresář www] tak, aby document-root mířil do tohoto adresáře.
@@ -65,7 +67,7 @@ Aplikace WebProject je připravená ke spuštění, není třeba vůbec nic konf
HTTP požadavek
==============
-Vše začíná ve chvíli, kdy uživatel v prohlížeči otevře stránku. Tedy když prohlížeč zaklepe na server s HTTP požadavkem. Požadavek míří na jediný PHP soubor, který se nachází ve veřejném adresáři `www/`, a tím je `index.php`. Dejme tomu, že jde o požadavek na adresu `https://example.com/product/123`. Díky vhodnému [nastavení serveru|nette:troubleshooting#Jak nastavit server pro hezká URL?] se i tohle URL mapuje na soubor `index.php` a ten se vykoná.
+Vše začíná ve chvíli, kdy uživatel v prohlížeči otevře stránku. Tedy když prohlížeč zaklepe na server s HTTP požadavkem. Požadavek míří na jediný PHP soubor, který se nachází ve veřejném adresáři `www/`, a tím je `index.php`. Dejme tomu, že jde o požadavek na adresu `https://example.com/product/123`. Díky vhodnému [nastavení serveru |nette:troubleshooting#Jak nastavit server pro hezká URL] se i tohle URL mapuje na soubor `index.php` a ten se vykoná.
Jeho úkolem je:
@@ -75,11 +77,11 @@ Jeho úkolem je:
Jakou že továrnu? Nevyrábíme přece traktory, ale webové stránky! Vydržte, hned se to vysvětlí.
-Slovy „inicializace prostředí“ myslíme například to, že se aktivuje [Tracy|tracy:], což je úžasný nástroj pro logování nebo vizualizaci chyb. Na produkčním serveru chyby loguje, na vývojovém rovnou zobrazuje. Tudíž k inicializaci patří i rozhodnutí, zda web běží v produkčním nebo vývojářském režimu. K tomu Nette používá autodetekci: pokud web spouštíte na localhost, běží v režimu vývojářském. Nemusíte tak nic konfigurovat a aplikace je rovnou připravena jak pro vývoj, tak ostré nasazení. Tyhle kroky se provádějí a jsou podrobně rozepsané v kapitole o [třídě Bootstrap|bootstrap].
+Slovy „inicializace prostředí“ myslíme například to, že se aktivuje [Tracy|tracy:], což je úžasný nástroj pro logování nebo vizualizaci chyb. Na produkčním serveru chyby loguje, na vývojovém rovnou zobrazuje. Tudíž k inicializaci patří i rozhodnutí, zda web běží v produkčním nebo vývojářském režimu. K tomu Nette používá [chytrou autodetekci |bootstrapping#Vývojářský vs produkční režim]: pokud web spouštíte na localhost, běží v režimu vývojářském. Nemusíte tak nic konfigurovat a aplikace je rovnou připravena jak pro vývoj, tak ostré nasazení. Tyhle kroky se provádějí a jsou podrobně rozepsané v kapitole o [třídě Bootstrap|bootstrapping].
Třetím bodem (ano, druhý jsme přeskočili, ale vrátíme se k němu) je spuštění aplikace. Vyřizování HTTP požadavků má v Nette na starosti třída `Nette\Application\Application` (dále `Application`), takže když říkáme spustit aplikaci, myslíme tím konkrétně zavolání metody s příznačným názvem `run()` na objektu této třídy.
-Nette je mentor, který vás vede k psaní čistých aplikací podle osvědčených metodik. A jedna z těch naprosto nejosvědčenějších se nazývá **dependency injection**, zkráceně DI. V tuto chvíli vás nechceme zatěžovat vysvětlováním DI, od toho je tu [samostatná kapitola|dependency-injection:introduction], podstatný je důsledek, že klíčové objekty nám bude obvykle vytvářet továrna na objekty, které se říká **DI kontejner** (zkráceně DIC). Ano, to je ta továrna, o které byla před chvíli řeč. A vyrobí nám i objekt `Application`, proto potřebujeme nejprve kontejner. Získáme jej pomocí třídy `Configurator` a necháme jej vyrobit objekt `Application`, zavoláme na něm metodu `run()` a tím se spustí Nette aplikace. Přesně tohle se děje v souboru [index.php|bootstrap#index.php].
+Nette je mentor, který vás vede k psaní čistých aplikací podle osvědčených metodik. A jedna z těch naprosto nejosvědčenějších se nazývá **dependency injection**, zkráceně DI. V tuto chvíli vás nechceme zatěžovat vysvětlováním DI, od toho je tu [samostatná kapitola|dependency-injection:introduction], podstatný je důsledek, že klíčové objekty nám bude obvykle vytvářet továrna na objekty, které se říká **DI kontejner** (zkráceně DIC). Ano, to je ta továrna, o které byla před chvíli řeč. A vyrobí nám i objekt `Application`, proto potřebujeme nejprve kontejner. Získáme jej pomocí třídy `Configurator` a necháme jej vyrobit objekt `Application`, zavoláme na něm metodu `run()` a tím se spustí Nette aplikace. Přesně tohle se děje v souboru [index.php |bootstrapping#index.php].
Nette Application
@@ -91,7 +93,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 +123,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#Hledání šablon]).
-- `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 +136,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.
@@ -146,7 +145,7 @@ Možná jste se teď setkali s velkou spoustou nových pojmů, ale věříme, ž
Šablony
=======
-Když už přišla řeč na šablony, v Nette se používá šablonovací systém [Latte |latte:]. Proto taky ty koncovky `.latte` u šablon. Latte se používá jednak proto, že jde o nejlépe zabezpečený šablonovací systém pro PHP, a zároveň také systém nejintuitivnější. Nemusíte se učit mnoho nového, vystačíte si se znalostí PHP a několika značek. Všechno se dozvíte [v dokumentaci |latte:].
+Když už přišla řeč na šablony, v Nette se používá šablonovací systém [Latte |latte:]. Proto taky ty koncovky `.latte` u šablon. Latte se používá jednak proto, že jde o nejlépe zabezpečený šablonovací systém pro PHP, a zároveň také systém nejintuitivnější. Nemusíte se učit mnoho nového, vystačíte si se znalostí PHP a několika značek. Všechno se dozvíte [v dokumentaci |templates].
V šabloně se [vytvářejí odkazy |creating-links] na další presentery & akce takto:
@@ -160,10 +159,7 @@ Prostě místo reálného URL napíšete známý pár `Presenter:action` a uvede
detail produktu
```
-Generování URL má na starosti už dříve zmíněný router. Totiž routery v Nette jsou výjimečné tím, že dokáží provádět nejen transformace z URL na dvojici presenter:action, ale také obráceně, tedy z názvu presenteru + akce + parametrů vygenerovat URL.
-Díky tomu v Nette můžete úplně změnit tvary URL v celé hotové aplikaci, aniž byste změnili jediný znak v šabloně nebo presenteru. Jen tím, že upravíte router.
-Také díky tomu funguje tzv. kanonizace, což je další unikátní vlastnost Nette, která přispívá k lepšímu SEO (optimalizaci nalezitelnosti na internetu) tím, že automaticky zabraňuje existenci duplicitního obsahu na různých URL.
-Hodně programátorů to považuje za ohromující.
+Generování URL má na starosti už dříve zmíněný router. Totiž routery v Nette jsou výjimečné tím, že dokáží provádět nejen transformace z URL na dvojici presenter:action, ale také obráceně, tedy z názvu presenteru + akce + parametrů vygenerovat URL. Díky tomu v Nette můžete úplně změnit tvary URL v celé hotové aplikaci, aniž byste změnili jediný znak v šabloně nebo presenteru. Jen tím, že upravíte router. Také díky tomu funguje tzv. kanonizace, což je další unikátní vlastnost Nette, která přispívá k lepšímu SEO (optimalizaci nalezitelnosti na internetu) tím, že automaticky zabraňuje existenci duplicitního obsahu na různých URL. Hodně programátorů to považuje za ohromující.
Interaktivní komponenty
@@ -173,7 +169,7 @@ O presenterech vám musíme prozradit ještě jednu věc: mají v sobě zabudova
Komponenty jsou samostatné znovupoužitelné celky, které vkládáme do stránek (tedy presenterů). Mohou to být [formuláře |forms:in-presenter], [datagridy |https://componette.org/contributte/datagrid/], menu, hlasovací ankety, vlastně cokoliv, co má smysl používat opakovaně. Můžeme vytvářet vlastní komponenty nebo používat některé z [ohromné nabídky |https://componette.org] open source komponent.
-Komponenty zásadním způsobem ovlivňují přístup k tvorbě aplikacím. Otevřou vám nové možnosti skládání stránek z předpřipravených jednotek. A navíc mají něco společného s [Hollywoodem|components#Hollywood style].
+Komponenty zásadním způsobem ovlivňují přístup k tvorbě aplikacím. Otevřou vám nové možnosti skládání stránek z předpřipravených jednotek. A navíc mají něco společného s [Hollywoodem |components#Hollywood style].
DI kontejner a konfigurace
@@ -185,9 +181,9 @@ Nemějte obavy, není to žádný magický black box, jak by se třeba mohlo z p
Objektům, které DI kontejner vytváří, se z nějakého důvodu říká služby.
-Co je na této třídě opravdu speciálního, tak že ji neprogramujete vy, ale framework. On skutečně vygeneruje PHP kód a uloží ho na disk. Vy jen dáváte instrukce, jaké objekty má umět kontejner vyrábět a jak přesně. A tyhle instrukce jsou zapsané v [konfiguračních souborech|bootstrap#konfigurace-di-kontejneru], pro které se používá formát [NEON|neon:format] a tedy mají i příponu `.neon`.
+Co je na této třídě opravdu speciálního, tak že ji neprogramujete vy, ale framework. On skutečně vygeneruje PHP kód a uloží ho na disk. Vy jen dáváte instrukce, jaké objekty má umět kontejner vyrábět a jak přesně. A tyhle instrukce jsou zapsané v [konfiguračních souborech |bootstrapping#Konfigurace DI kontejneru], pro které se používá formát [NEON|neon:format] a tedy mají i příponu `.neon`.
-Konfigurační soubory slouží čistě k instruování DI kontejneru. Takže když například uvedu v sekci [session|http:configuration#Session] volbu `expiration: 14 days`, tak DI kontejner při vytváření objektu `Nette\Http\Session` reprezentujícího session zavolá jeho metodu `setExpiration('14 days')` a tím se konfigurace stane realitou.
+Konfigurační soubory slouží čistě k instruování DI kontejneru. Takže když například uvedu v sekci [session |http:configuration#Session] volbu `expiration: 14 days`, tak DI kontejner při vytváření objektu `Nette\Http\Session` reprezentujícího session zavolá jeho metodu `setExpiration('14 days')` a tím se konfigurace stane realitou.
Je tu pro vás připravená celá kapitola popisující, co vše lze [konfigurovat |nette:configuring] a jak [definovat vlastní služby |dependency-injection:services].
diff --git a/application/cs/modules.texy b/application/cs/modules.texy
deleted file mode 100644
index 2cb3e42719..0000000000
--- a/application/cs/modules.texy
+++ /dev/null
@@ -1,148 +0,0 @@
-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.
-
-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`.
-
-/--pre
-app/
-├── Cena: {$price|money}
+ +{if isWeekend($now)} ... {/if} +``` + +Pro složitější logiku můžete konfigurovat přímo objekt `Latte\Engine`: + +```php +protected function beforeRender(): void +{ $latte = $this->template->getLatte(); - $latte->addFilterLoader(/* ... */); + $latte->setFeature(Latte\Feature::MigrationWarnings); } ``` -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: +**Pomocí atributů** + +Elegantní způsob je definovat filtry a funkce jako metody přímo ve [třídě parametrů šablony|#Typově bezpečné šablony] presenteru nebo komponenty a označit je atributy: ```php -namespace App\Templating; +class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template +{ + #[Latte\Attributes\TemplateFilter] + public function money(float $val): string + { + return round($val) . ' Kč'; + } + + #[Latte\Attributes\TemplateFunction] + public function isWeekend(DateTimeInterface $date): bool + { + return $date->format('N') >= 6 + } +} +``` + +Latte automaticky rozpozná a zaregistruje metody označené těmito atributy. Název filtru nebo funkce v šabloně odpovídá názvu metody. Tyto metody nesmí být privátní. + +**Globálně pomocí Extension** + +Předchozí způsoby jsou vhodné pro filtry a funkce, které potřebujete jen v konkrétním presenteru nebo komponentě, nikoliv v celé aplikaci. Pro celou aplikaci je nejvhodnější vytvořit si [extension |latte:extending-latte#Latte Extension]. Jde o třídu, která centralizuje všechna rozšíření Latte pro celý projekt. Kusý příklad: + +```php +namespace App\Presentation\Accessory; final class LatteExtension extends Latte\Extension { @@ -203,24 +315,30 @@ final class LatteExtension extends Latte\Extension ]; } + private function filterTimeAgoInWords(DateTimeInterface $time): string + { + // ... + } + // ... } ``` -Zaregistrujeme ji pomocí [konfigurace |configuration#Šablony Latte]: +Extension zaregistrujeme pomocí [konfigurace |configuration#Šablony Latte]: ```neon latte: extensions: - - App\Templating\LatteExtension + - App\Presentation\Accessory\LatteExtension ``` +Výhodou extension je, že lze využít dependency injection, mít přístup k modelové vrstvě aplikace a všechna rozšíření mít přehledně na jednom místě. Extension umožnuje definovat i vlastní značky, providery, průchody pro Latte kompilátor a další. + Překládání ---------- -Pokud programujete vícejazyčnou aplikaci, budete nejspíš potřebovat některé texty v šabloně vypsat v různých jazycích. Nette Framework k tomuto účelu definuje rozhraní pro překlad [api:Nette\Localization\Translator], které má jedinou metodu `translate()`. Ta přijímá zprávu `$message`, což zpravidla bývá řetězec, a libovolné další parametry. Úkolem je vrátit přeložený řetězec. -V Nette není žádná výchozí implementace, můžete si vybrat podle svých potřeb z několika hotových řešeních, které najdete na [Componette |https://componette.org/search/localization]. V jejich dokumentaci se dozvíte, jak translator konfigurovat. +Pokud programujete vícejazyčnou aplikaci, budete nejspíš potřebovat některé texty v šabloně vypsat v různých jazycích. Nette Framework k tomuto účelu definuje rozhraní pro překlad [api:Nette\Localization\Translator], které má jedinou metodu `translate()`. Ta přijímá zprávu `$message`, což zpravidla bývá řetězec, a libovolné další parametry. Úkolem je vrátit přeložený řetězec. V Nette není žádná výchozí implementace, můžete si vybrat podle svých potřeb z několika hotových řešeních, které najdete na [Componette |https://componette.org/search/localization]. V jejich dokumentaci se dozvíte, jak translator konfigurovat. Šablonám lze nastavit překladač, který si [necháme předat |dependency-injection:passing-dependencies], metodou `setTranslator()`: @@ -237,7 +355,7 @@ Translator je alternativně možné nastavit pomocí [konfigurace |configuration ```neon latte: extensions: - - Latte\Essential\TranslatorExtension + - Latte\Essential\TranslatorExtension(@Nette\Localization\Translator) ``` Poté lze překladač používat například jako filtr `|translate`, a to včetně doplňujících parametrů, které se předají metodě `translate()` (viz `foo, bar`): diff --git a/application/de/@home.texy b/application/de/@home.texy index 91906d2888..a151863801 100644 --- a/application/de/@home.texy +++ b/application/de/@home.texy @@ -2,35 +2,84 @@ Nette Application ***************** .[perex] -Das Paket `nette/application` ist die Grundlage für die Erstellung interaktiver Webanwendungen. +Nette Application ist der Kern des Nette Frameworks und bietet leistungsstarke Werkzeuge zur Erstellung moderner Webanwendungen. Es bietet eine Reihe außergewöhnlicher Eigenschaften, die die Entwicklung erheblich vereinfachen und die Sicherheit sowie die Wartbarkeit des Codes verbessern. -- [Wie funktionieren die Anwendungen? |how-it-works] -- [Bootstrap] -- [Präsentatoren |Presenters] -- [Schablonen |Templates] -- [Module |Modules] -- [Routing |Routing] -- [URL-Links erstellen |creating-links] -- [Interaktive Komponenten |components] -- [AJAX & Schnipsel |ajax] -- [Multiplikator |multiplier] -- [Konfiguration |Configuration] +Installation +------------ -Einrichtung ------------ - -Laden Sie das Paket herunter und installieren Sie es mit [Composer |best-practices:composer]: +Laden Sie die Bibliothek herunter und installieren Sie sie mit [Composer|best-practices:composer]: ```shell composer require nette/application ``` -| Version | kompatibel mit PHP -|-----------|------------------- -| Nette-Anwendung 4.0 | PHP 8.0 - 8.2 -| Nette Anwendung 3.1 | PHP 7.2 - 8.2 -| Nette Anwendung 3.0 | PHP 7.1 - 8.0 -| Nette-Anwendung 2.4 | PHP 5.6 - 8.0 -Gilt für die neuesten Patch-Versionen. +Warum Nette Application wählen? +------------------------------- + +Nette war schon immer ein Pionier im Bereich der Webtechnologien. + +**Bidirektionaler Router:** Nette verfügt über ein fortschrittliches Routing-System, das durch seine Bidirektionalität einzigartig ist – es übersetzt nicht nur URLs in Anwendungsaktionen, sondern kann auch rückwirkend URL-Adressen generieren. Das bedeutet: +- Sie können jederzeit die URL-Struktur der gesamten Anwendung ändern, ohne die Templates anpassen zu müssen +- URLs werden automatisch kanonisiert, was die SEO verbessert +- Das Routing wird an einer Stelle definiert, nicht verstreut in Annotationen + +**Komponenten und Signale:** Das integrierte Komponentensystem, inspiriert von Delphi und React.js, ist unter PHP-Frameworks völlig einzigartig: +- Ermöglicht die Erstellung wiederverwendbarer UI-Elemente +- Unterstützt die hierarchische Zusammensetzung von Komponenten +- Bietet eine elegante Verarbeitung von AJAX-Anfragen mittels Signalen +- Umfangreiche Bibliothek fertiger Komponenten auf [Componette](https://componette.org) + +**AJAX und Snippets:** Nette führte bereits 2009 eine revolutionäre Methode zur Arbeit mit AJAX ein, lange vor ähnlichen Lösungen wie Hotwire für Ruby on Rails oder Symfony UX Turbo: +- Snippets ermöglichen die Aktualisierung nur von Teilen der Seite, ohne JavaScript schreiben zu müssen +- Automatische Integration mit dem Komponentensystem +- Intelligente Invalidierung von Seitenteilen +- Minimale Menge an übertragenen Daten + +**Intuitive Templates [Latte|latte:]:** Das sicherste Template-System für PHP mit erweiterten Funktionen: +- Automatischer Schutz vor XSS durch kontextsensitives Escaping +- Erweiterbarkeit durch eigene Filter, Funktionen und Tags +- Template-Vererbung und Snippets für AJAX +- Hervorragende Unterstützung für PHP 8.x mit Typsystem + +**Dependency Injection:** Nette nutzt Dependency Injection vollständig aus: +- Automatische Übergabe von Abhängigkeiten (Autowiring) +- Konfiguration mittels übersichtlichem NEON-Format +- Unterstützung für Komponenten-Factories + + +Hauptvorteile +------------- + +- **Sicherheit**: Automatischer Schutz vor [Schwachstellen|nette:vulnerability-protection] wie XSS, CSRF, etc. +- **Produktivität**: Weniger schreiben, mehr Funktionen dank cleverem Design +- **Debugging**: [Tracy Debugger|tracy:] mit Routing-Panel +- **Leistung**: Intelligenter Cache, Lazy Loading von Komponenten +- **Flexibilität**: Einfache Anpassung von URLs auch nach Fertigstellung der Anwendung +- **Komponenten**: Einzigartiges System wiederverwendbarer UI-Elemente +- **Modern**: Volle Unterstützung für PHP 8.4+ und Typsystem + + +Erste Schritte +-------------- + +1. [Wie Anwendungen funktionieren |how-it-works] - Verständnis der grundlegenden Architektur +2. [Presenter |presenters] - Arbeit mit Presentern und Aktionen +3. [Templates |templates] - Erstellung von Templates in Latte +4. [Routing |routing] - Konfiguration von URL-Adressen +5. [Interaktive Komponenten |components] - Nutzung des Komponentensystems + + +PHP-Kompatibilität +------------------ + +| Version | kompatibel mit PHP +|-------------------|------------------- +| Nette Application 4.0 | PHP 8.1 – 8.4 +| Nette Application 3.2 | PHP 8.1 – 8.4 +| Nette Application 3.1 | PHP 7.2 – 8.3 +| Nette Application 3.0 | PHP 7.1 – 8.0 +| Nette Application 2.4 | PHP 5.6 – 8.0 + +Gilt für die letzte Patch-Version. diff --git a/application/de/@left-menu.texy b/application/de/@left-menu.texy index 8fac50f03b..2a16b701bb 100644 --- a/application/de/@left-menu.texy +++ b/application/de/@left-menu.texy @@ -1,19 +1,22 @@ -Nette Bewerbung -*************** -- [Wie funktionieren die Anwendungen? |how-it-works] -- [Bootstrap] -- [Präsentatoren |Presenters] -- [Schablonen |Templates] -- [Module |Modules] -- [Routing |Routing] -- [URL-Links erstellen |creating-links] +Nette Application +***************** +- [Wie Anwendungen funktionieren |how-it-works] +- [Bootstrapping] +- [Presenter |presenters] +- [Templates |templates] +- [Verzeichnisstruktur |directory-structure] +- [Routing |routing] +- [Erstellen von URL-Links |creating-links] - [Interaktive Komponenten |components] -- [AJAX & Schnipsel |ajax] -- [Multiplikator |multiplier] -- [Konfiguration |Configuration] +- [AJAX & Snippets |ajax] +- [Multiplier |Multiplier] +- [Konfiguration |configuration] Weitere Lektüre *************** -- [Bewährte Praktiken |best-practices:] -- [Fehlersuche |nette:troubleshooting] +- [Warum Nette verwenden? |www:10-reasons-why-nette] +- [Installation |nette:installation] +- [Schreiben wir die erste Anwendung! |quickstart:] +- [Anleitungen und Verfahren |best-practices:] +- [Fehlerbehebung |nette:troubleshooting] diff --git a/application/de/@meta.texy b/application/de/@meta.texy new file mode 100644 index 0000000000..b3b806b2ca --- /dev/null +++ b/application/de/@meta.texy @@ -0,0 +1 @@ +{{sitename: Nette Dokumentation}} diff --git a/application/de/ajax.texy b/application/de/ajax.texy index bcdbd4ac93..3ef05ebfe4 100644 --- a/application/de/ajax.texy +++ b/application/de/ajax.texy @@ -1,38 +1,45 @@ -AJAX & Schnipsel -**************** +AJAX & Snippets +***************
-Moderne Webanwendungen laufen heute zur Hälfte auf einem Server und zur Hälfte in einem Browser. AJAX ist ein wichtiger verbindender Faktor. Welche Unterstützung bietet das Nette Framework?
-- Senden von Template-Fragmenten (sogenannte *snippets*)
+In der Ära moderner Webanwendungen, in der die Funktionalität oft zwischen Server und Browser aufgeteilt ist, ist AJAX ein unverzichtbares Bindeglied. Welche Möglichkeiten bietet uns das Nette Framework in diesem Bereich?
+- Senden von Teilen des Templates, sogenannten Snippets
- Übergabe von Variablen zwischen PHP und JavaScript
-- Debugging von AJAX-Anwendungen
+- Tools zum Debuggen von AJAX-Anfragen
-Eine AJAX-Anfrage kann mit einer Methode eines Dienstes, [der eine HTTP-Anfrage kapselt |http:request], erkannt werden `$httpRequest->isAjax()` (erkennt anhand des `X-Requested-With` HTTP-Headers). Es gibt auch eine Kurzform der Methode in Presenter: `$this->isAjax()`.
-Eine AJAX-Anfrage unterscheidet sich nicht von einer normalen Anfrage - ein Presenter wird mit einer bestimmten Ansicht und Parametern aufgerufen. Auch hier ist es dem Präsentator überlassen, wie er reagiert: Er kann seine Routinen nutzen, um entweder ein Fragment von HTML-Code (ein Snippet), ein XML-Dokument, ein JSON-Objekt oder ein Stück Javascript-Code zurückzugeben.
+AJAX-Anfrage
+============
-Es gibt ein vorverarbeitetes Objekt namens `payload`, das für das Senden von Daten in JSON an den Browser bestimmt ist.
+Eine AJAX-Anfrage unterscheidet sich im Grunde nicht von einer klassischen HTTP-Anfrage. Ein Presenter wird mit bestimmten Parametern aufgerufen. Und es liegt am Presenter, wie er auf die Anfrage reagiert – er kann Daten im JSON-Format zurückgeben, einen Teil des HTML-Codes senden, ein XML-Dokument usw.
-```php
-public function actionDelete(int $id): void
-{
- if ($this->isAjax()) {
- $this->payload->message = 'Erfolg';
- }
- // ...
-}
+Auf der Browserseite initialisieren wir die AJAX-Anfrage mit der Funktion `fetch()`:
+
+```js
+fetch(url, {
+ headers: {'X-Requested-With': 'XMLHttpRequest'},
+})
+.then(response => response.json())
+.then(payload => {
+ // Verarbeitung der Antwort
+});
```
-Um die volle Kontrolle über Ihre JSON-Ausgabe zu haben, verwenden Sie die Methode `sendJson` in Ihrem Presenter. Sie beendet den Presenter sofort und Sie können auf eine Vorlage verzichten:
+Auf der Serverseite erkennen wir eine AJAX-Anfrage mit der Methode `$httpRequest->isAjax()` des [die HTTP-Anfrage kapselnden |http:request] Dienstes. Zur Erkennung verwendet sie den HTTP-Header `X-Requested-With`, daher ist es wichtig, diesen mitzusenden. Innerhalb des Presenters kann die Methode `$this->isAjax()` verwendet werden.
+
+Wenn Sie Daten im JSON-Format senden möchten, verwenden Sie die Methode [`sendJson()` |presenters#Senden der Antwort]. Die Methode beendet auch die Aktivität des Presenters.
```php
-$this->sendJson(['key' => 'value', /* ... */]);
+public function actionExport(): void
+{
+ $this->sendJson($this->model->getData);
+}
```
-Wenn wir HTML senden wollen, können wir entweder eine spezielle Vorlage für AJAX-Anfragen festlegen:
+Wenn Sie planen, mit einem speziellen Template für AJAX zu antworten, können Sie dies wie folgt tun:
```php
public function handleClick($param): void
@@ -45,222 +52,198 @@ public function handleClick($param): void
```
-Naja .[#toc-naja]
-=================
+Snippets
+========
+
+Das stärkste Mittel, das Nette zur Verbindung von Server und Client bietet, sind Snippets. Dank ihnen können Sie eine gewöhnliche Anwendung mit minimalem Aufwand und wenigen Codezeilen in eine AJAX-Anwendung verwandeln. Wie das Ganze funktioniert, demonstriert das Beispiel Fifteen, dessen Code Sie auf [GitHub |https://github.com/nette-examples/fifteen] finden.
+
+Snippets, oder Ausschnitte, ermöglichen es, nur Teile der Seite zu aktualisieren, anstatt die gesamte Seite neu zu laden. Dies ist nicht nur schneller und effizienter, sondern bietet auch eine komfortablere Benutzererfahrung. Snippets erinnern vielleicht an Hotwire für Ruby on Rails oder Symfony UX Turbo. Interessanterweise hat Nette Snippets bereits 14 Jahre früher eingeführt.
+
+Wie funktionieren Snippets? Beim ersten Laden der Seite (nicht-AJAX-Anfrage) wird die gesamte Seite einschließlich aller Snippets geladen. Wenn der Benutzer mit der Seite interagiert (z. B. auf einen Button klickt, ein Formular absendet usw.), wird anstelle des Ladens der gesamten Seite eine AJAX-Anfrage ausgelöst. Der Code im Presenter führt die Aktion aus und entscheidet, welche Snippets aktualisiert werden müssen. Nette rendert diese Snippets und sendet sie in Form eines Arrays im JSON-Format. Der Verarbeitungscode im Browser fügt die empfangenen Snippets wieder in die Seite ein. Es wird also nur der Code der geänderten Snippets übertragen, was Bandbreite spart und das Laden im Vergleich zur Übertragung des gesamten Seiteninhalts beschleunigt.
-Die [Naja-Bibliothek |https://naja.js.org] wird verwendet, um AJAX-Anfragen auf der Browserseite zu verarbeiten. [Installieren |https://naja.js.org/#/guide/01-install-setup-naja] Sie sie als node.js-Paket (zur Verwendung mit Webpack, Rollup, Vite, Parcel und mehr):
+
+Naja
+----
+
+Zur Verarbeitung von Snippets auf der Browserseite dient die [Bibliothek Naja |https://naja.js.org]. Diese [installieren Sie |https://naja.js.org/#/guide/01-install-setup-naja] als node.js-Paket (zur Verwendung mit Anwendungen wie Webpack, Rollup, Vite, Parcel und anderen):
```shell
npm install naja
```
-...oder fügen Sie sie direkt in die Seitenvorlage ein:
+…oder fügen Sie sie direkt in das Seiten-Template ein:
```html
```
+Zuerst muss die Bibliothek [initialisiert |https://naja.js.org/#/guide/01-install-setup-naja?id=initialization] werden:
-Schnipsel .[#toc-snippets]
-==========================
+```js
+naja.initialize();
+```
-Es gibt ein weitaus mächtigeres Werkzeug der eingebauten AJAX-Unterstützung - Snippets. Mit ihnen ist es möglich, eine normale Anwendung mit nur wenigen Zeilen Code in eine AJAX-Anwendung zu verwandeln. Wie das Ganze funktioniert, wird im Fifteen-Beispiel gezeigt, dessen Code auch im Build oder auf [GitHub |https://github.com/nette-examples/fifteen] verfügbar ist.
+Um aus einem gewöhnlichen Link (Signal) oder dem Absenden eines Formulars eine AJAX-Anfrage zu machen, genügt es, den entsprechenden Link, das Formular oder den Button mit der Klasse `ajax` zu kennzeichnen:
-Die Funktionsweise der Snippets besteht darin, dass bei der ersten (d.h. Nicht-AJAX-) Anfrage die gesamte Seite übertragen wird und dann bei jeder [AJAX-Unteranfrage |components#signal] (Anfrage derselben Ansicht desselben Präsentators) nur der Code der geänderten Teile in das bereits erwähnte Repository `payload` übertragen wird.
+```html
+Go
-Snippets erinnern vielleicht an Hotwire für Ruby on Rails oder Symfony UX Turbo, aber Nette hat sie schon vierzehn Jahre früher erfunden.
+
+oder
+
+
+```
-Invalidierung von Snippets .[#toc-invalidation-of-snippets]
-===========================================================
-Jeder Nachkomme der Klasse [Control |components] (also auch ein Presenter) ist in der Lage, sich zu merken, ob es während einer Anfrage Änderungen gab, die ein erneutes Rendern erforderlich machen. Dafür gibt es zwei Methoden: `redrawControl()` und `isControlInvalid()`. Ein Beispiel:
+Neuzeichnen von Snippets
+------------------------
+
+Jedes Objekt der Klasse [Control |components] (einschließlich des Presenters selbst) verfolgt, ob Änderungen aufgetreten sind, die sein Neuzeichnen erfordern. Dazu dient die Methode `redrawControl()`:
```php
public function handleLogin(string $user): void
{
- // Das Objekt muss neu gerendert werden, nachdem sich der Benutzer angemeldet hat
+ // nach dem Login muss der relevante Teil neu gezeichnet werden
$this->redrawControl();
// ...
}
```
-Nette bietet jedoch eine noch feinere Auflösung als ganze Komponenten. Die aufgeführten Methoden akzeptieren den Namen eines sogenannten "Snippets" als optionalen Parameter. Ein "Snippet" ist im Grunde ein Element in Ihrer Vorlage, das zu diesem Zweck durch ein Latte-Makro markiert wurde, mehr dazu später. So ist es möglich, eine Komponente aufzufordern, nur *Teile* ihrer Vorlage neu zu zeichnen. Wenn die gesamte Komponente ungültig ist, werden alle ihre Schnipsel neu gerendert. Eine Komponente ist auch dann "ungültig", wenn eine ihrer Unterkomponenten ungültig ist.
-
-```php
-$this->isControlInvalid(); // -> false
-$this->redrawControl('header'); // macht das Snippet namens 'header' ungültig
-$this->isControlInvalid('header'); // -> true
-$this->isControlInvalid('footer'); // -> false
-$this->isControlInvalid(); // -> true, mindestens ein Snippet ist ungültig
+Nette ermöglicht eine noch feinere Kontrolle darüber, was neu gezeichnet werden soll. Die genannte Methode kann nämlich als Argument den Namen des Snippets entgegennehmen. Man kann also auf der Ebene von Template-Teilen invalidieren (sprich: Neuzeichnen erzwingen). Wenn die gesamte Komponente invalidiert wird, wird auch jedes ihrer Snippets neu gezeichnet:
-$this->redrawControl(); // macht die gesamte Komponente ungültig, jedes Snippet
-$this->isControlInvalid('footer'); // -> true
+```php
+// invalidiert das Snippet 'header'
+$this->redrawControl('header');
```
-Eine Komponente, die ein Signal erhält, wird automatisch zum Neuzeichnen markiert.
-
-Dank des Snippet-Redrawing wissen wir genau, welche Teile welcher Elemente neu gezeichnet werden sollten.
-
-
-Tag `{snippet} … {/snippet}` .{toc: Tag snippet}
-================================================
-Das Rendering der Seite verläuft ganz ähnlich wie bei einer normalen Anfrage: Es werden die gleichen Vorlagen geladen usw. Entscheidend ist jedoch, dass die Teile, die nicht in die Ausgabe gelangen sollen, weggelassen werden; die anderen Teile sollen mit einem Bezeichner verknüpft und in einem für einen JavaScript-Handler verständlichen Format an den Benutzer gesendet werden.
+Snippets in Latte
+-----------------
-
-Syntax .[#toc-syntax]
----------------------
-
-Wenn ein Steuerelement oder ein Snippet in der Vorlage vorhanden ist, müssen wir es mit dem `{snippet} ... {/snippet}` pair-Tag einpacken - er sorgt dafür, dass das gerenderte Snippet "ausgeschnitten" und an den Browser gesendet wird. Außerdem wird es in ein Hilfs-Tag eingebettet `` Tag (es ist möglich, einen anderen zu verwenden). Im folgenden Beispiel wird ein Snippet mit dem Namen `header` definiert. Es kann ebenso gut die Vorlage einer Komponente darstellen:
+Die Verwendung von Snippets in Latte ist extrem einfach. Um einen Teil des Templates als Snippet zu definieren, umschließen Sie ihn einfach mit den Tags `{snippet}` und `{/snippet}`:
```latte
{snippet header}
-
Hello ...
+Hallo ...
{/snippet} ``` -Wenn Sie ein Snippet mit einem anderen Element erstellen möchten als `` erstellen oder dem Element benutzerdefinierte Attribute hinzufügen möchten, können Sie die folgende Definition verwenden:
+Das Snippet erstellt in der HTML-Seite ein `
`-Element mit einer speziellen generierten `id`. Beim Neuzeichnen des Snippets wird dann der Inhalt dieses Elements aktualisiert. Daher ist es notwendig, dass beim erstmaligen Rendern der Seite auch alle Snippets gerendert werden, auch wenn sie anfangs leer sein mögen.
+
+Sie können auch ein Snippet mit einem anderen Element als `
` erstellen, indem Sie ein n:Attribut verwenden:
```latte
-
```
-Dynamische Schnipsel .[#toc-dynamic-snippets]
-=============================================
+Snippet-Bereiche
+----------------
-In Nette können Sie auch Snippets mit einem dynamischen Namen definieren, der auf einem Laufzeitparameter basiert. Dies eignet sich besonders für verschiedene Listen, bei denen nur eine Zeile geändert werden muss, aber nicht die ganze Liste mit übertragen werden soll. Ein Beispiel hierfür wäre:
+Snippet-Namen können auch Ausdrücke sein:
```latte
-{$item}
+{/foreach}
```
-Es gibt ein statisches Snippet namens `itemsContainer`, das mehrere dynamische Snippets enthält: `item-0`, `item-1` und so weiter.
+So entstehen mehrere Snippets `item-0`, `item-1` usw. Wenn wir ein dynamisches Snippet direkt invalidieren würden (zum Beispiel `item-1`), würde nichts neu gezeichnet werden. Der Grund dafür ist, dass Snippets wirklich wie Ausschnitte funktionieren und nur sie selbst direkt gerendert werden. Im Template gibt es jedoch faktisch kein Snippet namens `item-1`. Dieses entsteht erst durch die Ausführung des Codes um das Snippet herum, also der foreach-Schleife. Wir kennzeichnen daher den Teil des Templates, der ausgeführt werden soll, mit dem Tag `{snippetArea}`:
-Ein dynamisches Snippet kann nicht direkt neu gezeichnet werden (das erneute Zeichnen von `item-1` hat keine Auswirkung), Sie müssen das übergeordnete Snippet (in diesem Beispiel `itemsContainer`) neu zeichnen. Dies bewirkt, dass der Code des übergeordneten Snippets ausgeführt wird, aber nur seine Unter-Snippets an den Browser gesendet werden. Wenn Sie nur einen der Teil-Snippets senden wollen, müssen Sie die Eingabe für das übergeordnete Snippet so ändern, dass die anderen Teil-Snippets nicht erzeugt werden.
+```latte
+()`, wobei `` der Name der Komponente ist, die erstellt und zurückgegeben wird.
+Eine Komponenten-Factory stellt eine elegante Möglichkeit dar, Komponenten erst dann zu erstellen, wenn sie tatsächlich benötigt werden (lazy / on demand). Der ganze Zauber besteht darin, eine Methode mit dem Namen `createComponent()` zu implementieren, wobei `` der Name der zu erstellenden Komponente ist, und die die Komponente erstellt und zurückgibt.
```php .{file:DefaultPresenter.php}
class DefaultPresenter extends Nette\Application\UI\Presenter
@@ -37,43 +37,43 @@ class DefaultPresenter extends Nette\Application\UI\Presenter
}
```
-Da alle Komponenten in separaten Methoden erstellt werden, ist der Code sauberer und leichter zu lesen.
+Dadurch, dass alle Komponenten in separaten Methoden erstellt werden, gewinnt der Code an Übersichtlichkeit.
.[note]
-Komponentennamen beginnen immer mit einem Kleinbuchstaben, obwohl sie im Methodennamen groß geschrieben werden.
+Komponentennamen beginnen immer mit einem Kleinbuchstaben, obwohl sie im Methodennamen großgeschrieben werden.
-Wir rufen die Factories nie direkt auf, sondern sie werden automatisch aufgerufen, wenn wir Komponenten zum ersten Mal verwenden. Dadurch wird eine Komponente im richtigen Moment erstellt, und nur dann, wenn sie wirklich benötigt wird. Wenn wir die Komponente nicht verwenden würden (z. B. bei einer AJAX-Anfrage, bei der nur ein Teil der Seite zurückgegeben wird, oder wenn Teile im Cache gespeichert sind), wird sie gar nicht erst erstellt, und wir sparen Leistung des Servers.
+Factories werden niemals direkt aufgerufen, sie rufen sich selbst auf, wenn die Komponente zum ersten Mal verwendet wird. Dadurch wird die Komponente zum richtigen Zeitpunkt erstellt und nur dann, wenn sie tatsächlich benötigt wird. Wenn wir die Komponente nicht verwenden (z. B. bei einer AJAX-Anfrage, bei der nur ein Teil der Seite übertragen wird, oder beim Caching des Templates), wird sie überhaupt nicht erstellt und wir sparen Serverleistung.
```php .{file:DefaultPresenter.php}
-// wir greifen auf die Komponente zu und wenn es das erste Mal war,
-// wird createComponentPoll() aufgerufen, um sie zu erstellen
+// Wir greifen auf die Komponente zu, und wenn es das erste Mal war,
+// wird createComponentPoll() aufgerufen, die sie erstellt
$poll = $this->getComponent('poll');
// alternative Syntax: $poll = $this['poll'];
```
-In der Vorlage können Sie eine Komponente mit dem Tag [{control} |#Rendering] rendern. Es besteht also keine Notwendigkeit, die Komponenten manuell an die Vorlage zu übergeben.
+Im Template kann eine Komponente mit dem Tag [{control} |#Rendern] gerendert werden. Es ist daher nicht notwendig, Komponenten manuell an das Template zu übergeben.
```latte
-()` oder `render()`aufrufen, rufen Signale Methoden auf `handle()`. Während sich das Konzept der Aktion (oder Ansicht) nur auf Präsentatoren bezieht, gelten Signale für alle Komponenten. Und damit auch für Presenter, denn `UI\Presenter` ist ein Abkömmling von `UI\Control`.
+Diese Art von Anfragen wird als Signale bezeichnet. Und ähnlich wie Aktionen die Methoden `action()` oder `render()` aufrufen, rufen Signale die Methoden `handle()` auf. Während der Begriff Aktion (oder View) rein mit Presentern zusammenhängt, betreffen Signale alle Komponenten. Und somit auch Presenter, da `UI\Presenter` ein Nachfahre von `UI\Control` ist.
```php
public function handleClick(int $x, int $y): void
@@ -192,36 +192,36 @@ public function handleClick(int $x, int $y): void
}
```
-Der Link, der das Signal aufruft, wird auf die übliche Weise erstellt, d.h. in der Vorlage durch das Attribut `n:href` oder den Tag `{link}`, im Code durch die Methode `link()`. Mehr dazu im Kapitel [URL-Links erstellen |creating-links#Links to Signal].
+Einen Link, der ein Signal aufruft, erstellen wir auf die übliche Weise, d. h. im Template mit dem Attribut `n:href` oder dem Tag `{link}`, im Code mit der Methode `link()`. Mehr dazu im Kapitel [Erstellen von URL-Links |creating-links#Links zu Signalen].
```latte
-click here
+Hier klicken
```
-Das Signal wird immer im aktuellen Präsentator und in der aktuellen Ansicht aufgerufen, es ist also nicht möglich, das Signal in einem anderen Präsentator / einer anderen Aktion zu verlinken.
+Ein Signal wird immer im aktuellen Presenter und der aktuellen Action aufgerufen, es kann nicht in einem anderen Presenter oder einer anderen Action ausgelöst werden.
-Das Signal bewirkt also, dass die Seite genau so neu geladen wird wie in der ursprünglichen Anfrage, nur dass zusätzlich die Signalbehandlungsmethode mit den entsprechenden Parametern aufgerufen wird. Wenn die Methode nicht existiert, wird die Ausnahme [api:Nette\Application\UI\BadSignalException] ausgelöst, die dem Benutzer als Fehlerseite 403 Forbidden angezeigt wird.
+Ein Signal bewirkt also das Neuladen der Seite genau wie bei der ursprünglichen Anfrage, ruft aber zusätzlich die Signal-Handler-Methode mit den entsprechenden Parametern auf. Wenn die Methode nicht existiert, wird eine Ausnahme [api:Nette\Application\UI\BadSignalException] ausgelöst, die dem Benutzer als Fehlerseite 403 Forbidden angezeigt wird.
-Schnipsel und AJAX .[#toc-snippets-and-ajax]
-============================================
+Snippets und AJAX
+=================
-Die Signale erinnern Sie vielleicht ein wenig an AJAX: Handler, die auf der aktuellen Seite aufgerufen werden. Und Sie haben Recht, Signale werden wirklich oft mit AJAX aufgerufen, und dann übertragen wir nur geänderte Teile der Seite an den Browser. Sie werden Snippets genannt. Mehr Informationen finden Sie auf der [Seite über AJAX |ajax].
+Signale erinnern Sie vielleicht ein wenig an AJAX: Handler, die auf der aktuellen Seite aufgerufen werden. Und Sie haben Recht, Signale werden tatsächlich oft mittels AJAX aufgerufen, und anschließend übertragen wir nur die geänderten Teile der Seite an den Browser. Also sogenannte Snippets. Weitere Informationen finden Sie auf der [AJAX gewidmeten Seite |ajax].
-Flash-Meldungen .[#toc-flash-messages]
-======================================
+Flash-Nachrichten
+=================
-Eine Komponente verfügt über einen eigenen, vom Presenter unabhängigen Speicher für Flash-Nachrichten. Dies sind Meldungen, die z.B. über das Ergebnis der Operation informieren. Eine wichtige Eigenschaft von Flash-Meldungen ist, dass sie auch nach einer Routing in der Vorlage verfügbar sind. Selbst nachdem sie angezeigt wurden, bleiben sie noch 30 Sekunden lang erhalten - zum Beispiel für den Fall, dass der Benutzer die Seite ungewollt aktualisiert - die Nachricht geht nicht verloren.
+Eine Komponente hat ihren eigenen Speicher für Flash-Nachrichten, unabhängig vom Presenter. Dies sind Nachrichten, die z. B. über das Ergebnis einer Operation informieren. Ein wichtiges Merkmal von Flash-Nachrichten ist, dass sie auch nach einer Weiterleitung im Template verfügbar sind. Auch nach der Anzeige bleiben sie weitere 30 Sekunden aktiv – zum Beispiel für den Fall, dass der Benutzer aufgrund einer fehlerhaften Übertragung die Seite neu lädt – die Nachricht verschwindet also nicht sofort.
-Das Versenden erfolgt mit der Methode [flashMessage |api:Nette\Application\UI\Control::flashMessage()]. Der erste Parameter ist der Nachrichtentext oder das `stdClass` Objekt, das die Nachricht repräsentiert. Der optionale zweite Parameter ist der Typ der Nachricht (Fehler, Warnung, Info, etc.). Die Methode `flashMessage()` gibt eine Instanz von flash message als Objekt stdClass zurück, an das Sie Informationen übergeben können.
+Das Senden übernimmt die Methode [flashMessage |api:Nette\Application\UI\Control::flashMessage()]. Der erste Parameter ist der Nachrichtentext oder ein `stdClass`-Objekt, das die Nachricht repräsentiert. Der optionale zweite Parameter ist ihr Typ (error, warning, info usw.). Die Methode `flashMessage()` gibt eine Instanz der Flash-Nachricht als `stdClass`-Objekt zurück, dem weitere Informationen hinzugefügt werden können.
```php
-$this->flashMessage('Artikel wurde gelöscht.');
-$this->redirect(/* ... */); // und umleiten
+$this->flashMessage('Der Eintrag wurde gelöscht.');
+$this->redirect(/* ... */); // und wir leiten weiter
```
-In der Vorlage stehen diese Meldungen in der Variablen `$flashes` als Objekte `stdClass` zur Verfügung, die die Eigenschaften `message` (Meldungstext), `type` (Meldungstyp) enthalten und die bereits erwähnten Benutzerinformationen enthalten können. Wir zeichnen sie wie folgt:
+Dem Template stehen diese Nachrichten in der Variablen `$flashes` als `stdClass`-Objekte zur Verfügung, die die Eigenschaften `message` (Nachrichtentext), `type` (Nachrichtentyp) enthalten und die bereits erwähnten Benutzerinformationen enthalten können. Wir rendern sie zum Beispiel so:
```latte
{foreach $flashes as $flash}
@@ -230,44 +230,66 @@ In der Vorlage stehen diese Meldungen in der Variablen `$flashes` als Objekte `s
```
-Dauerhafte Parameter .[#toc-persistent-parameters]
-==================================================
+Weiterleitung nach Signal
+=========================
-Persistente Parameter werden verwendet, um den Zustand von Komponenten zwischen verschiedenen Anfragen zu erhalten. Ihr Wert bleibt gleich, auch wenn ein Link angeklickt wird. Im Gegensatz zu Sitzungsdaten werden sie in der URL übertragen. Und sie werden automatisch übertragen, einschließlich Links, die in anderen Komponenten auf derselben Seite erstellt wurden.
+Nach der Verarbeitung eines Komponentensignals folgt oft eine Weiterleitung. Dies ist eine ähnliche Situation wie bei Formularen – nach dem Absenden leiten wir ebenfalls weiter, damit beim Neuladen der Seite im Browser die Daten nicht erneut gesendet werden.
-Sie haben zum Beispiel eine Komponente zum Paging von Inhalten. Es kann mehrere solcher Komponenten auf einer Seite geben. Und Sie möchten, dass alle Komponenten auf ihrer aktuellen Seite bleiben, wenn Sie auf den Link klicken. Deshalb machen wir die Seitennummer (`page`) zu einem dauerhaften Parameter.
+```php
+$this->redirect('this') // leitet zum aktuellen Presenter und zur aktuellen Action weiter
+```
-Das Erstellen eines dauerhaften Parameters ist in Nette extrem einfach. Erstellen Sie einfach eine öffentliche Eigenschaft und versehen Sie sie mit dem Attribut: (früher wurde `/** @persistent */` verwendet)
+Da eine Komponente ein wiederverwendbares Element ist und normalerweise keine direkte Bindung an bestimmte Presenter haben sollte, interpretieren die Methoden `redirect()` und `link()` den Parameter automatisch als Signal der Komponente:
```php
-use Nette\Application\Attributes\Persistent; // diese Zeile ist wichtig
+$this->redirect('click') // leitet zum Signal 'click' derselben Komponente weiter
+```
+
+Wenn Sie zu einem anderen Presenter oder einer anderen Aktion weiterleiten müssen, können Sie dies über den Presenter tun:
+
+```php
+$this->getPresenter()->redirect('Product:show'); // leitet zu einem anderen Presenter/Action weiter
+```
+
+
+Persistente Parameter
+=====================
+
+Persistente Parameter dienen dazu, den Zustand in Komponenten über verschiedene Anfragen hinweg zu erhalten. Ihr Wert bleibt auch nach dem Klick auf einen Link gleich. Im Gegensatz zu Daten in der Session werden sie in der URL übertragen. Und das vollautomatisch, einschließlich Links, die in anderen Komponenten auf derselben Seite erstellt wurden.
+
+Sie haben z. B. eine Komponente für die Paginierung von Inhalten. Solche Komponenten können auf einer Seite mehrmals vorkommen. Und wir möchten, dass nach dem Klick auf einen Link alle Komponenten auf ihrer aktuellen Seite bleiben. Deshalb machen wir die Seitenzahl (`page`) zu einem persistenten Parameter.
+
+Die Erstellung eines persistenten Parameters ist in Nette äußerst einfach. Es genügt, eine öffentliche Eigenschaft zu erstellen und sie mit einem Attribut zu kennzeichnen: (früher wurde `/** @persistent */` verwendet)
+
+```php
+use Nette\Application\Attributes\Persistent; // diese Zeile ist wichtig
class PaginatingControl extends Control
{
#[Persistent]
- public int $page = 1; // muss öffentlich sein
+ public int $page = 1; // muss public sein
}
```
-Es wird empfohlen, den Datentyp (z. B. `int`) mit der Eigenschaft zu verknüpfen, und Sie können auch einen Standardwert angeben. Parameterwerte können [validiert |#Validation of Persistent Parameters] werden.
+Für die Eigenschaft empfehlen wir, auch den Datentyp anzugeben (z. B. `int`), und Sie können auch einen Standardwert angeben. Die Werte der Parameter können [validiert |#Validierung persistenter Parameter] werden.
-Sie können den Wert eines persistenten Parameters beim Erstellen eines Links ändern:
+Beim Erstellen eines Links kann der Wert des persistenten Parameters geändert werden:
```latte
-next
+weiter
```
-Oder er kann *zurückgesetzt* werden, d.h. aus der URL entfernt werden. Er nimmt dann seinen Standardwert an:
+Oder er kann *zurückgesetzt* werden, d. h. aus der URL entfernt werden. Dann nimmt er seinen Standardwert an:
```latte
-reset
+zurücksetzen
```
-Persistente Komponenten .[#toc-persistent-components]
-=====================================================
+Persistente Komponenten
+=======================
-Nicht nur Parameter, sondern auch Komponenten können persistent sein. Ihre persistenten Parameter werden auch zwischen verschiedenen Aktionen oder zwischen verschiedenen Präsentatoren übertragen. Wir kennzeichnen persistente Komponenten mit diesen Annotationen für die Presenter-Klasse. Zum Beispiel markieren wir hier die Komponenten `calendar` und `poll` wie folgt:
+Nicht nur Parameter, sondern auch Komponenten können persistent sein. Bei einer solchen Komponente werden ihre persistenten Parameter auch zwischen verschiedenen Aktionen des Presenters oder zwischen mehreren Presentern übertragen. Persistente Komponenten kennzeichnen wir mit einer Annotation in der Presenter-Klasse. So kennzeichnen wir beispielsweise die Komponenten `calendar` und `poll`:
```php
/**
@@ -278,9 +300,9 @@ class DefaultPresenter extends Nette\Application\UI\Presenter
}
```
-Sie müssen die Unterkomponenten nicht als persistent kennzeichnen, sie sind automatisch persistent.
+Sub-Komponenten innerhalb dieser Komponenten müssen nicht gekennzeichnet werden, sie werden ebenfalls persistent.
-In PHP 8 können Sie auch Attribute verwenden, um persistente Komponenten zu kennzeichnen:
+In PHP 8 können Sie zur Kennzeichnung persistenter Komponenten auch Attribute verwenden:
```php
use Nette\Application\Attributes\Persistent;
@@ -292,18 +314,18 @@ class DefaultPresenter extends Nette\Application\UI\Presenter
```
-Komponenten mit Abhängigkeiten .[#toc-components-with-dependencies]
-===================================================================
+Komponenten mit Abhängigkeiten
+==============================
-Wie kann man Komponenten mit Abhängigkeiten erstellen, ohne die Präsentatoren, die sie verwenden werden, zu "versauen"? Dank der cleveren Funktionen des DI-Containers in Nette können wir, wie bei der Verwendung herkömmlicher Dienste, den Großteil der Arbeit dem Framework überlassen.
+Wie erstellt man Komponenten mit Abhängigkeiten, ohne die Presenter, die sie verwenden, zu „verschmutzen“? Dank der intelligenten Eigenschaften des DI-Containers in Nette kann man, wie bei der Verwendung klassischer Dienste, den größten Teil der Arbeit dem Framework überlassen.
-Nehmen wir als Beispiel eine Komponente, die von dem Dienst `PollFacade` abhängig ist:
+Nehmen wir als Beispiel eine Komponente, die eine Abhängigkeit vom Dienst `PollFacade` hat:
```php
class PollControl extends Control
{
public function __construct(
- private int $id, // Id einer Umfrage, für die die Komponente erstellt wird
+ private int $id, // ID der Umfrage, für die wir die Komponente erstellen
private PollFacade $facade,
) {
}
@@ -316,11 +338,11 @@ class PollControl extends Control
}
```
-Wenn wir einen klassischen Dienst schreiben würden, gäbe es nichts zu befürchten. Der DI-Container würde sich unsichtbar um die Übergabe aller Abhängigkeiten kümmern. Aber wir handhaben die Komponenten normalerweise so, dass wir eine neue Instanz von ihnen direkt im Presenter in [Factory-Methoden |#factory methods] `createComponent...()` erstellen. Aber die Übergabe aller Abhängigkeiten aller Komponenten an den Presenter, um sie dann an die Komponenten weiterzugeben, ist umständlich. Und die Menge des geschriebenen Codes...
+Wenn wir einen klassischen Dienst schreiben würden, gäbe es nichts zu lösen. Der DI-Container würde sich unsichtbar um die Übergabe aller Abhängigkeiten kümmern. Aber mit Komponenten gehen wir normalerweise so um, dass wir ihre neue Instanz direkt im Presenter in den [#Factory-Methoden] `createComponent…()` erstellen. Aber alle Abhängigkeiten aller Komponenten an den Presenter zu übergeben, nur um sie dann an die Komponenten weiterzugeben, ist umständlich. Und der viele geschriebene Code…
-Die logische Frage ist, warum registrieren wir die Komponente nicht einfach als klassischen Dienst, übergeben sie an den Präsentator und geben sie dann in der Methode `createComponent...()` zurück? Dieser Ansatz ist jedoch ungeeignet, da wir die Komponente mehrfach erstellen können möchten.
+Die logische Frage ist, warum registrieren wir die Komponente nicht einfach als klassischen Dienst, übergeben sie an den Presenter und geben sie dann in der Methode `createComponent…()` zurück? Dieser Ansatz ist jedoch ungeeignet, da wir die Komponente möglicherweise mehrmals erstellen möchten.
-Die richtige Lösung besteht darin, eine Fabrik für die Komponente zu schreiben, d. h. eine Klasse, die die Komponente für uns erstellt:
+Die richtige Lösung ist, eine Factory für die Komponente zu schreiben, also eine Klasse, die uns die Komponente erstellt:
```php
class PollControlFactory
@@ -337,17 +359,17 @@ class PollControlFactory
}
```
-Jetzt registrieren wir unseren Dienst am DI-Container zur Konfiguration:
+Diese Factory registrieren wir in unserem Container in der Konfiguration:
```neon
services:
- PollControlFactory
```
-Schließlich werden wir diese Fabrik in unserem Präsentator verwenden:
+und schließlich verwenden wir sie in unserem Presenter:
```php
-class PollPresenter extends Nette\UI\Application\Presenter
+class PollPresenter extends Nette\Application\UI\Presenter
{
public function __construct(
private PollControlFactory $pollControlFactory,
@@ -362,7 +384,7 @@ class PollPresenter extends Nette\UI\Application\Presenter
}
```
-Das Tolle daran ist, dass Nette DI solche einfachen Fabriken [generieren |dependency-injection:factory] kann, so dass man nicht den ganzen Code schreiben muss, sondern nur die Schnittstelle:
+Das Tolle ist, dass Nette DI solche einfachen Factories [generieren |dependency-injection:factory] kann, sodass statt des gesamten Codes nur ihr Interface geschrieben werden muss:
```php
interface PollControlFactory
@@ -371,21 +393,21 @@ interface PollControlFactory
}
```
-Das ist alles. Nette implementiert diese Schnittstelle intern und injiziert sie in unseren Präsentator, wo wir sie verwenden können. Außerdem werden auf magische Weise unser Parameter `$id` und die Instanz der Klasse `PollFacade` an unsere Komponente übergeben.
+Und das ist alles. Nette implementiert dieses Interface intern und übergibt es an den Presenter, wo wir es bereits verwenden können. Es fügt magischerweise auch den Parameter `$id` und eine Instanz der Klasse `PollFacade` zu unserer Komponente hinzu.
-Komponenten im Detail .[#toc-components-in-depth]
-=================================================
+Komponenten im Detail
+=====================
-Komponenten in einer Nette-Anwendung sind die wiederverwendbaren Teile einer Web-Anwendung, die wir in Seiten einbetten, was das Thema dieses Kapitels ist. Was genau sind die Fähigkeiten einer solchen Komponente?
+Komponenten in Nette Application stellen wiederverwendbare Teile einer Webanwendung dar, die wir in Seiten einfügen und denen dieses ganze Kapitel gewidmet ist. Welche Fähigkeiten hat eine solche Komponente genau?
-1) sie ist in einer Vorlage renderbar
-2) sie weiß, welcher Teil von ihr bei einer [AJAX-Anfrage |ajax#invalidation] gerendert werden soll (Snippets)
-3) er kann seinen Zustand in einer URL speichern (persistente Parameter)
-4) es hat die Fähigkeit, auf Benutzeraktionen zu reagieren (Signale)
-5) er erstellt eine hierarchische Struktur (wobei die Wurzel der Präsentator ist)
+1) Sie ist im Template renderbar.
+2) Sie weiß, [welchen Teil |ajax#Snippets] sie bei einer AJAX-Anfrage rendern soll (Snippets).
+3) Sie hat die Fähigkeit, ihren Zustand in der URL zu speichern (persistente Parameter).
+4) Sie hat die Fähigkeit, auf Benutzeraktionen zu reagieren (Signale).
+5) Sie bildet eine hierarchische Struktur (deren Wurzel der Presenter ist).
-Jede dieser Funktionen wird von einer der Klassen der Vererbungslinie ausgeführt. Die Darstellung (1 + 2) wird von [api:Nette\Application\UI\Control] übernommen, die Einbindung in den [Lebenszyklus |presenters#life-cycle-of-presenter] (3, 4) von der Klasse [api:Nette\Application\UI\Component] und die Erstellung der hierarchischen Struktur (5) von den Klassen [Container und Component |component-model:].
+Jede dieser Funktionen wird von einer der Klassen der Vererbungslinie übernommen. Das Rendern (1 + 2) übernimmt [api:Nette\Application\UI\Control], die Einbindung in den [Lebenszyklus |presenters#Lebenszyklus des Presenters] (3, 4) die Klasse [api:Nette\Application\UI\Component] und die Erstellung der hierarchischen Struktur (5) die Klassen [Container und Component |component-model:].
```
Nette\ComponentModel\Component { IComponent }
@@ -400,18 +422,18 @@ Nette\ComponentModel\Component { IComponent }
```
-Lebenszyklus der Komponente .[#toc-life-cycle-of-component]
------------------------------------------------------------
+Lebenszyklus einer Komponente
+-----------------------------
[* lifecycle-component.svg *] *** *Lebenszyklus einer Komponente* .<>
-Validierung von persistenten Parametern .[#toc-validation-of-persistent-parameters]
------------------------------------------------------------------------------------
+Validierung persistenter Parameter
+----------------------------------
-Die Werte von [persistenten Parametern |#persistent parameters], die von URLs empfangen werden, werden von der Methode `loadState()` in Eigenschaften geschrieben. Sie prüft auch, ob der für die Eigenschaft angegebene Datentyp übereinstimmt, andernfalls antwortet sie mit einem 404-Fehler und die Seite wird nicht angezeigt.
+Die Werte der [persistenten Parameter |#Persistente Parameter], die aus der URL empfangen wurden, schreibt die Methode `loadState()` in die Eigenschaften. Sie prüft auch, ob der bei der Eigenschaft angegebene Datentyp übereinstimmt, andernfalls antwortet sie mit einem 404-Fehler und die Seite wird nicht angezeigt.
-Verlassen Sie sich niemals blind auf persistente Parameter, da sie leicht vom Benutzer in der URL überschrieben werden können. So prüfen wir zum Beispiel, ob die Seitenzahl `$this->page` größer als 0 ist. Eine gute Möglichkeit, dies zu tun, ist, die oben erwähnte Methode `loadState()` zu überschreiben:
+Vertrauen Sie niemals blind persistenten Parametern, da sie vom Benutzer leicht in der URL überschrieben werden können. So überprüfen wir beispielsweise, ob die Seitenzahl `$this->page` größer als 0 ist. Ein geeigneter Weg ist, die erwähnte Methode `loadState()` zu überschreiben:
```php
class PaginatingControl extends Control
@@ -421,8 +443,8 @@ class PaginatingControl extends Control
public function loadState(array $params): void
{
- parent::loadState($params); // hier wird die $this->page gesetzt
- // auf die Prüfung der Benutzerwerte:
+ parent::loadState($params); // hier wird $this->page gesetzt
+ // es folgt die eigene Wertprüfung:
if ($this->page < 1) {
$this->error();
}
@@ -430,27 +452,27 @@ class PaginatingControl extends Control
}
```
-Der umgekehrte Prozess, d. h. das Sammeln von Werten aus dauerhaften Propertys, wird von der Methode `saveState()` übernommen.
+Der umgekehrte Prozess, also das Sammeln von Werten aus persistenten Eigenschaften, wird von der Methode `saveState()` übernommen.
-Signale in der Tiefe .[#toc-signals-in-depth]
----------------------------------------------
+Signale im Detail
+-----------------
-Ein Signal bewirkt ein Neuladen der Seite wie die ursprüngliche Anfrage (mit Ausnahme von AJAX) und ruft die Methode `signalReceived($signal)` auf, deren Standardimplementierung in der Klasse `Nette\Application\UI\Component` versucht, eine Methode aufzurufen, die aus den Worten `handle{Signal}` besteht. Die weitere Verarbeitung hängt von dem angegebenen Objekt ab. Objekte, die Nachkommen von `Component` sind (d.h. `Control` und `Presenter`), versuchen, `handle{Signal}` mit den entsprechenden Parametern aufzurufen.
+Ein Signal bewirkt das Neuladen der Seite genau wie bei der ursprünglichen Anfrage (außer wenn es per AJAX aufgerufen wird) und ruft die Methode `signalReceived($signal)` auf, deren Standardimplementierung in der Klasse `Nette\Application\UI\Component` versucht, eine Methode aufzurufen, die aus den Wörtern `handle{signal}` zusammengesetzt ist. Die weitere Verarbeitung liegt beim jeweiligen Objekt. Objekte, die von `Component` erben (d. h. `Control` und `Presenter`), reagieren, indem sie versuchen, die Methode `handle{signal}` mit den entsprechenden Parametern aufzurufen.
-Mit anderen Worten: die Definition der Methode `handle{Signal}` wird genommen und alle Parameter, die in der Anfrage empfangen wurden, werden mit den Parametern der Methode abgeglichen. Das bedeutet, dass der Parameter `id` aus der URL mit dem Parameter `$id` der Methode abgeglichen wird, `something` mit `$something` und so weiter. Und wenn die Methode nicht existiert, löst die Methode `signalReceived` [eine Ausnahme |api:Nette\Application\UI\BadSignalException] aus.
+Mit anderen Worten: Es wird die Definition der Funktion `handle{signal}` und alle mit der Anfrage übermittelten Parameter genommen, und den Argumenten werden anhand des Namens Parameter aus der URL zugewiesen, und es wird versucht, die betreffende Methode aufzurufen. Z. B. wird als Parameter `$id` der Wert des Parameters `id` aus der URL übergeben, als `$something` wird `something` aus der URL übergeben, usw. Und wenn die Methode nicht existiert, löst die Methode `signalReceived` eine [Ausnahme |api:Nette\Application\UI\BadSignalException] aus.
-Das Signal kann von jeder Komponente empfangen werden, die die Schnittstelle `SignalReceiver` implementiert, wenn sie mit dem Komponentenbaum verbunden ist.
+Ein Signal kann von jeder Komponente, jedem Presenter oder jedem Objekt empfangen werden, das das Interface `SignalReceiver` implementiert und in den Komponentenbaum eingebunden ist.
-Die Hauptempfänger von Signalen sind `Presenters` und visuelle Komponenten, die `Control` erweitern. Ein Signal ist ein Zeichen für ein Objekt, dass es etwas zu tun hat - eine Umfrage zählt eine Stimme vom Benutzer, eine Box mit Nachrichten muss sich entfalten, ein Formular wurde gesendet und muss Daten verarbeiten und so weiter.
+Die Hauptempfänger von Signalen sind `Presenter` und visuelle Komponenten, die von `Control` erben. Ein Signal soll als Zeichen für ein Objekt dienen, dass es etwas tun soll – die Umfrage soll eine Stimme vom Benutzer zählen, der Nachrichtenblock soll sich aufklappen und doppelt so viele Nachrichten anzeigen, das Formular wurde abgeschickt und soll die Daten verarbeiten und so weiter.
-Die URL für das Signal wird mit der Methode [Component::link() |api:Nette\Application\UI\Component::link()] erstellt. Als Parameter `$destination` übergeben wir den String `{signal}!` und als `$args` ein Array von Argumenten, die wir an den Signalhandler übergeben wollen. Die Signalparameter werden an die URL des aktuellen Presenters/Views angehängt. **Der Parameter `?do` in der URL bestimmt das aufgerufene Signal.
+Die URL für ein Signal erstellen wir mit der Methode [Component::link() |api:Nette\Application\UI\Component::link()]. Als Parameter `$destination` übergeben wir den String `{signal}!` und als `$args` ein Array von Argumenten, die wir dem Signal übergeben möchten. Das Signal wird immer im aktuellen Presenter und der aktuellen Action mit den aktuellen Parametern aufgerufen, die Signalparameter werden nur hinzugefügt. Zusätzlich wird ganz am Anfang der **Parameter `?do`, der das Signal bestimmt**, hinzugefügt.
-Sein Format ist `{signal}` oder `{signalReceiver}-{signal}`. `{signalReceiver}` ist der Name der Komponente im Presenter. Aus diesem Grund kann der Bindestrich nicht im Namen der Komponente vorkommen - er wird verwendet, um den Namen der Komponente und des Signals zu trennen, aber es ist möglich, mehrere Komponenten zusammenzustellen.
+Sein Format ist entweder `{signal}` oder `{signalReceiver}-{signal}`. `{signalReceiver}` ist der Name der Komponente im Presenter. Deshalb darf im Komponentennamen kein Bindestrich vorkommen – er wird zur Trennung von Komponentennamen und Signal verwendet, es ist jedoch möglich, mehrere Komponenten auf diese Weise zu verschachteln.
-Die Methode [isSignalReceiver() |api:Nette\Application\UI\Presenter::isSignalReceiver()] prüft, ob eine Komponente (erstes Argument) ein Empfänger eines Signals (zweites Argument) ist. Das zweite Argument kann weggelassen werden - dann wird festgestellt, ob die Komponente ein Empfänger eines Signals ist. Wenn der zweite Parameter `true` lautet, wird geprüft, ob die Komponente oder ihre Nachkommen Empfänger eines Signals sind.
+Die Methode [isSignalReceiver()|api:Nette\Application\UI\Presenter::isSignalReceiver()] prüft, ob eine Komponente (erstes Argument) der Empfänger eines Signals ist (zweites Argument). Das zweite Argument kann weggelassen werden – dann wird geprüft, ob die Komponente Empfänger irgendeines Signals ist. Als zweites Parameter kann `true` angegeben werden, um zu prüfen, ob nicht nur die angegebene Komponente, sondern auch einer ihrer Nachfahren Empfänger ist.
-In jeder Phase, die `handle{Signal}` vorausgeht, kann ein Signal manuell ausgeführt werden, indem die Methode [processSignal() |api:Nette\Application\UI\Presenter::processSignal()] aufgerufen wird, die die Verantwortung für die Signalausführung übernimmt. Nimmt die Empfängerkomponente (wenn nicht gesetzt, ist es der Präsentator selbst) und sendet ihr das Signal.
+In jeder Phase vor `handle{signal}` können wir das Signal manuell ausführen, indem wir die Methode [processSignal()|api:Nette\Application\UI\Presenter::processSignal()] aufrufen, die die Bearbeitung des Signals übernimmt – sie nimmt die Komponente, die als Signalempfänger bestimmt wurde (wenn kein Signalempfänger bestimmt ist, ist es der Presenter selbst) und sendet ihr das Signal.
Beispiel:
@@ -460,4 +482,4 @@ if ($this->isSignalReceiver($this, 'paging') || $this->isSignalReceiver($this, '
}
```
-Das Signal wird vorzeitig ausgeführt und wird nicht mehr aufgerufen.
+Damit wird das Signal vorzeitig ausgeführt und nicht mehr erneut aufgerufen.
diff --git a/application/de/configuration.texy b/application/de/configuration.texy
index aa8d370e08..638fba748b 100644
--- a/application/de/configuration.texy
+++ b/application/de/configuration.texy
@@ -1,58 +1,71 @@
-Anwendung konfigurieren
-***********************
+Konfiguration von Anwendungen
+*****************************
.[perex]
-Überblick über die Konfigurationsoptionen für die Nette-Anwendung.
+Übersicht über die Konfigurationsoptionen für Nette-Anwendungen.
-Anwendung .[#toc-application]
-=============================
+Application
+===========
```neon
-Anwendung:
- # zeigt das Feld "Nette Anwendung" in Tracy BlueScreen?
- debugger: ... # (bool) standardmäßig true
+application:
+ # Das "Nette Application"-Panel im Tracy BlueScreen anzeigen?
+ debugger: ... # (bool) Standard ist true
+
+ # Soll bei einem Fehler der Error-Presenter aufgerufen werden?
+ # wirkt sich nur im Entwicklungsmodus aus
+ catchExceptions: ... # (bool) Standard ist true
- # wird der error-presenter im Fehlerfall aufgerufen?
- catchExceptions: ... # (bool) steht im Produktionsmodus standardmäßig auf true
+ # Name des Error-Presenters
+ errorPresenter: Error # (string|array) Standard ist 'Nette:Error'
- # Name des Fehlermelders
- errorPresenter: Error # (string) Standardwert ist 'Nette:Error'
+ # definiert Aliase für Presenter und Aktionen
+ aliases: ...
- # definiert die Regeln für die Auflösung des Presenter-Namens in eine Klasse
+ # definiert Regeln für die Übersetzung des Presenter-Namens in eine Klasse
mapping: ...
- # werden bei schlechten Links Warnungen erzeugt?
- # hat nur im Entwicklermodus Auswirkungen
- silentLinks: ... # (bool) ist standardmäßig auf false eingestellt
+ # Erzeugen fehlerhafte Links keine Warnungen?
+ # wirkt sich nur im Entwicklungsmodus aus
+ silentLinks: ... # (bool) Standard ist false
+```
+
+Seit `nette/application` Version 3.2 kann ein Paar von Error-Presentern definiert werden:
+
+```neon
+application:
+ errorPresenter:
+ 4xx: Error4xx # für die Ausnahme Nette\Application\BadRequestException
+ 5xx: Error5xx # für andere Ausnahmen
```
-Da Fehlerpräsenter im Entwicklungsmodus standardmäßig nicht aufgerufen werden und die Fehler von Tracy angezeigt werden, hilft das Ändern des Wertes `catchExceptions` in `true` dabei, zu überprüfen, ob die Fehlerpräsenter während der Entwicklung korrekt funktionieren.
+Die Option `silentLinks` bestimmt, wie sich Nette im Entwicklungsmodus verhält, wenn die Linkgenerierung fehlschlägt (z. B. weil der Presenter nicht existiert usw.). Der Standardwert `false` bedeutet, dass Nette einen `E_USER_WARNING`-Fehler auslöst. Durch Setzen auf `true` wird diese Fehlermeldung unterdrückt. In der Produktionsumgebung wird `E_USER_WARNING` immer ausgelöst. Dieses Verhalten kann auch durch Setzen der Presenter-Variable [$invalidLinkMode |creating-links#Ungültige Links] beeinflusst werden.
-Die Option `silentLinks` legt fest, wie sich Nette im Entwicklermodus verhält, wenn die Link-Generierung fehlschlägt (z. B. weil kein Presenter vorhanden ist usw.). Der Standardwert `false` bedeutet, dass Nette `E_USER_WARNING` auslöst. Die Einstellung `true` unterdrückt diese Fehlermeldung. In einer Produktionsumgebung wird immer `E_USER_WARNING` aufgerufen. Wir können dieses Verhalten auch beeinflussen, indem wir die Presenter-Variable [$invalidLinkMode |creating-links#Invalid Links] setzen.
+[Aliase vereinfachen das Verlinken |creating-links#Aliase] zu häufig verwendeten Presentern.
-Das [Mapping definiert die Regeln |modules#mapping], nach denen der Klassenname aus dem Presenter-Namen abgeleitet wird.
+[Mapping definiert Regeln |directory-structure#Presenter-Mapping], nach denen der Klassenname vom Presenter-Namen abgeleitet wird.
-Automatische Registrierung von Präsentatoren .[#toc-automatic-registration-of-presenters]
------------------------------------------------------------------------------------------
+Automatische Registrierung von Presentern
+-----------------------------------------
-Nette fügt Presenter automatisch als Dienste zum DI-Container hinzu, was ihre Erstellung erheblich beschleunigt. Wie Nette Presenter findet, kann konfiguriert werden:
+Nette fügt Presenter automatisch als Dienste zum DI-Container hinzu, was deren Erstellung erheblich beschleunigt. Wie Nette Presenter findet, kann konfiguriert werden:
```neon
-Anwendung:
- # um nach Präsentatoren in der Composer-Klassenkarte zu suchen?
- scanComposer: ... # (bool) standardmäßig auf true
+application:
+ # Presenter in der Composer Class Map suchen?
+ scanComposer: ... # (bool) Standard ist true
- # eine Maske, die mit der Klasse und dem Dateinamen übereinstimmen muss
- scanFilter: ... # (string) Standardwert ist '*Presenter'.
+ # Maske, der Klassen- und Dateiname entsprechen müssen
+ scanFilter: ... # (string) Standard ist '*Presenter'
- # in welchen Verzeichnissen soll nach Präsentatoren gesucht werden?
- scanDirs: # (string[]|false) Standardwert ist '%appDir%'
+ # In welchen Verzeichnissen sollen Presenter gesucht werden?
+ scanDirs: # (string[]|false) Standard ist '%appDir%'
- %vendorDir%/mymodule
```
-Die in `scanDirs` aufgeführten Verzeichnisse überschreiben nicht den Standardwert `%appDir%`, sondern ergänzen ihn, so dass `scanDirs` die beiden Pfade `%appDir%` und `%vendorDir%/mymodule` enthält. Wenn wir das Standardverzeichnis überschreiben wollen, verwenden wir ein [Ausrufezeichen |dependency-injection:configuration#Merging]:
+Die in `scanDirs` angegebenen Verzeichnisse überschreiben nicht den Standardwert `%appDir%`, sondern ergänzen ihn, sodass `scanDirs` beide Pfade `%appDir%` und `%vendorDir%/mymodule` enthält. Wenn wir das Standardverzeichnis auslassen möchten, verwenden wir ein [Ausrufezeichen |dependency-injection:configuration#Zusammenführen], das den Wert überschreibt:
```neon
application:
@@ -60,64 +73,73 @@ application:
- %vendorDir%/mymodule
```
-Das Scannen von Verzeichnissen kann durch die Einstellung false ausgeschaltet werden. Es wird nicht empfohlen, das automatische Hinzufügen von Präsentatoren vollständig zu unterdrücken, da sonst die Leistung der Anwendung beeinträchtigt wird.
+Das Scannen von Verzeichnissen kann durch Angabe des Wertes false deaktiviert werden. Wir empfehlen nicht, das automatische Hinzufügen von Presentern vollständig zu unterdrücken, da dies die Leistung der Anwendung beeinträchtigen würde.
-Latte .[#toc-latte]
-===================
+Latte-Templates
+===============
-Diese Einstellung wirkt sich global auf das Verhalten von Latte in Komponenten und Presentern aus.
+Mit dieser Einstellung kann das Verhalten von Latte in Komponenten und Presentern global beeinflusst werden.
```neon
-Latte:
- # zeigt das Latte-Panel in der Tracy Bar für die Hauptvorlage (true) oder für alle Komponenten (all)?
- debugger: ... # (true|false|'all') ist standardmäßig true
+latte:
+ # Latte-Panel in der Tracy Bar für das Haupttemplate (true) oder alle Komponenten (all) anzeigen?
+ debugger: ... # (true|false|'all') Standard ist true
+
+ # generiert Templates mit dem Header declare(strict_types=1)
+ strictTypes: ... # (bool) Standard ist false
+
+ # schaltet den [strengen Parser-Modus |latte:develop#strict-mode] ein
+ strictParsing: ... # (bool) Standard ist false
+
+ # aktiviert die [Überprüfung des generierten Codes |latte:develop#checking-generated-code]
+ phpLinter: ... # (string) Standard ist null
- # erzeugt Vorlagen mit declare(strict_types=1)
- strictTypes: ... # (bool) ist standardmäßig false
+ # setzt die Locale
+ locale: cs_CZ # (string) Standard ist null
- # Klasse von $this->template
- templateClass: App\MyTemplateClass # Standardwert ist Nette\Bridges\ApplicationLatte\DefaultTemplate
+ # Klasse des $this->template-Objekts
+ templateClass: App\MyTemplateClass # Standard ist Nette\Bridges\ApplicationLatte\DefaultTemplate
```
-Wenn Sie Latte Version 3 verwenden, können Sie neue [Erweiterungen |latte:creating-extension] mit hinzufügen:
+Wenn Sie Latte Version 3 verwenden, können Sie neue [Erweiterungen |latte:extending-latte#Latte Extension] hinzufügen mit:
```neon
latte:
extensions:
- - Latte\Essential\TranslatorExtension
+ - Latte\Essential\TranslatorExtension(@Nette\Localization\Translator)
```
-/--comment
-
-
-
+Wenn Sie Latte Version 2 verwenden, können Sie neue Tags (Makros) registrieren, indem Sie entweder den Klassennamen oder eine Referenz auf einen Dienst angeben. Standardmäßig wird die Methode `install()` aufgerufen, dies kann jedoch geändert werden, indem ein anderer Methodenname angegeben wird:
+```neon
+latte:
+ # Registrierung benutzerdefinierter Latte-Tags
+ macros:
+ - App\MyLatteMacros::register # statische Methode, Klassenname oder Callable
+ - @App\MyLatteMacrosFactory # Dienst mit install()-Methode
+ - @App\MyLatteMacrosFactory::register # Dienst mit register()-Methode
+
+services:
+ - App\MyLatteMacrosFactory
+```
-
-
-
-
-
-\--
-
-
-Routing .[#toc-routing]
-=======================
+Routing
+=======
Grundeinstellungen:
```neon
routing:
- # zeigt Routing-Panel in Tracy Bar?
- debugger: ... # (bool) standardmäßig true
+ # Routing-Panel in der Tracy Bar anzeigen?
+ debugger: ... # (bool) Standard ist true
- # Router in DI-Container serialisieren?
- cache: ... # (bool) Standardwert ist false
+ # serialisiert den Router in den DI-Container
+ cache: ... # (bool) Standard ist false
```
-Router werden normalerweise in der Klasse [RouterFactory |routing#Route Collection] definiert. Alternativ können Router auch in der Konfiguration mit `mask: action` Paaren definiert werden, aber diese Methode bietet keine so große Variationsbreite an Einstellungen:
+Das Routing wird normalerweise in der Klasse [RouterFactory |routing#Routen-Sammlung] definiert. Alternativ können Routen auch in der Konfiguration über Paare `Maske: Aktion` definiert werden, aber diese Methode bietet nicht so viel Flexibilität bei den Einstellungen:
```neon
routing:
@@ -127,8 +149,8 @@ routing:
```
-Konstanten .[#toc-constants]
-============================
+Konstanten
+==========
Erstellen von PHP-Konstanten.
@@ -137,18 +159,33 @@ constants:
Foobar: 'baz'
```
-Die Konstante `Foobar` wird nach dem Start der Anwendung erstellt.
+Nach dem Start der Anwendung wird die Konstante `Foobar` erstellt.
.[note]
-Konstanten sollten nicht als global verfügbare Variablen dienen. Um Werte an Objekte zu übergeben, verwenden Sie [Dependency Injection |dependency-injection:passing-dependencies].
+Konstanten sollten nicht als global verfügbare Variablen dienen. Verwenden Sie [Dependency Injection |dependency-injection:passing-dependencies], um Werte an Objekte zu übergeben.
PHP
===
-Sie können PHP-Direktiven setzen. Eine Übersicht über alle Direktiven finden Sie auf [php.net |https://www.php.net/manual/en/ini.list.php].
+Einstellen von PHP-Direktiven. Eine Übersicht über alle Direktiven finden Sie auf [php.net |https://www.php.net/manual/en/ini.list.php].
```neon
php:
date.timezone: Europe/Prague
```
+
+
+DI-Dienste
+==========
+
+Diese Dienste werden dem DI-Container hinzugefügt:
+
+| Name | Typ | Beschreibung
+|----------------------------------------------------------------------------------------------------------
+| `application.application` | [api:Nette\Application\Application] | [Starter der gesamten Anwendung |how-it-works#Nette Application]
+| `application.linkGenerator` | [api:Nette\Application\LinkGenerator] | [LinkGenerator |creating-links#LinkGenerator]
+| `application.presenterFactory` | [api:Nette\Application\PresenterFactory] | Factory für Presenter
+| `application.###` | [api:Nette\Application\UI\Presenter] | einzelne Presenter
+| `latte.latteFactory` | [api:Nette\Bridges\ApplicationLatte\LatteFactory] | Factory für das `Latte\Engine`-Objekt
+| `latte.templateFactory` | [api:Nette\Application\UI\TemplateFactory] | Factory für [`$this->template` |templates]
diff --git a/application/de/creating-links.texy b/application/de/creating-links.texy
index 1ec3fbd1e9..ff63ee2419 100644
--- a/application/de/creating-links.texy
+++ b/application/de/creating-links.texy
@@ -1,160 +1,160 @@
-URL-Links erstellen
-*******************
+Erstellen von URL-Links
+***********************
()` oder `action()` Methode angegeben sind, übertragen. Wenn wir uns also auf den Seiten `Product:show` und `id:123` befinden, wird der Link zu `this` auch diesen Parameter übergeben.
+Gleichzeitig werden auch alle Parameter übertragen, die in der Signatur der Methode `action()` oder `render()` angegeben sind, falls `action()` nicht definiert ist. Wenn wir also auf der Seite `Product:show` mit `id: 123` sind, übergibt der Link auf `this` auch diesen Parameter.
-Natürlich ist es auch möglich, die Parameter direkt anzugeben:
+Natürlich ist es möglich, Parameter direkt anzugeben:
```latte
-refresh
+aktualisieren
```
-Die Funktion `isLinkCurrent()` ermittelt, ob das Ziel des Links mit der aktuellen Seite identisch ist. Dies kann z. B. in einer Vorlage zur Unterscheidung von Links usw. verwendet werden.
+Die Funktion `isLinkCurrent()` prüft, ob das Ziel des Links mit der aktuellen Seite übereinstimmt. Dies kann beispielsweise in einem Template verwendet werden, um Links zu unterscheiden usw.
-Die Parameter sind die gleichen wie bei der Methode `link()`, aber es ist auch möglich, den Platzhalter `*` anstelle einer bestimmten Aktion zu verwenden, d.h. jede Aktion des Präsentators.
+Die Parameter sind die gleichen wie bei der Methode `link()`, zusätzlich ist es jedoch möglich, anstelle einer konkreten Aktion den Platzhalter `*` anzugeben, der jede Aktion des gegebenen Presenters bedeutet.
```latte
{if !isLinkCurrent('Admin:login')}
- Přihlaste se
+ Anmelden
{/if}
@@ -162,58 +162,58 @@ Die Parameter sind die gleichen wie bei der Methode `link()`, aber es ist auch m
```
-Eine abgekürzte Form kann in Kombination mit `n:href` in einem einzelnen Element verwendet werden:
+In Kombination mit `n:href` in einem Element kann eine verkürzte Form verwendet werden:
```latte
-...
+...
```
-Das Platzhalterzeichen "*" ersetzt nur die Aktion des Präsentators, nicht den Präsentator selbst.
+Der Platzhalter `*` kann nur anstelle der Aktion verwendet werden, nicht für den Presenter.
-Um herauszufinden, ob wir uns in einem bestimmten Modul oder dessen Untermodul befinden, können wir die Funktion `isModuleCurrent(moduleName)` verwenden.
+Um festzustellen, ob wir uns in einem bestimmten Modul oder dessen Submodul befinden, verwenden wir die Methode `isModuleCurrent(moduleName)`.
```latte
-
+
...
```
-Links zu Signal .[#toc-links-to-signal]
-=======================================
+Links zu Signalen
+=================
-Das Ziel des Links kann nicht nur der Präsentator und die Aktion sein, sondern auch das [Signal |components#Signal] (sie rufen die Methode `handle()`). Die Syntax lautet wie folgt:
+Das Ziel eines Links muss nicht nur ein Presenter und eine Aktion sein, sondern auch ein [Signal |components#Signal] (sie rufen die Methode `handle()` auf). Dann lautet die Syntax wie folgt:
```
[//] [sub-component:]signal! [#fragment]
```
-Das Signal ist also durch ein Ausrufezeichen gekennzeichnet:
+Das Signal wird also durch ein Ausrufezeichen unterschieden:
```latte
-signal
+Signal
```
-Sie können auch einen Verweis auf das Signal der Unterkomponente (oder Unter-Unterkomponente) erstellen:
+Es kann auch ein Link zum Signal einer Subkomponente (oder Sub-Subkomponente) erstellt werden:
```latte
-signal
+Signal
```
-Verknüpfungen in der Komponente .[#toc-links-in-component]
-==========================================================
+Links in einer Komponente
+=========================
-Da [Komponenten |components] separate, wiederverwendbare Einheiten sind, die keine Beziehungen zu umgebenden Präsentatoren haben sollten, funktionieren die Links etwas anders. Das Latte-Attribut `n:href` und das Tag `{link}` sowie Komponentenmethoden wie `link()` und andere betrachten immer das Ziel **als Signalnamen**. Daher ist es nicht notwendig, ein Ausrufezeichen zu verwenden:
+Da [Komponenten |components] separate wiederverwendbare Einheiten sind, die keine Bindungen an umgebende Presenter haben sollten, funktionieren Links hier etwas anders. Das Latte-Attribut `n:href` und der Tag `{link}` sowie Komponentenmethoden wie `link()` und andere betrachten das Linkziel **immer als den Namen des Signals**. Daher ist es nicht notwendig, ein Ausrufezeichen anzugeben:
```latte
-signal, not an action
+Signal, nicht Aktion
```
-Wenn wir auf Präsentatoren in der Komponentenvorlage verlinken wollen, verwenden wir das Tag `{plink}`:
+Wenn wir im Template einer Komponente auf Presenter verlinken möchten, verwenden wir dazu den Tag `{plink}`:
```latte
-home
+Startseite
```
oder im Code
@@ -223,17 +223,41 @@ $this->getPresenter()->link('Home:default')
```
-Ungültige Links .[#toc-invalid-links]
-=====================================
+Aliase .{data-version:v3.2.2}
+=============================
-Es kann vorkommen, dass wir einen ungültigen Link erstellen - entweder weil er auf einen nicht existierenden Presenter verweist, oder weil er mehr Parameter übergibt, als die Zielmethode in ihrer Signatur erhält, oder wenn es keine generierte URL für die angestrebte Aktion geben kann. Was mit ungültigen Links zu tun ist, wird durch die statische Variable `Presenter::$invalidLinkMode` bestimmt. Sie kann einen der folgenden Werte (Konstanten) haben:
+Manchmal kann es nützlich sein, dem Paar Presenter:Aktion einen leicht zu merkenden Alias zuzuordnen. Zum Beispiel die Startseite `Front:Home:default` einfach als `home` benennen oder `Admin:Dashboard:default` als `admin`.
-- `Presenter::InvalidLinkSilent` - stiller Modus, gibt das Symbol `#` als URL zurück
-- `Presenter::InvalidLinkWarning` - E_USER_WARNING wird erzeugt
-- `Presenter::InvalidLinkTextual` - visuelle Warnung, der Fehlertext wird im Link angezeigt
-- `Presenter::InvalidLinkException` - Es wird eine InvalidLinkException ausgelöst
+Aliase werden in der [Konfiguration |configuration] unter dem Schlüssel `application › aliases` definiert:
-Die Standardeinstellung im Produktionsmodus ist `InvalidLinkWarning` und im Entwicklungsmodus ist `InvalidLinkWarning | InvalidLinkTextual`. `InvalidLinkWarning` beendet das Skript in der Produktionsumgebung nicht, aber die Warnung wird protokolliert. In der Entwicklungsumgebung fängt [Tracy |tracy:] die Warnung ab und zeigt den Fehlerbluescreen an. Wenn `InvalidLinkTextual` gesetzt ist, geben Presenter und Komponenten die Fehlermeldung als URL zurück, die mit `#error:` beginnt. Um solche Links sichtbar zu machen, können wir eine CSS-Regel zu unserem Stylesheet hinzufügen:
+```neon
+application:
+ aliases:
+ home: Front:Home:default
+ admin: Admin:Dashboard:default
+ sign: Front:Sign:in
+```
+
+In Links werden sie dann mit einem At-Zeichen geschrieben, zum Beispiel:
+
+```latte
+Administration
+```
+
+Sie werden auch in allen Methoden unterstützt, die mit Links arbeiten, wie `redirect()` und ähnliche.
+
+
+Ungültige Links
+===============
+
+Es kann vorkommen, dass wir einen ungültigen Link erstellen – entweder weil er auf einen nicht existierenden Presenter verweist, oder weil er mehr Parameter übergibt, als die Zielmethode in ihrer Signatur akzeptiert, oder wenn für die Zielaktion keine URL generiert werden kann. Wie mit ungültigen Links umgegangen wird, bestimmt die statische Variable `Presenter::$invalidLinkMode`. Diese kann eine Kombination der folgenden Werte (Konstanten) annehmen:
+
+- `Presenter::InvalidLinkSilent` - stiller Modus, als URL wird das Zeichen # zurückgegeben
+- `Presenter::InvalidLinkWarning` - es wird eine E_USER_WARNING-Warnung ausgegeben, die im Produktionsmodus protokolliert wird, aber die Skriptausführung nicht unterbricht
+- `Presenter::InvalidLinkTextual` - visuelle Warnung, gibt den Fehler direkt im Link aus
+- `Presenter::InvalidLinkException` - es wird eine InvalidLinkException-Ausnahme ausgelöst
+
+Die Standardeinstellung ist `InvalidLinkWarning` im Produktionsmodus und `InvalidLinkWarning | InvalidLinkTextual` im Entwicklungsmodus. `InvalidLinkWarning` im Produktionsmodus führt nicht zur Unterbrechung des Skripts, aber die Warnung wird protokolliert. Im Entwicklungsmodus wird sie von [Tracy |tracy:] abgefangen und zeigt einen Bluescreen an. `InvalidLinkTextual` funktioniert so, dass als URL eine Fehlermeldung zurückgegeben wird, die mit den Zeichen `#error:` beginnt. Damit solche Links auf den ersten Blick erkennbar sind, ergänzen wir unser CSS:
```css
a[href^="#error:"] {
@@ -242,7 +266,7 @@ a[href^="#error:"] {
}
```
-Wenn wir nicht wollen, dass in der Entwicklungsumgebung Warnungen ausgegeben werden, können wir in der [Konfiguration |configuration] den Modus "Stiller ungültiger Link" einschalten.
+Wenn wir nicht möchten, dass im Entwicklungsmodus Warnungen erzeugt werden, können wir den stillen Modus direkt in der [Konfiguration |configuration] einstellen.
```neon
application:
@@ -250,13 +274,13 @@ application:
```
-LinkGenerator .[#toc-linkgenerator]
-===================================
+LinkGenerator
+=============
-Wie erstellt man Links mit der Methode `link()` comfort, aber ohne die Anwesenheit eines Presenters? Deshalb gibt es hier [api:Nette\Application\LinkGenerator].
+Wie erstellt man Links mit ähnlichem Komfort wie die Methode `link()`, aber ohne die Anwesenheit eines Presenters? Dafür gibt es den [api:Nette\Application\LinkGenerator].
-LinkGenerator ist ein Dienst, den Sie über den Konstruktor übergeben können und dann Links mit seiner Methode `link()` erstellen.
+Der LinkGenerator ist ein Dienst, den Sie sich über den Konstruktor übergeben lassen und dann Links mit seiner Methode `link()` erstellen können.
-Es gibt einen Unterschied zu Presentern. LinkGenerator erstellt alle Links als absolute URLs. Außerdem gibt es keinen "aktuellen Präsentator", so dass es nicht möglich ist, nur den Namen der Aktion `link('default')` oder die relativen Pfade zu den [Modulen |modules] anzugeben.
+Im Vergleich zu Presentern gibt es hier einen Unterschied. Der LinkGenerator erstellt alle Links direkt als absolute URLs. Außerdem gibt es keinen "aktuellen Presenter", sodass man als Ziel nicht nur den Aktionsnamen `link('default')` angeben oder relative Pfade zu Modulen verwenden kann.
-Ungültige Links führen immer zu `Nette\Application\UI\InvalidLinkException`.
+Ungültige Links lösen immer eine `Nette\Application\UI\InvalidLinkException` aus.
diff --git a/application/de/directory-structure.texy b/application/de/directory-structure.texy
new file mode 100644
index 0000000000..c7c34615b7
--- /dev/null
+++ b/application/de/directory-structure.texy
@@ -0,0 +1,526 @@
+Verzeichnisstruktur der Anwendung
+*********************************
+
+()`. Wir empfehlen jedoch, Presenter mit einer oder so wenigen Aktionen wie möglich zu entwerfen.
+Ein Presenter kann mehrere Aktionen bedienen, also mehrere Methoden `render()` haben. Wir empfehlen jedoch, Presenter mit einer oder möglichst wenigen Aktionen zu entwerfen.
-So wurde die Methode `renderShow(123)` aufgerufen, deren Code ein fiktives Beispiel ist, aber Sie können daran sehen, wie die Daten an die Vorlage übergeben werden, d.h. durch Schreiben an `$this->template`.
+Also, die Methode `renderShow(123)` wurde aufgerufen, deren Code zwar ein fiktives Beispiel ist, aber Sie können daran sehen, wie Daten an das Template übergeben werden, nämlich durch Schreiben in `$this->template`.
-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.
+Anschließend gibt der Presenter eine Antwort zurück. Das kann eine HTML-Seite, ein Bild, ein XML-Dokument, das Senden einer Datei von der Festplatte, JSON oder auch eine Weiterleitung auf eine andere Seite sein. Wichtig ist, dass wenn wir nicht explizit sagen, wie geantwortet werden soll (was der Fall bei `ProductPresenter` ist), die Antwort das Rendern eines Templates mit einer HTML-Seite sein wird. Warum? Weil wir in 99 % der Fälle ein Template rendern wollen, daher nimmt der Presenter dieses Verhalten als Standard an und möchte uns die Arbeit erleichtern. Das ist der Sinn 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, welches Template gerendert werden soll, den Pfad dazu leitet er selbst ab. Im Falle der Aktion `show` versucht er einfach, das Template `show.latte` im Verzeichnis der Klasse `ProductPresenter` zu laden. Ebenso versucht er, das Layout in der Datei `@layout.latte` zu finden (mehr dazu unter [Template-Suche |templates#Finden von Vorlagen]).
-- `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].
+Und anschließend rendert er die Templates. Damit ist die Aufgabe des Presenters und der gesamten Anwendung erfüllt und das Werk vollendet. Wenn das Template nicht existiert, wird eine Seite mit dem Fehler 404 zurückgegeben. Mehr über Presenter erfahren Sie auf der Seite [Presenter |presenters].
[* request-flow.svg *]
-Um sicherzugehen, versuchen wir, den gesamten Prozess mit einer etwas anderen URL zu rekapitulieren:
+Zur Sicherheit versuchen wir, den gesamten Prozess mit einer etwas anderen URL zu rekapitulieren:
-1) Die URL lautet dann `https://example.com`
-2) wir booten die Anwendung, erstellen einen Container und starten `Application::run()`
-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
+1) Die URL lautet `https://example.com`
+2) Wir booten die Anwendung, der DI-Container wird erstellt und `Application::run()` wird gestartet
+3) Der Router dekodiert die URL als Paar `Home:default`
+4) Ein Objekt der Klasse `HomePresenter` wird erstellt
+5) Die Methode `renderDefault()` wird aufgerufen (falls sie existiert)
+6) Das Template z.B. `default.latte` mit dem Layout z.B. `@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.
+Vielleicht sind Sie jetzt auf viele neue Begriffe gestoßen, aber wir glauben, dass sie Sinn ergeben. Die Entwicklung von Anwendungen in Nette ist unglaublich entspannt.
-Schablonen .[#toc-templates]
-============================
+Templates
+=========
-Für die Vorlagen verwendet Nette das [Latte-Vorlagensystem |latte:]. Deshalb enden die Dateien mit Vorlagen mit `.latte`. Latte wird verwendet, weil es das sicherste Templatesystem für PHP und gleichzeitig das intuitivste System ist. Sie müssen nicht viel Neues lernen, Sie müssen nur PHP und ein paar Latte-Tags kennen. Sie werden alles [in der Dokumentation |latte:] finden.
+Wo wir schon bei Templates sind, in Nette wird das Template-System [Latte |latte:] verwendet. Daher auch die Endungen `.latte` bei den Templates. Latte wird zum einen verwendet, weil es das sicherste Template-System für PHP ist, und zum anderen auch das intuitivste System. Sie müssen nicht viel Neues lernen, Sie kommen mit PHP-Kenntnissen und ein paar Tags aus. Alles erfahren Sie [in der Dokumentation |templates].
-In der Vorlage [erstellen wir eine Verknüpfung |creating-links] zu anderen Moderatoren & Aktionen wie folgt:
+Im Template werden [Links erstellt |creating-links] zu anderen Presentern & Aktionen wie folgt:
```latte
-product detail
+Produktdetail
```
-Schreiben Sie einfach das bekannte `Presenter:action` -Paar anstelle der echten URL und fügen Sie beliebige Parameter ein. Der Trick ist `n:href`, das besagt, dass dieses Attribut von Nette verarbeitet wird. Und es wird erzeugt:
+Einfach statt der realen URL schreiben Sie das bekannte Paar `Presenter:action` und geben eventuelle Parameter an. Der Trick liegt im `n:href`, das besagt, dass dieses Attribut von Nette verarbeitet wird. Und es generiert:
```latte
-product detail
+Produktdetail
```
-Der bereits erwähnte Router ist für die Generierung der URL zuständig. Die Router in Nette sind insofern einzigartig, als sie nicht nur Transformationen von einer URL in ein Presenter:Action-Paar durchführen können, sondern auch umgekehrt eine URL aus dem Namen des Presenters + Action + Parameter generieren können.
-Dadurch kann man in Nette die Form der URL in der gesamten fertigen Anwendung komplett ändern, ohne auch nur ein einziges Zeichen in der Vorlage oder dem Presenter zu ändern, indem man einfach den Router modifiziert.
-Und dank dessen funktioniert die so genannte Kanonisierung, ein weiteres einzigartiges Feature von Nette, das die SEO (Optimierung der Auffindbarkeit im Internet) verbessert, indem es automatisch das Vorhandensein von doppeltem Inhalt unter verschiedenen URLs verhindert.
-Viele Programmierer finden das erstaunlich.
+Die Generierung der URL übernimmt der bereits erwähnte Router. Denn Router in Nette sind außergewöhnlich, da sie nicht nur Transformationen von URL zum Paar Presenter:Aktion durchführen können, sondern auch umgekehrt, also aus dem Namen des Presenters + Aktion + Parametern eine URL generieren. Dadurch können Sie in Nette die Formen der URLs in der gesamten fertigen Anwendung vollständig ändern, ohne ein einziges Zeichen im Template oder Presenter zu ändern. Nur durch die Anpassung des Routers. Dadurch funktioniert auch die sogenannte Kanonisierung, was eine weitere einzigartige Eigenschaft von Nette ist, die zu besserem SEO (Optimierung der Auffindbarkeit im Internet) beiträgt, indem sie automatisch die Existenz von doppeltem Inhalt unter verschiedenen URLs verhindert. Viele Programmierer finden das erstaunlich.
-Interaktive Komponenten .[#toc-interactive-components]
-======================================================
+Interaktive Komponenten
+=======================
-Es gibt noch eine weitere Sache, die wir Ihnen über Presenter erzählen wollen: Sie haben ein eingebautes Komponentensystem. Die Älteren unter Ihnen erinnern sich vielleicht an etwas Ähnliches aus Delphi oder ASP.NET Web Forms. React oder Vue.js bauen auf etwas entfernt Ähnlichem auf. In der Welt der PHP-Frameworks ist dies eine völlig einzigartige Funktion.
+Über Presenter müssen wir Ihnen noch eine Sache verraten: Sie haben ein eingebautes Komponentensystem. Etwas Ähnliches kennen Ältere vielleicht aus Delphi oder ASP.NET Web Forms, auf etwas entfernt Ähnlichem bauen React oder Vue.js auf. In der Welt der PHP-Frameworks ist dies eine absolut einzigartige Angelegenheit.
-Komponenten sind separate wiederverwendbare Einheiten, die wir in Seiten (d.h. Präsentatoren) einfügen. Dabei kann es sich um [Formulare |forms:in-presenter], [Datenfelder |https://componette.org/contributte/datagrid/], Menüs, Umfragen, eigentlich um alles handeln, was für eine wiederholte Verwendung sinnvoll ist. Wir können unsere eigenen Komponenten erstellen oder eine der [zahlreichen |https://componette.org] Open-Source-Komponenten verwenden.
+Komponenten sind eigenständige wiederverwendbare Einheiten, die wir in Seiten (also Presenter) einfügen. Das können [Formulare |forms:in-presenter], [Datagrids |https://componette.org/contributte/datagrid/], Menüs, Abstimmungsumfragen sein, eigentlich alles, was sinnvoll wiederverwendet werden kann. Wir können eigene Komponenten erstellen oder einige aus dem [riesigen Angebot |https://componette.org] an Open-Source-Komponenten verwenden.
-Komponenten verändern den Ansatz der Anwendungsentwicklung grundlegend. Sie eröffnen neue Möglichkeiten, Seiten aus vordefinierten Einheiten zusammenzustellen. Und sie haben etwas mit [Hollywood |components#Hollywood style] gemeinsam.
+Komponenten beeinflussen grundlegend den Ansatz zur Anwendungsentwicklung. Sie eröffnen Ihnen neue Möglichkeiten, Seiten aus vorgefertigten Einheiten zusammenzusetzen. Und außerdem haben sie etwas mit [Hollywood gemeinsam |components#Hollywood Style].
-DI-Container und Konfiguration .[#toc-di-container-and-configuration]
-=====================================================================
+DI-Container und Konfiguration
+==============================
-Der DI-Container (Fabrik für Objekte) ist das Herzstück der gesamten Anwendung.
+Der DI-Container oder die Objekt-Factory ist das Herz der gesamten Anwendung.
-Keine Sorge, es handelt sich nicht um eine magische Blackbox, wie es nach den vorangegangenen Worten den Anschein haben könnte. Eigentlich handelt es sich um eine ziemlich langweilige PHP-Klasse, die von Nette generiert und in einem Cache-Verzeichnis gespeichert wird. Sie hat eine Menge Methoden mit dem Namen `createServiceAbcd()` und jede von ihnen erzeugt ein Objekt und gibt es zurück. Ja, es gibt auch eine Methode `createServiceApplication()`, die `Nette\Application\Application` erzeugt, die wir in der Datei `index.php` benötigen, um die Anwendung auszuführen. Und es gibt Methoden zur Erzeugung einzelner Präsentatoren. Und so weiter.
+Keine Sorge, es ist keine magische Blackbox, wie es vielleicht aus den vorherigen Zeilen scheinen mag. Eigentlich ist es eine ziemlich langweilige PHP-Klasse, die Nette generiert und im Cache-Verzeichnis speichert. Sie hat viele Methoden namens `createServiceAbcd()` und jede von ihnen kann ein bestimmtes Objekt erstellen und zurückgeben. Ja, es gibt auch eine Methode `createServiceApplication()`, die `Nette\Application\Application` erstellt, das wir in der Datei `index.php` zum Starten der Anwendung benötigten. Und es gibt Methoden, die einzelne Presenter erstellen. Und so weiter.
-Die Objekte, die der DI-Container erzeugt, werden aus irgendeinem Grund Dienste genannt.
+Objekte, die der DI-Container erstellt, werden aus irgendeinem Grund Dienste genannt.
-Das Besondere an dieser Klasse ist, dass sie nicht von Ihnen programmiert wird, sondern von dem Framework. Es generiert den PHP-Code und speichert ihn auf der Festplatte. Sie geben lediglich Anweisungen, welche Objekte der Container wie genau erzeugen soll. Und diese Anweisungen werden in [Konfigurationsdateien |bootstrap#DI Container Configuration] im [NEON-Format |neon:format] geschrieben und haben daher die Endung `.neon`.
+Was an dieser Klasse wirklich besonders ist, ist, dass nicht Sie sie programmieren, sondern das Framework. Es generiert tatsächlich den PHP-Code und speichert ihn auf der Festplatte. Sie geben nur Anweisungen, welche Objekte der Container erstellen können soll und wie genau. Und diese Anweisungen sind in [Konfigurationsdateien |bootstrapping#Konfiguration des DI-Containers] geschrieben, für die das Format [NEON|neon:format] verwendet wird und die daher auch die Erweiterung `.neon` haben.
-Die Konfigurationsdateien dienen nur dazu, den DI-Container zu instruieren. Wenn ich also zum Beispiel die Option `expiration: 14 days` im Abschnitt [Session |http:configuration#Session] angebe, wird der DI-Container bei der Erstellung des `Nette\Http\Session` -Objekts, das die Session repräsentiert, seine Methode `setExpiration('14 days')` aufrufen, und damit wird die Konfiguration Wirklichkeit.
+Konfigurationsdateien dienen rein dazu, den DI-Container zu instruieren. Wenn ich also zum Beispiel im Abschnitt [session |http:configuration#Session] die Option `expiration: 14 days` angebe, ruft der DI-Container beim Erstellen des Objekts `Nette\Http\Session`, das die Session repräsentiert, dessen Methode `setExpiration('14 days')` auf und damit wird die Konfiguration Realität.
-Es steht ein ganzes Kapitel für Sie bereit, in dem beschrieben wird, was [konfiguriert |nette:configuring] werden kann und wie Sie [Ihre eigenen Dienste definieren |dependency-injection:services] können.
+Es gibt für Sie ein ganzes Kapitel, das beschreibt, was alles [konfiguriert |nette:configuring] werden kann und wie man [eigene Dienste definiert |dependency-injection:services].
-Sobald Sie sich mit der Erstellung von Diensten befassen, werden Sie auf das Wort [Autowiring |dependency-injection:autowiring] stoßen. Das ist ein Gadget, das Ihnen das Leben unglaublich erleichtern wird. Es kann Objekte automatisch dort übergeben, wo Sie sie brauchen (z. B. in den Konstruktoren Ihrer Klassen), ohne dass Sie etwas tun müssen. Sie werden feststellen, dass der DI-Container in Nette ein kleines Wunderwerk ist.
+Sobald Sie etwas tiefer in die Erstellung von Diensten eintauchen, werden Sie auf das Wort [Autowiring |dependency-injection:autowiring] stoßen. Das ist ein Feature, das Ihnen das Leben unglaublich vereinfacht. Es kann Objekte automatisch dorthin übergeben, wo Sie sie benötigen (z.B. in den Konstruktoren Ihrer Klassen), ohne dass Sie etwas tun müssen. Sie werden feststellen, dass der DI-Container in Nette ein kleines Wunder ist.
-Wie geht es weiter? .[#toc-what-next]
-=====================================
+Wohin als nächstes?
+===================
-Wir haben die Grundprinzipien von Anwendungen in Nette durchgenommen. Bisher sehr oberflächlich, aber Sie werden bald in die Tiefe gehen und schließlich wunderbare Webanwendungen erstellen. Wo soll es weitergehen? Haben Sie schon das Tutorial [Erstellen Sie Ihre erste Anwendung |quickstart:] ausprobiert?
+Wir sind die Grundprinzipien von Anwendungen in Nette durchgegangen. Bisher sehr oberflächlich, aber bald werden Sie in die Tiefe vordringen und mit der Zeit wunderbare Webanwendungen erstellen. Wohin soll es als nächstes gehen? Haben Sie schon das Tutorial [Meine erste Anwendung schreiben|quickstart:] ausprobiert?
-Darüber hinaus verfügt Nette über ein ganzes Arsenal an [nützlichen Klassen |utils:], [Datenbankschichten |database:] usw. Klicken Sie sich doch einfach mal durch die Dokumentation. Oder besuchen Sie den [Blog |https://blog.nette.org]. Sie werden eine Menge interessanter Dinge entdecken.
+Neben dem oben Beschriebenen verfügt Nette über ein ganzes Arsenal an [nützlichen Klassen|utils:], eine [Datenbankschicht|database:], usw. Versuchen Sie doch mal, einfach so durch die Dokumentation zu klicken. Oder den [Blog|https://blog.nette.org]. Sie werden viele interessante Dinge entdecken.
-Möge das Framework Ihnen viel Freude bereiten 💙.
+Möge Ihnen das Framework viel Freude bereiten 💙
diff --git a/application/de/modules.texy b/application/de/modules.texy
deleted file mode 100644
index fcdf4331c4..0000000000
--- a/application/de/modules.texy
+++ /dev/null
@@ -1,148 +0,0 @@
-Module
-******
-
-.[perex]
-In Nette stellen Module die logischen Einheiten dar, aus denen eine Anwendung besteht. Sie umfassen Presenter, Templates, eventuell auch Komponenten und Modellklassen.
-
-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`.
-
-/--pre
-app/
-├── Presenters/
-├── Modules/ ← Verzeichnis mit Modulen
-│ ├── Admin/ ← Modul Admin
-│ │ ├── Presenters/ ← seine Presenters
-│ │ │ ├── DashboardPresenter.php
-│ │ │ └── templates/
-│ └── Front/ ← Modul Front
-│ └── Presenters/ ← seine Presenters
-│ └── ...
-\--
-
-Diese Verzeichnisstruktur spiegelt sich in den Klassennamensräumen wider, so dass z. B. `DashboardPresenter` im Namensraum `App\Modules\Admin\Presenters` liegt:
-
-```php
-namespace App\Modules\Admin\Presenters;
-
-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.
-
-Module können neben Presentern und Templates natürlich auch alle anderen Elemente enthalten, wie z.B. Komponenten, Modellklassen, etc.
-
-
-Verschachtelte Module .[#toc-nested-modules]
---------------------------------------------
-
-Module müssen nicht nur eine flache Struktur bilden, Sie können auch Untermodule erstellen, zum Beispiel:
-
-/--pre
-app/
-├── Modules/ ← Verzeichnis mit Modulen
-│ ├── Blog/ ← Modul Blog
-│ │ ├── Admin/ ← Submodul Admin
-│ │ │ ├── Presenters/
-│ │ │ └── ...
-│ │ └── Front/ ← Submodul Front
-│ │ ├── Presenters/
-│ │ └── ...
-│ ├── Forum/ ← Modul Forum
-│ │ └── ...
-\--
-
-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.
-
-Die Verschachtelung kann beliebig tief gehen, so dass Sub-Submodule erstellt werden können.
-
-
-Erstellen von Links .[#toc-creating-links]
-------------------------------------------
-
-Links in Präsentatorvorlagen sind relativ zum aktuellen Modul. So führt der Link `Foo:default` zu dem Präsentator `Foo` im gleichen Modul wie der aktuelle Präsentator. Wenn das aktuelle Modul zum Beispiel `Front` ist, sieht der Link so aus:
-
-```latte
-link to Front:Product:show
-```
-
-Ein Link ist auch dann relativ, wenn er den Namen eines Moduls enthält, das dann als Untermodul betrachtet wird:
-
-```latte
-link to Front:Shop:Product:show
-```
-
-Absolute Links werden analog zu absoluten Pfaden auf der Festplatte geschrieben, jedoch mit Doppelpunkten anstelle von Schrägstrichen. Ein absoluter Link beginnt also mit einem Doppelpunkt:
-
-```latte
-link to Admin:Product:show
-```
-
-Um herauszufinden, ob wir uns in einem bestimmten Modul oder dessen Untermodul befinden, können wir die Funktion `isModuleCurrent(moduleName)` verwenden.
-
-```latte
-
- ...
-
-```
-
-
-Routing .[#toc-routing]
------------------------
-
-Siehe [Kapitel über Routing |routing#Modules].
-
-
-Abbildung .[#toc-mapping]
--------------------------
-
-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`.
-
-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:
-
-```neon
-application:
- mapping:
- *: App\Presenters\*Presenter
-```
-
-Der Name des Presenters wird durch das Sternchen in der Klassenmaske ersetzt und das Ergebnis ist der Klassenname. Einfach!
-
-Wenn wir die Vortragenden in Module unterteilen, können wir für jedes Modul eine eigene Zuordnung vornehmen:
-
-```neon
-application:
- mapping:
- Front: App\Modules\Front\Presenters\*Presenter
- Admin: App\Modules\Admin\Presenters\*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`.
-
-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:
-
-```neon
-application:
- mapping:
- *: App\Modules\*\Presenters\*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`.
-
-Eine alternative Schreibweise ist die Verwendung eines Arrays, das aus drei Segmenten anstelle einer Zeichenkette besteht. Diese Notation ist gleichwertig mit der vorherigen:
-
-```neon
-application:
- mapping:
- *: [App\Modules, *, Presenters\*Presenter]
-```
-
-Der Standardwert ist `*: *Module\*Presenter`.
diff --git a/application/de/multiplier.texy b/application/de/multiplier.texy
index 36f60fcc31..c4b504a032 100644
--- a/application/de/multiplier.texy
+++ b/application/de/multiplier.texy
@@ -1,30 +1,32 @@
-Multiplikator: Dynamische Komponenten
-*************************************
+Multiplier: dynamische Komponenten
+**********************************
-Ein Werkzeug zur dynamischen Erstellung von interaktiven Komponenten .[perex]
+.[perex]
+Werkzeug zur dynamischen Erstellung interaktiver Komponenten
-Beginnen wir mit einem typischen Problem: Wir haben eine Liste von Produkten auf einer E-Commerce-Website und möchten jedes Produkt mit einem Formular *in den Warenkorb legen* begleiten. Eine Möglichkeit ist, die gesamte Liste in ein einziges Formular zu verpacken. Eine bequemere Möglichkeit ist die Verwendung von [api:Nette\Application\UI\Multiplier].
+Beginnen wir mit einem typischen Beispiel: Wir haben eine Liste von Waren in einem E-Shop, und für jede Ware möchten wir ein Formular zum Hinzufügen in den Warenkorb anzeigen. Eine mögliche Variante ist, die gesamte Auflistung in ein einziges Formular zu packen. Einen viel bequemeren Weg bietet uns jedoch [api:Nette\Application\UI\Multiplier].
-Multiplier ermöglicht es Ihnen, eine Fabrik für mehrere Komponenten zu definieren. Sie basiert auf dem Prinzip der verschachtelten Komponenten - jede Komponente, die von [api:Nette\ComponentModel\Container] erbt, kann andere Komponenten enthalten.
+Multiplier ermöglicht es, bequem eine Factory für mehrere Komponenten zu definieren. Es funktioniert nach dem Prinzip verschachtelter Komponenten - jede Komponente, die von [api:Nette\ComponentModel\Container] erbt, kann weitere Komponenten enthalten.
-Siehe [Komponentenmodell |components#Components in Depth] in der Dokumentation. .[tip]
+.[tip]
+Siehe das Kapitel über das [Komponentenmodell |components#Komponenten im Detail] in der Dokumentation oder den [Vortrag von Honza Tvrdík|https://www.youtube.com/watch?v=8y3LLexWu-I].
-Multiplier stellt eine übergeordnete Komponente dar, die ihre Kinder dynamisch über den im Konstruktor übergebenen Callback erzeugen kann. Siehe Beispiel:
+Das Wesen des Multipliers ist, dass er als Elternteil fungiert, der seine Nachkommen dynamisch mithilfe eines im Konstruktor übergebenen Callbacks erstellen kann. Siehe Beispiel:
```php
protected function createComponentShopForm(): Multiplier
{
return new Multiplier(function () {
$form = new Nette\Application\UI\Form;
- $form->addInteger('amount', 'Amount:')
+ $form->addInteger('count', 'Anzahl der Artikel:')
->setRequired();
- $form->addSubmit('send', 'Add to cart');
+ $form->addSubmit('send', 'In den Warenkorb legen');
return $form;
});
}
```
-In der Vorlage können wir ein Formular für jedes Produkt darstellen - und jedes Formular wird tatsächlich eine einzigartige Komponente sein.
+Jetzt können wir im Template einfach für jeden Artikel das Formular rendern lassen - und jedes wird tatsächlich eine eindeutige Komponente sein.
```latte
{foreach $items as $item}
@@ -35,26 +37,26 @@ In der Vorlage können wir ein Formular für jedes Produkt darstellen - und jede
{/foreach}
```
-Das Argument, das an den `{control}` -Tag übergeben wird, lautet:
+Das im Tag `{control}` übergebene Argument hat ein Format, das besagt:
-1. eine Komponente erhalten `shopForm`
-2. und ihr Kind zurückgeben `$item->id`
+1. hole die Komponente `shopForm`
+2. und hole daraus den Nachkommen `$item->id`
-Beim ersten Aufruf von **1.** ist die Komponente `shopForm` noch nicht vorhanden, daher wird die Methode `createComponentShopForm` aufgerufen, um sie zu erstellen. Eine anonyme Funktion, die als Parameter an Multiplier übergeben wird, wird dann aufgerufen und ein Formular wird erstellt.
+Beim ersten Aufruf von Punkt **1.** existiert `shopForm` noch nicht, also wird seine Factory `createComponentShopForm` aufgerufen. Auf der erhaltenen Komponente (Instanz des Multipliers) wird dann die Factory des konkreten Formulars aufgerufen - was die anonyme Funktion ist, die wir dem Multiplier im Konstruktor übergeben haben.
-In den folgenden Iterationen des `foreach` wird die Methode `createComponentShopForm` nicht mehr aufgerufen, da die Komponente bereits existiert. Da wir aber auf ein anderes Kind verweisen (`$item->id` variiert zwischen den Iterationen), wird erneut eine anonyme Funktion aufgerufen und ein neues Formular erstellt.
+In der nächsten Iteration des foreache wird die Methode `createComponentShopForm` nicht mehr aufgerufen (die Komponente existiert), aber da wir einen anderen Nachkommen suchen (`$item->id` wird in jeder Iteration anders sein), wird die anonyme Funktion erneut aufgerufen und gibt uns ein neues Formular zurück.
-Als Letztes müssen wir sicherstellen, dass das Formular tatsächlich das richtige Produkt zum Warenkorb hinzufügt, denn im aktuellen Zustand sind alle Formulare gleich und wir können nicht unterscheiden, zu welchen Produkten sie gehören. Hierfür können wir die Eigenschaft von Multiplier (und generell von jeder Komponentenfabrikmethode im Nette Framework) nutzen, dass jede Komponentenfabrikmethode den Namen der erstellten Komponente als erstes Argument erhält. In unserem Fall wäre das `$item->id`, was genau das ist, was wir brauchen, um einzelne Produkte zu unterscheiden. Alles, was Sie tun müssen, ist, den Code für die Erstellung des Formulars zu ändern:
+Das Einzige, was übrig bleibt, ist sicherzustellen, dass das Formular tatsächlich die richtige Ware in den Warenkorb legt - derzeit ist das Formular für jeden Artikel völlig identisch. Hier hilft uns eine Eigenschaft des Multipliers (und generell jeder Komponenten-Factory im Nette Framework), nämlich dass jede Factory als erstes Argument den Namen der zu erstellenden Komponente erhält. In unserem Fall ist das `$item->id`, was genau die Information ist, die wir benötigen. Es genügt also, die Erstellung des Formulars leicht anzupassen:
```php
protected function createComponentShopForm(): Multiplier
{
return new Multiplier(function ($itemId) {
$form = new Nette\Application\UI\Form;
- $form->addInteger('amount', 'Amount:')
+ $form->addInteger('count', 'Anzahl der Artikel:')
->setRequired();
$form->addHidden('itemId', $itemId);
- $form->addSubmit('send', 'Add to cart');
+ $form->addSubmit('send', 'In den Warenkorb legen');
return $form;
});
}
diff --git a/application/de/presenters.texy b/application/de/presenters.texy
index 57c36c0bd7..e8764b84bc 100644
--- a/application/de/presenters.texy
+++ b/application/de/presenters.texy
@@ -1,39 +1,39 @@
-Vortragende
-***********
+Presenter
+*********
(args...)` .{toc: action()}
--------------------------------------------------
-Ähnlich wie bei der Methode `render()`. Während `render()` dazu gedacht ist, Daten für eine bestimmte Vorlage vorzubereiten, die anschließend gerendert wird, wird in `action()` wird eine Anfrage ohne anschließendes Rendering der Vorlage verarbeitet. So werden z. B. Daten verarbeitet, ein Benutzer an- oder abgemeldet usw., und dann wird er [an eine andere Stelle weitergeleitet |#Redirection].
+Ähnlich der Methode `render()`. Während `render()` dazu dient, Daten für ein bestimmtes Template vorzubereiten, das anschließend gerendert wird, wird in `action()` die Anfrage ohne Bezug zum Rendern des Templates verarbeitet. Zum Beispiel werden Daten verarbeitet, der Benutzer an- oder abgemeldet usw., und danach [woandershin weitergeleitet |#Weiterleitung].
-Es ist wichtig, dass `action()` vor aufgerufen wird `render()`aufgerufen wird, damit wir darin möglicherweise den weiteren Verlauf des Lebenszyklus ändern können, d. h. die Vorlage, die gerendert wird, und auch die Methode `render
Hello ...
+Hallo ...
-
- {foreach $list as $id => $item}
-
- {$item} update - {/foreach} -
-
+ {foreach $items as $id => $item}
+
- {$item} + {/foreach} +
-
- {foreach $list as $id => $item}
-
- {$item} update - {/foreach} -
-
-Bootstrap ist ein Bootcode, der die Umgebung initialisiert, einen Dependency Injection (DI) Container erstellt und die Anwendung startet. Wir werden das besprechen:
-
-- wie Sie Ihre Anwendung mithilfe von NEON-Dateien konfigurieren
-- wie man den Produktions- und den Entwicklungsmodus handhabt
-- wie man den DI-Container erstellt
-
-
-
-
-Anwendungen, ob webbasiert oder als Befehlszeilenskript, beginnen mit einer Art Initialisierung der Umgebung. In früheren Zeiten konnte das eine Datei namens `include.inc.php` sein, die dafür zuständig war und in der Startdatei enthalten war.
-In modernen Nette-Anwendungen wurde sie durch die Klasse `Bootstrap` ersetzt, die als Teil der Anwendung in der Datei `app/Bootstrap.php` zu finden ist. Sie könnte zum Beispiel so aussehen:
-
-```php
-use Nette\Bootstrap\Configurator;
-
-class Bootstrap
-{
- public static function boot(): Configurator
- {
- $appDir = dirname(__DIR__);
- $configurator = new Configurator;
- //$configurator->setDebugMode('secret@23.75.345.200');
- $configurator->enableTracy($appDir . '/log');
- $configurator->setTempDirectory($appDir . '/temp');
- $configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
- $configurator->addConfig($appDir . '/config/common.neon');
- return $configurator;
- }
-}
-```
-
-
-index.php .[#toc-index-php]
-===========================
-
-Im Falle von Webanwendungen ist die Ausgangsdatei `index.php`, die sich im öffentlichen Verzeichnis `www/` befindet. Sie überlässt es der Klasse `Bootstrap`, die Umgebung zu initialisieren und den `$configurator` zurückzugeben, der den DI-Container erstellt. Dann wird der Dienst `Application` aufgerufen, der die Webanwendung ausführt:
-
-```php
-// Initialisieren der Umgebung + Abrufen des Configurator-Objekts
-$configurator = App\Bootstrap::boot();
-// Erstellen eines DI-Containers
-$container = $configurator->createContainer();
-// DI-Container erstellt ein Nette\Application\Application-Objekt
-$application = $container->getByType(Nette\Application\Application::class);
-// Nette-Anwendung starten
-$application->run();
-```
-
-Wie Sie sehen, hilft die Klasse [api:Nette\Bootstrap\Configurator], die wir nun genauer vorstellen werden, bei der Einrichtung der Umgebung und der Erstellung eines Dependency-Injection-Containers (DI).
-
-
-Entwicklungs- vs. Produktionsmodus .[#toc-development-vs-production-mode]
-=========================================================================
-
-Nette unterscheidet zwischen zwei grundlegenden Modi, in denen eine Anfrage ausgeführt wird: Entwicklungs- und Produktionsmodus. Der Entwicklungsmodus ist auf maximalen Komfort für den Programmierer ausgerichtet, Tracy wird angezeigt, der Cache wird automatisch aktualisiert, wenn Vorlagen oder die DI-Containerkonfiguration geändert werden, usw. Im Produktionsmodus liegt der Schwerpunkt auf der Leistung, Tracy protokolliert nur Fehler und Änderungen an Vorlagen und anderen Dateien werden nicht überprüft.
-
-Die Auswahl des Modus erfolgt durch automatische Erkennung, so dass in der Regel keine Notwendigkeit besteht, etwas manuell zu konfigurieren oder umzuschalten. Der Modus ist Entwicklung, wenn die Anwendung auf localhost läuft (d.h. IP-Adresse `127.0.0.1` oder `::1`) und kein Proxy vorhanden ist (d.h. sein HTTP-Header). Ansonsten läuft sie im Produktionsmodus.
-
-Wenn Sie den Entwicklungsmodus in anderen Fällen aktivieren möchten, z. B. für Programmierer, die von einer bestimmten IP-Adresse aus zugreifen, können Sie `setDebugMode()` verwenden:
-
-```php
-$configurator->setDebugMode('23.75.345.200'); // eine oder mehrere IP-Adressen
-```
-
-Wir empfehlen auf jeden Fall, eine IP-Adresse mit einem Cookie zu kombinieren. Wir speichern ein geheimes Token im `nette-debug` Cookie, z.B. `secret1234`, und der Entwicklungsmodus wird für Programmierer mit dieser Kombination von IP und Cookie aktiviert.
-
-```php
-$configurator->setDebugMode('secret1234@23.75.345.200');
-```
-
-Wir können den Entwicklermodus auch komplett abschalten, sogar für localhost:
-
-```php
-$configurator->setDebugMode(false);
-```
-
-Beachten Sie, dass der Wert `true` den Entwicklermodus standardmäßig einschaltet, was auf einem Produktionsserver niemals passieren sollte.
-
-
-Debugging-Werkzeug Tracy .[#toc-debugging-tool-tracy]
-=====================================================
-
-Zur einfachen Fehlersuche werden wir das großartige Tool [Tracy |tracy:] einschalten. Im Entwicklermodus zeigt es Fehler an und im Produktionsmodus protokolliert es Fehler in das angegebene Verzeichnis:
-
-```php
-$configurator->enableTracy($appDir . '/log');
-```
-
-
-Temporäre Dateien .[#toc-temporary-files]
-=========================================
-
-Nette verwendet den Cache für DI-Container, RobotLoader, Vorlagen usw. Daher ist es notwendig, den Pfad zu dem Verzeichnis festzulegen, in dem der Cache gespeichert werden soll:
-
-```php
-$configurator->setTempDirectory($appDir . '/temp');
-```
-
-Unter Linux oder macOS setzen Sie die [Schreibrechte |nette:troubleshooting#Setting directory permissions] für die Verzeichnisse `log/` und `temp/`.
-
-
-RobotLoader .[#toc-robotloader]
-===============================
-
-Normalerweise wollen wir die Klassen automatisch mit [RobotLoader |robot-loader:] laden, also müssen wir ihn starten und ihn Klassen aus dem Verzeichnis laden lassen, in dem sich `Bootstrap.php` befindet (d.h. `__DIR__`) und aus allen seinen Unterverzeichnissen:
-
-```php
-$configurator->createRobotLoader()
- ->addDirectory(__DIR__)
- ->register();
-```
-
-Eine alternative Möglichkeit ist, nur das automatische Laden von [Composer |best-practices:composer] PSR-4 zu verwenden.
-
-
-Zeitzone .[#toc-timezone]
-=========================
-
-Configurator ermöglicht es Ihnen, eine Zeitzone für Ihre Anwendung festzulegen.
-
-```php
-$configurator->setTimeZone('Europe/Prague');
-```
-
-
-DI-Container-Konfiguration .[#toc-di-container-configuration]
-=============================================================
-
-Teil des Boot-Prozesses ist die Erstellung eines DI-Containers, d.h. einer Fabrik für Objekte, die das Herzstück der gesamten Anwendung ist. Dabei handelt es sich um eine PHP-Klasse, die von Nette generiert und in einem Cache-Verzeichnis gespeichert wird. Die Factory erzeugt wichtige Anwendungsobjekte, und Konfigurationsdateien weisen sie an, wie sie zu erstellen und zu konfigurieren sind, wodurch wir das Verhalten der gesamten Anwendung beeinflussen.
-
-Konfigurationsdateien werden normalerweise im [NEON-Format |neon:format] geschrieben. [Was konfiguriert werden kann |nette:configuring], können Sie [hier |nette:configuring] nachlesen.
-
-.[tip]
-Im Entwicklungsmodus wird der Container jedes Mal automatisch aktualisiert, wenn Sie den Code oder die Konfigurationsdateien ändern. Im Produktionsmodus wird er nur einmal generiert und Dateiänderungen werden nicht überprüft, um die Leistung zu maximieren.
-
-Konfigurationsdateien werden mit `addConfig()` geladen:
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-```
-
-Die Methode `addConfig()` kann mehrfach aufgerufen werden, um mehrere Dateien hinzuzufügen.
-
-```php
-$configurator->addConfig($appDir . '/config/common.neon');
-$configurator->addConfig($appDir . '/config/local.neon');
-if (PHP_SAPI === 'cli') {
- $configurator->addConfig($appDir . '/config/cli.php');
-}
-```
-
-Der Name `cli.php` ist kein Tippfehler, die Konfiguration kann auch in eine PHP-Datei geschrieben werden, die sie als Array zurückgibt.
-
-Alternativ können wir auch den [Abschnitt`includes` |dependency-injection:configuration#including files] verwenden, um weitere Konfigurationsdateien zu laden.
-
-Wenn Elemente mit denselben Schlüsseln in Konfigurationsdateien vorkommen, werden sie [überschrieben oder |dependency-injection:configuration#Merging] im Falle von Arrays [zusammengeführt |dependency-injection:configuration#Merging]. Die später eingebundene Datei hat eine höhere Priorität als die vorherige. Die Datei, in der der Abschnitt `includes` aufgeführt ist, hat eine höhere Priorität als die in ihr enthaltenen Dateien.
-
-
-Statische Parameter .[#toc-static-parameters]
----------------------------------------------
-
-Parameter, die in Konfigurationsdateien verwendet werden, können [im Abschnitt `parameters` |dependency-injection:configuration#parameters] definiert und auch von der Methode `addStaticParameters()` übergeben (oder überschrieben) werden (sie hat den Alias `addParameters()`). Wichtig ist, dass unterschiedliche Parameterwerte die Erzeugung zusätzlicher DI-Container, d.h. zusätzlicher Klassen, bewirken.
-
-```php
-$configurator->addStaticParameters([
- 'projectId' => 23,
-]);
-```
-
-In Konfigurationsdateien können wir die übliche Notation `%projectId%` verwenden, um auf den Parameter mit dem Namen `projectId` zuzugreifen. Standardmäßig füllt der Configurator die folgenden Parameter aus: `appDir`, `wwwDir`, `tempDir`, `vendorDir`, `debugMode` und `consoleMode`.
-
-
-Dynamische Parameter .[#toc-dynamic-parameters]
------------------------------------------------
-
-Wir können dem Container auch dynamische Parameter hinzufügen, deren unterschiedliche Werte, im Gegensatz zu statischen Parametern, nicht die Erzeugung neuer DI-Container verursachen.
-
-```php
-$configurator->addDynamicParameters([
- 'remoteIp' => $_SERVER['REMOTE_ADDR'],
-]);
-```
-
-Umgebungsvariablen können mit dynamischen Parametern leicht verfügbar gemacht werden. Wir können über `%env.variable%` in Konfigurationsdateien auf sie zugreifen.
-
-```php
-$configurator->addDynamicParameters([
- 'env' => getenv(),
-]);
-```
-
-
-Importierte Dienste .[#toc-imported-services]
----------------------------------------------
-
-Wir gehen jetzt in die Tiefe. Obwohl der Zweck eines DI-Containers darin besteht, Objekte zu erstellen, kann es in Ausnahmefällen erforderlich sein, ein vorhandenes Objekt in den Container einzufügen. Wir tun dies, indem wir den Dienst mit dem Attribut `imported: true` definieren.
-
-```neon
-services:
- myservice:
- type: App\Model\MyCustomService
- imported: true
-```
-
-Erstellen Sie eine neue Instanz und fügen Sie sie in Bootstrap ein:
-
-```php
-$configurator->addServices([
- 'myservice' => new App\Model\MyCustomService('foobar'),
-]);
-```
-
-
-Verschiedene Umgebungen .[#toc-different-environments]
-======================================================
-
-Es steht Ihnen frei, die Klasse `Bootstrap` an Ihre Bedürfnisse anzupassen. Sie können der Methode `boot()` Parameter hinzufügen, um Webprojekte zu unterscheiden, oder andere Methoden hinzufügen, wie `bootForTests()`, die die Umgebung für Unit-Tests initialisiert, `bootForCli()` für Skripte, die von der Befehlszeile aus aufgerufen werden, und so weiter.
-
-```php
-public static function bootForTests(): Configurator
-{
- $configurator = self::boot();
- Tester\Environment::setup(); // Nette Tester Initialisierung
- return $configurator;
-}
-```
diff --git a/application/de/bootstrapping.texy b/application/de/bootstrapping.texy
new file mode 100644
index 0000000000..6a61ac820c
--- /dev/null
+++ b/application/de/bootstrapping.texy
@@ -0,0 +1,297 @@
+Bootstrapping
+*************
+
+
+
+Bootstrapping ist der Prozess der Initialisierung der Anwendungsumgebung, der Erstellung eines Dependency Injection (DI) Containers und des Startens der Anwendung. Wir werden besprechen:
+
+- wie die Bootstrap-Klasse die Umgebung initialisiert
+- wie Anwendungen mit NEON-Dateien konfiguriert werden
+- wie zwischen Produktions- und Entwicklungsmodus unterschieden wird
+- wie der DI-Container erstellt und konfiguriert wird
+
+
+
+
+Anwendungen, egal ob Webanwendungen oder von der Kommandozeile gestartete Skripte, beginnen ihre Ausführung mit einer Form der Initialisierung der Umgebung. Früher war dafür eine Datei wie `include.inc.php` verantwortlich, die von der initialen Datei eingebunden wurde. In modernen Nette-Anwendungen wurde dies durch die Klasse `Bootstrap` ersetzt, die Sie als Teil der Anwendung in der Datei `app/Bootstrap.php` finden. Sie könnte zum Beispiel so aussehen:
+
+```php
+use Nette\Bootstrap\Configurator;
+
+class Bootstrap
+{
+ private Configurator $configurator;
+ private string $rootDir;
+
+ public function __construct()
+ {
+ $this->rootDir = dirname(__DIR__);
+ // Der Configurator ist für die Einstellung der Anwendungsumgebung und der Dienste verantwortlich.
+ $this->configurator = new Configurator;
+ // Legt das Verzeichnis für temporäre Dateien fest, die von Nette generiert werden (z. B. kompilierte Templates)
+ $this->configurator->setTempDirectory($this->rootDir . '/temp');
+ }
+
+ public function bootWebApplication(): Nette\DI\Container
+ {
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+ }
+
+ private function initializeEnvironment(): void
+ {
+ // Nette ist schlau und der Entwicklungsmodus wird automatisch aktiviert,
+ // oder Sie können ihn für eine bestimmte IP-Adresse aktivieren, indem Sie die folgende Zeile auskommentieren:
+ // $this->configurator->setDebugMode('secret@23.75.345.200');
+
+ // Aktiviert Tracy: das ultimative "Schweizer Taschenmesser" für das Debugging.
+ $this->configurator->enableTracy($this->rootDir . '/log');
+
+ // RobotLoader: lädt automatisch alle Klassen im ausgewählten Verzeichnis
+ $this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+ }
+
+ private function setupContainer(): void
+ {
+ // Lädt Konfigurationsdateien
+ $this->configurator->addConfig($this->rootDir . '/config/common.neon');
+ }
+}
+```
+
+
+index.php
+=========
+
+Die initiale Datei für Webanwendungen ist `index.php`, die sich im [öffentlichen Verzeichnis |directory-structure#Öffentliches Verzeichnis www] `www/` befindet. Diese lässt die Umgebung von der Bootstrap-Klasse initialisieren und den DI-Container erstellen. Danach holt sie sich den Dienst `Application` daraus, der die Webanwendung startet:
+
+```php
+$bootstrap = new App\Bootstrap;
+// Initialisierung der Umgebung + Erstellung des DI-Containers
+$container = $bootstrap->bootWebApplication();
+// Der DI-Container erstellt das Objekt Nette\Application\Application
+$application = $container->getByType(Nette\Application\Application::class);
+// Start der Nette-Anwendung und Verarbeitung der eingehenden Anfrage
+$application->run();
+```
+
+Wie man sieht, hilft die Klasse [api:Nette\Bootstrap\Configurator] bei der Einstellung der Umgebung und der Erstellung des Dependency Injection (DI) Containers, die wir uns nun genauer ansehen werden.
+
+
+Entwicklungs- vs. Produktionsmodus
+==================================
+
+Nette verhält sich unterschiedlich, je nachdem, ob es auf einem Entwicklungs- oder Produktionsserver läuft:
+
+🛠️ Entwicklungsmodus (Development):
+ - Zeigt die Tracy Debugbar mit nützlichen Informationen an (SQL-Abfragen, Ausführungszeit, verwendeter Speicher)
+ - Zeigt im Fehlerfall eine detaillierte Fehlerseite mit Funktionsaufrufen und Variableninhalten an
+ - Erneuert automatisch den Cache bei Änderungen an Latte-Templates, Konfigurationsdateien usw.
+
+
+🚀 Produktionsmodus (Production):
+ - Zeigt keine Debugging-Informationen an, alle Fehler werden im Log protokolliert
+ - Zeigt im Fehlerfall den ErrorPresenter oder eine allgemeine "Server Error"-Seite an
+ - Der Cache wird niemals automatisch erneuert!
+ - Optimiert für Geschwindigkeit und Sicherheit
+
+
+Die Moduswahl erfolgt durch Auto-Detektion, sodass normalerweise nichts konfiguriert oder manuell umgeschaltet werden muss:
+
+- Entwicklungsmodus: auf Localhost (IP-Adresse `127.0.0.1` oder `::1`), wenn kein Proxy vorhanden ist (d. h. dessen HTTP-Header)
+- Produktionsmodus: überall sonst
+
+Wenn wir den Entwicklungsmodus auch in anderen Fällen aktivieren möchten, z. B. für Programmierer, die von einer bestimmten IP-Adresse zugreifen, verwenden wir `setDebugMode()`:
+
+```php
+$this->configurator->setDebugMode('23.75.345.200'); // es kann auch ein Array von IP-Adressen angegeben werden
+```
+
+Wir empfehlen dringend, die IP-Adresse mit einem Cookie zu kombinieren. Wir speichern einen geheimen Token, z. B. `secret1234`, im Cookie `nette-debug` und aktivieren auf diese Weise den Entwicklungsmodus für Programmierer, die von einer bestimmten IP-Adresse zugreifen und gleichzeitig den erwähnten Token im Cookie haben:
+
+```php
+$this->configurator->setDebugMode('secret1234@23.75.345.200');
+```
+
+Wir können den Entwicklungsmodus auch vollständig deaktivieren, sogar für Localhost:
+
+```php
+$this->configurator->setDebugMode(false);
+```
+
+Achtung, der Wert `true` schaltet den Entwicklungsmodus fest ein, was auf einem Produktionsserver niemals passieren darf.
+
+
+Debugging-Tool Tracy
+====================
+
+Für einfaches Debugging aktivieren wir noch das großartige Werkzeug [Tracy |tracy:]. Im Entwicklungsmodus visualisiert es Fehler und im Produktionsmodus protokolliert es Fehler in das angegebene Verzeichnis:
+
+```php
+$this->configurator->enableTracy($this->rootDir . '/log');
+```
+
+
+Temporäre Dateien
+=================
+
+Nette verwendet einen Cache für den DI-Container, RobotLoader, Templates usw. Daher ist es notwendig, den Pfad zum Verzeichnis festzulegen, in dem der Cache gespeichert wird:
+
+```php
+$this->configurator->setTempDirectory($this->rootDir . '/temp');
+```
+
+Unter Linux oder macOS setzen Sie für die Verzeichnisse `log/` und `temp/` [Schreibrechte |nette:troubleshooting#Einstellung der Verzeichnisberechtigungen].
+
+
+RobotLoader
+===========
+
+In der Regel möchten wir Klassen automatisch mit dem [RobotLoader |robot-loader:] laden, also müssen wir ihn starten und ihn Klassen aus dem Verzeichnis laden lassen, in dem sich `Bootstrap.php` befindet (d. h. `__DIR__`), sowie aus allen Unterverzeichnissen:
+
+```php
+$this->configurator->createRobotLoader()
+ ->addDirectory(__DIR__)
+ ->register();
+```
+
+Ein alternativer Ansatz besteht darin, Klassen nur über [Composer |best-practices:composer] unter Einhaltung von PSR-4 laden zu lassen.
+
+
+Zeitzone
+========
+
+Über den Konfigurator können Sie die Standard-Zeitzone einstellen.
+
+```php
+$this->configurator->setTimeZone('Europe/Prague');
+```
+
+
+Konfiguration des DI-Containers
+===============================
+
+Ein Teil des Boot-Prozesses ist die Erstellung des DI-Containers, auch Objektfabrik genannt, der das Herz der gesamten Anwendung ist. Es handelt sich tatsächlich um eine PHP-Klasse, die von Nette generiert und im Cache-Verzeichnis gespeichert wird. Die Fabrik erstellt die Schlüsselobjekte der Anwendung, und mithilfe von Konfigurationsdateien weisen wir sie an, wie sie diese erstellen und einstellen soll, wodurch wir das Verhalten der gesamten Anwendung beeinflussen.
+
+Konfigurationsdateien werden normalerweise im [NEON |neon:format]-Format geschrieben. In einem separaten Kapitel erfahren Sie, [was alles konfiguriert werden kann |nette:configuring].
+
+.[tip]
+Im Entwicklungsmodus wird der Container bei jeder Änderung des Codes oder der Konfigurationsdateien automatisch aktualisiert. Im Produktionsmodus wird er nur einmal generiert, und Änderungen werden zur Maximierung der Leistung nicht überprüft.
+
+Konfigurationsdateien laden wir mit `addConfig()`:
+
+```php
+$this->configurator->addConfig($this->rootDir . '/config/common.neon');
+```
+
+Wenn wir mehrere Konfigurationsdateien hinzufügen möchten, können wir die Funktion `addConfig()` mehrmals aufrufen.
+
+```php
+$configDir = $this->rootDir . '/config';
+$this->configurator->addConfig($configDir . '/common.neon');
+$this->configurator->addConfig($configDir . '/services.neon');
+if (PHP_SAPI === 'cli') {
+ $this->configurator->addConfig($configDir . '/cli.php');
+}
+```
+
+Der Name `cli.php` ist kein Tippfehler; die Konfiguration kann auch in einer PHP-Datei geschrieben sein, die sie als Array zurückgibt.
+
+Wir können auch weitere Konfigurationsdateien im [Abschnitt `includes` |dependency-injection:configuration#Dateien einbinden] hinzufügen.
+
+Wenn in den Konfigurationsdateien Elemente mit denselben Schlüsseln erscheinen, werden sie überschrieben oder im Falle von [Arrays zusammengeführt |dependency-injection:configuration#Zusammenführen]. Die später eingebundene Datei hat eine höhere Priorität als die vorherige. Die Datei, in der der Abschnitt `includes` aufgeführt ist, hat eine höhere Priorität als die darin eingebundenen Dateien.
+
+
+Statische Parameter
+-------------------
+
+Parameter, die in Konfigurationsdateien verwendet werden, können [im Abschnitt `parameters` |dependency-injection:configuration#Parameter] definiert und auch über die Methode `addStaticParameters()` (hat den Alias `addParameters()`) übergeben (oder überschrieben) werden. Wichtig ist, dass unterschiedliche Werte der Parameter die Generierung zusätzlicher DI-Container, also zusätzlicher Klassen, verursachen.
+
+```php
+$this->configurator->addStaticParameters([
+ 'projectId' => 23,
+]);
+```
+
+Auf den Parameter `projectId` kann in der Konfiguration mit der üblichen Schreibweise `%projectId%` verwiesen werden.
+
+
+Dynamische Parameter
+--------------------
+
+Wir können dem Container auch dynamische Parameter hinzufügen, deren unterschiedliche Werte im Gegensatz zu statischen Parametern nicht die Generierung neuer DI-Container verursachen.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'remoteIp' => $_SERVER['REMOTE_ADDR'],
+]);
+```
+
+So können wir einfach z. B. Umgebungsvariablen hinzufügen, auf die dann in der Konfiguration mit der Schreibweise `%env.variable%` verwiesen werden kann.
+
+```php
+$this->configurator->addDynamicParameters([
+ 'env' => getenv(),
+]);
+```
+
+
+Standardparameter
+-----------------
+
+In Konfigurationsdateien können Sie diese statischen Parameter verwenden:
+
+- `%appDir%` ist der absolute Pfad zum Verzeichnis mit der Datei `Bootstrap.php`
+- `%wwwDir%` ist der absolute Pfad zum Verzeichnis mit der Eingabedatei `index.php`
+- `%tempDir%` ist der absolute Pfad zum Verzeichnis für temporäre Dateien
+- `%vendorDir%` ist der absolute Pfad zum Verzeichnis, in dem Composer Bibliotheken installiert
+- `%rootDir%` ist der absolute Pfad zum Stammverzeichnis des Projekts
+- `%debugMode%` gibt an, ob sich die Anwendung im Debugging-Modus befindet
+- `%consoleMode%` gibt an, ob die Anfrage über die Kommandozeile kam
+
+
+Importierte Dienste
+-------------------
+
+Jetzt gehen wir tiefer. Obwohl der Zweck des DI-Containers darin besteht, Objekte zu erstellen, kann es ausnahmsweise notwendig sein, ein vorhandenes Objekt in den Container einzufügen. Dies tun wir, indem wir den Dienst mit dem Flag `imported: true` definieren.
+
+```neon
+services:
+ myservice:
+ type: App\Model\MyCustomService
+ imported: true
+```
+
+Und im Bootstrap fügen wir das Objekt in den Container ein:
+
+```php
+$this->configurator->addServices([
+ 'myservice' => new App\Model\MyCustomService('foobar'),
+]);
+```
+
+
+Unterschiedliche Umgebungen
+===========================
+
+Scheuen Sie sich nicht, die Bootstrap-Klasse an Ihre Bedürfnisse anzupassen. Sie können der Methode `bootWebApplication()` Parameter hinzufügen, um Webprojekte zu unterscheiden. Oder wir können weitere Methoden hinzufügen, zum Beispiel `bootTestEnvironment()`, die die Umgebung für Unit-Tests initialisiert, `bootConsoleApplication()` für Skripte, die von der Kommandozeile aufgerufen werden, usw.
+
+```php
+public function bootTestEnvironment(): Nette\DI\Container
+{
+ Tester\Environment::setup(); // Initialisierung von Nette Tester
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+
+public function bootConsoleApplication(): Nette\DI\Container
+{
+ $this->configurator->setDebugMode(false);
+ $this->initializeEnvironment();
+ $this->setupContainer();
+ return $this->configurator->createContainer();
+}
+```
diff --git a/application/de/components.texy b/application/de/components.texy
index 4429cd3cd7..b39a8e5abd 100644
--- a/application/de/components.texy
+++ b/application/de/components.texy
@@ -3,27 +3,27 @@ Interaktive Komponenten
-Komponenten sind separate, wiederverwendbare Objekte, die wir in Seiten einfügen. Sie können Formulare, Datenfelder, Umfragen sein, eigentlich alles, was sinnvoll ist, um es wiederholt zu verwenden. Wir werden es zeigen:
+Komponenten sind eigenständige, wiederverwendbare Objekte, die wir in Seiten einfügen. Das können Formulare, Datengrids, Umfragen sein, eigentlich alles, was sinnvoll wiederverwendet werden kann. Wir zeigen Ihnen:
-- wie man Komponenten verwendet?
-- wie man sie schreibt?
+- Wie man Komponenten verwendet?
+- Wie man sie schreibt?
- Was sind Signale?
-Nette hat ein eingebautes Komponentensystem. Ältere von Ihnen erinnern sich vielleicht an etwas Ähnliches aus Delphi oder ASP.NET Web Forms. React oder Vue.js bauen auf etwas entfernt Ähnlichem auf. In der Welt der PHP-Frameworks ist dies jedoch eine völlig einzigartige Funktion.
+Nette verfügt über ein eingebautes Komponentensystem. Etwas Ähnliches kennen Kenner vielleicht noch aus Delphi oder ASP.NET Web Forms, und React oder Vue.js bauen auf etwas entfernt Ähnlichem auf. In der Welt der PHP-Frameworks ist dies jedoch eine einzigartige Angelegenheit.
-Gleichzeitig verändern Komponenten die Herangehensweise an die Anwendungsentwicklung grundlegend. Sie können Seiten aus vorgefertigten Einheiten zusammenstellen. Benötigen Sie ein Datagrid in der Verwaltung? Sie finden es bei [Componette |https://componette.org/search/component], einem Repository von Open-Source-Add-ons (nicht nur Komponenten) für Nette, und fügen es einfach in den Presenter ein.
+Dabei beeinflussen Komponenten den Ansatz zur Anwendungsentwicklung grundlegend. Sie können Seiten aus vorgefertigten Einheiten zusammenstellen. Benötigen Sie ein Datagrid in der Administration? Sie finden es auf [Componette |https://componette.org/search/component], einem Repository für Open-Source-Add-ons (also nicht nur Komponenten) für Nette, und fügen es einfach in den Presenter ein.
-Sie können eine beliebige Anzahl von Komponenten in den Presenter einfügen. Und Sie können andere Komponenten in einige Komponenten einfügen. So entsteht ein Komponentenbaum mit einem Presenter als Wurzel.
+Sie können beliebig viele Komponenten in einen Presenter integrieren. Und in einige Komponenten können Sie weitere Komponenten einfügen. So entsteht ein Komponentenbaum, dessen Wurzel der Presenter ist.
-Fabrik-Methoden .[#toc-factory-methods]
-=======================================
+Factory-Methoden
+================
-Wie werden Komponenten im Presenter platziert und anschließend verwendet? Normalerweise mit Hilfe von Fabrikmethoden.
+Wie werden Komponenten in den Presenter eingefügt und anschließend verwendet? Normalerweise über Factory-Methoden.
-Die Komponentenfabrik ist eine elegante Möglichkeit, Komponenten nur dann zu erstellen, wenn sie wirklich benötigt werden (lazy / on-demand). Der ganze Zauber liegt in der Implementierung einer Methode namens `createComponentPlease Vote
+Stimmen Sie ab
{control poll} ``` -Hollywood-Stil .[#toc-hollywood-style] -====================================== +Hollywood Style +=============== -Komponenten verwenden häufig eine coole Technik, die wir gerne als Hollywood-Stil bezeichnen. Sicherlich kennen Sie das Klischee, das Schauspieler bei Casting-Aufrufen oft hören: "Rufen Sie uns nicht an, wir rufen Sie an." Und genau darum geht es hier. +Komponenten verwenden üblicherweise eine frische Technik, die wir gerne Hollywood Style nennen. Sie kennen sicher den geflügelten Satz, den Teilnehmer von Filmcastings so oft hören: „Rufen Sie uns nicht an, wir rufen Sie an“. Und genau darum geht es. -Anstatt in Nette ständig Fragen zu stellen ("wurde das Formular abgeschickt?", "war es gültig?" oder "hat jemand diesen Knopf gedrückt?"), sagen Sie dem Framework "wenn das passiert, rufe diese Methode auf" und lassen die weitere Arbeit darauf beruhen. Wenn Sie in JavaScript programmieren, sind Sie mit dieser Art der Programmierung vertraut. Sie schreiben Funktionen, die aufgerufen werden, wenn ein bestimmtes Ereignis eintritt. Und die Engine übergibt die entsprechenden Parameter an sie. +In Nette sagen Sie dem Framework nämlich, anstatt ständig nachfragen zu müssen („wurde das Formular abgeschickt?“, „war es gültig?“ oder „hat der Benutzer diesen Button gedrückt?“), „wenn das passiert, ruf diese Methode auf“ und überlassen die weitere Arbeit ihm. Wenn Sie in JavaScript programmieren, kennen Sie diesen Programmierstil genau. Sie schreiben Funktionen, die aufgerufen werden, wenn ein bestimmtes Ereignis eintritt. Und die Sprache übergibt ihnen die entsprechenden Parameter. -Das verändert die Art und Weise, wie Sie Anwendungen schreiben, völlig. Je mehr Aufgaben Sie an das Framework delegieren können, desto weniger Arbeit haben Sie. Und desto weniger können Sie vergessen. +Dies verändert die Sichtweise auf das Schreiben von Anwendungen grundlegend. Je mehr Aufgaben Sie dem Framework überlassen können, desto weniger Arbeit haben Sie. Und desto weniger können Sie vielleicht übersehen. -Wie man eine Komponente schreibt .[#toc-how-to-write-a-component] -================================================================= +Wir schreiben eine Komponente +============================= -Mit Komponente sind in der Regel Abkömmlinge der Klasse [api:Nette\Application\UI\Control] gemeint. Der Präsentator [api:Nette\Application\UI\Presenter] selbst ist ebenfalls ein Abkömmling der Klasse `Control`. +Unter dem Begriff Komponente verstehen wir normalerweise einen Nachfahren der Klasse [api:Nette\Application\UI\Control]. (Genauer wäre es also, den Begriff „Controls“ zu verwenden, aber „Kontrollen“ hat im Deutschen eine ganz andere Bedeutung, und eher haben sich „Komponenten“ durchgesetzt.) Der Presenter [api:Nette\Application\UI\Presenter] selbst ist übrigens auch ein Nachfahre der Klasse `Control`. ```php .{file:PollControl.php} use Nette\Application\UI\Control; @@ -84,22 +84,22 @@ class PollControl extends Control ``` -Rendering .[#toc-rendering] -=========================== +Rendern +======= -Wir wissen bereits, dass das Tag `{control componentName}` zum Zeichnen einer Komponente verwendet wird. Es ruft die Methode `render()` der Komponente auf, in der wir uns um das Rendering kümmern. Wir haben, genau wie im Presenter, eine [Lattenvorlage |latte:] in der Variablen `$this->template`, der wir die Parameter übergeben. Im Gegensatz zur Verwendung im Presenter müssen wir eine Vorlagendatei angeben und sie rendern lassen: +Wir wissen bereits, dass zum Rendern einer Komponente der Tag `{control componentName}` verwendet wird. Dieser ruft eigentlich die Methode `render()` der Komponente auf, in der wir uns um das Rendern kümmern. Uns steht, genau wie im Presenter, eine [Latte-Vorlage|templates] in der Variablen `$this->template` zur Verfügung, an die wir Parameter übergeben. Im Gegensatz zum Presenter müssen wir die Template-Datei angeben und sie rendern lassen: ```php .{file:PollControl.php} public function render(): void { - // wir werden einige Parameter in die Vorlage einfügen + // Wir fügen einige Parameter in das Template ein $this->template->param = $value; - // und zeichnen es + // und rendern es $this->template->render(__DIR__ . '/poll.latte'); } ``` -Das Tag `{control}` erlaubt die Übergabe von Parametern an die Methode `render()`: +Der `{control}`-Tag ermöglicht es, Parameter an die `render()`-Methode zu übergeben: ```latte {control poll $id, $message} @@ -112,7 +112,7 @@ public function render(int $id, string $message): void } ``` -Manchmal kann eine Komponente aus mehreren Teilen bestehen, die wir separat rendern wollen. Für jedes dieser Teile wird eine eigene Rendering-Methode erstellt, hier zum Beispiel `renderPaginator()`: +Manchmal kann eine Komponente aus mehreren Teilen bestehen, die wir getrennt rendern möchten. Für jeden davon erstellen wir eine eigene Rendering-Methode, hier im Beispiel etwa `renderPaginator()`: ```php .{file:PollControl.php} public function renderPaginator(): void @@ -121,69 +121,69 @@ public function renderPaginator(): void } ``` -Und in der Vorlage rufen wir sie dann mit auf: +Und im Template rufen wir sie dann auf mit: ```latte {control poll:paginator} ``` -Zum besseren Verständnis ist es gut zu wissen, wie der Tag in PHP-Code übersetzt wird. +Zum besseren Verständnis ist es gut zu wissen, wie dieser Tag in PHP übersetzt wird. ```latte {control poll} {control poll:paginator 123, 'hello'} ``` -Dies kompiliert zu: +wird übersetzt als: ```php $control->getComponent('poll')->render(); $control->getComponent('poll')->renderPaginator(123, 'hello'); ``` -`getComponent()` Die Methode `poll` gibt die Komponente zurück, und dann wird die Methode `render()` bzw. `renderPaginator()` für sie aufgerufen. +Die Methode `getComponent()` gibt die Komponente `poll` zurück und ruft für diese Komponente die Methode `render()` bzw. `renderPaginator()` auf, wenn im Tag nach dem Doppelpunkt eine andere Rendering-Art angegeben ist. .[caution] -Wenn irgendwo im Parameterteil **`=>`** verwendet wird, werden alle Parameter in ein Array eingeschlossen und als erstes Argument übergeben: +Achtung, wenn irgendwo in den Parametern **`=>`** vorkommt, werden alle Parameter in ein Array verpackt und als erstes Argument übergeben: ```latte {control poll, id: 123, message: 'hello'} ``` -kompiliert zu: +wird übersetzt als: ```php $control->getComponent('poll')->render(['id' => 123, 'message' => 'hello']); ``` -Rendering der Unterkomponente: +Rendern einer Sub-Komponente: ```latte {control cartControl-someForm} ``` -kompiliert zu: +wird übersetzt als: ```php $control->getComponent("cartControl-someForm")->render(); ``` -Komponenten, wie Präsentatoren, übergeben automatisch mehrere nützliche Variablen an Vorlagen: +Komponenten, ebenso wie Presenter, übergeben automatisch einige nützliche Variablen an die Templates: -- `$basePath` ist ein absoluter URL-Pfad zum Stammverzeichnis (z. B. `/CD-collection`) -- `$baseUrl` ist eine absolute URL zum Stammverzeichnis (z. B. `http://localhost/CD-collection`) -- `$user` ist ein Objekt [, das den Benutzer repräsentiert |security:authentication] -- `$presenter` ist der aktuelle Präsentator +- `$basePath` ist der absolute URL-Pfad zum Wurzelverzeichnis (z. B. `/eshop`) +- `$baseUrl` ist die absolute URL zum Wurzelverzeichnis (z. B. `http://localhost/eshop`) +- `$user` ist das Objekt, das [den Benutzer repräsentiert |security:authentication] +- `$presenter` ist der aktuelle Presenter - `$control` ist die aktuelle Komponente -- `$flashes` Liste der von der Methode gesendeten [Meldungen |#flash-messages] `flashMessage()` +- `$flashes` ist ein Array von [Nachrichten |#Flash-Nachrichten], die mit der Funktion `flashMessage()` gesendet wurden -Signal .[#toc-signal] -===================== +Signal +====== -Wir wissen bereits, dass die Navigation in der Nette-Anwendung aus der Verknüpfung oder Routing zu Paaren `Presenter:action` besteht. Was aber, wenn wir nur eine Aktion auf der **aktuellen Seite** durchführen wollen? Zum Beispiel die Sortierreihenfolge der Tabellenspalte ändern, ein Element löschen, den Hell/Dunkel-Modus umschalten, das Formular abschicken, an der Umfrage teilnehmen usw. +Wir wissen bereits, dass die Navigation in einer Nette-Anwendung im Verlinken oder Weiterleiten auf Paare von `Presenter:action` besteht. Aber was ist, wenn wir nur eine Aktion auf der **aktuellen Seite** durchführen wollen? Zum Beispiel die Sortierreihenfolge von Spalten in einer Tabelle ändern; einen Eintrag löschen; den Hell-/Dunkelmodus umschalten; ein Formular absenden; in einer Umfrage abstimmen; usw. -Diese Art von Anfrage wird als Signal bezeichnet. Und wie Aktionen rufen Methoden auf `action
-Das Erstellen von Links in Nette ist so einfach wie ein Fingerzeig. Zeigen Sie einfach darauf und das Framework erledigt die ganze Arbeit für Sie. Wir werden es zeigen:
+Das Erstellen von Links in Nette ist so einfach wie mit dem Finger zu zeigen. Sie müssen nur zielen, und das Framework erledigt die ganze Arbeit für Sie. Wir zeigen Ihnen:
-- wie man Links in Vorlagen und anderswo erstellt
-- wie man einen Link von der aktuellen Seite unterscheidet
-- was mit ungültigen Links geschieht
+- wie man Links in Templates und anderswo erstellt
+- wie man einen Link zur aktuellen Seite unterscheidet
+- was mit ungültigen Links zu tun ist
-Dank des [bidirektionalen Routings |routing] müssen Sie die URLs der Anwendung nicht mehr in den Vorlagen oder im Code fest codieren, was sich später ändern oder kompliziert sein kann. Geben Sie einfach den Präsentator und die Aktion im Link an, übergeben Sie beliebige Parameter und das Framework generiert die URL selbst. Tatsächlich ist es dem Aufruf einer Funktion sehr ähnlich. Sie werden es mögen.
+Dank [bidirektionalem Routing |routing] müssen Sie niemals fest codierte URL-Adressen Ihrer Anwendung in Templates oder Code schreiben, die sich später ändern könnten, oder sie kompliziert zusammensetzen. Im Link genügt es, den Presenter und die Aktion anzugeben, eventuelle Parameter zu übergeben, und das Framework generiert die URL selbst. Eigentlich ist es sehr ähnlich wie der Aufruf einer Funktion. Das wird Ihnen gefallen.
-In der Präsentatorvorlage .[#toc-in-the-presenter-template]
-===========================================================
+Im Presenter-Template
+=====================
-Am häufigsten erstellen wir Links in Vorlagen und ein großer Helfer ist das Attribut `n:href`:
+Am häufigsten erstellen wir Links in Templates, und ein großartiger Helfer ist das Attribut `n:href`:
```latte
-detail
+Detail
```
-Beachten Sie, dass wir anstelle des HTML-Attributs `href` das [n:attribute |latte:syntax#n:attributes] `n:href` verwendet haben. Sein Wert ist keine URL, wie Sie es von dem Attribut `href` gewohnt sind, sondern der Name des Präsentators und der Aktion.
+Beachten Sie, dass wir anstelle des HTML-Attributs `href` das [n:Attribut |latte:syntax#n:Attribute] `n:href` verwendet haben. Sein Wert ist dann nicht eine URL, wie es beim `href`-Attribut der Fall wäre, sondern der Name des Presenters und der Aktion.
-Ein Klick auf einen Link ist, einfach gesagt, so etwas wie der Aufruf einer Methode `ProductPresenter::renderShow()`. Und wenn sie Parameter in ihrer Signatur hat, können wir sie mit Argumenten aufrufen:
+Ein Klick auf den Link ist, vereinfacht gesagt, so etwas wie der Aufruf der Methode `ProductPresenter::renderShow()`. Und wenn diese Parameter in ihrer Signatur hat, können wir sie mit Argumenten aufrufen:
```latte
-detail
+Produktdetail
```
-Es ist auch möglich, benannte Parameter zu übergeben. Der folgende Link übergibt den Parameter `lang` mit dem Wert `en`:
+Es ist auch möglich, benannte Parameter zu übergeben. Der folgende Link übergibt den Parameter `lang` mit dem Wert `cs`:
```latte
-detail
+Produktdetail
```
-Wenn die Methode `ProductPresenter::renderShow()` nicht `$lang` in ihrer Signatur hat, kann sie den Wert des Parameters mit `$lang = $this->getParameter('lang')` lesen.
+Wenn die Methode `ProductPresenter::renderShow()` `$lang` nicht in ihrer Signatur hat, kann sie den Wert des Parameters mit `$lang = $this->getParameter('lang')` oder aus der [Property |presenters#Anfrageparameter] ermitteln.
-Wenn die Parameter in einem Array gespeichert sind, können sie mit dem `...` -Operator (oder `(expand)` -Operator in Latte 2.x) expandiert werden:
+Wenn die Parameter in einem Array gespeichert sind, können sie mit dem Operator `...` (in Latte 2.x mit dem Operator `(expand)`) erweitert werden:
```latte
-{var $args = [$product->id, lang => en]}
-detail
+{var $args = [$product->id, lang => cs]}
+Produktdetail
```
-Die so genannten [persistenten Parameter |presenters#persistent parameters] werden ebenfalls automatisch in den Links übergeben.
+In Links werden auch automatisch sogenannte [persistente Parameter |presenters#Persistente Parameter] übergeben.
-Das Attribut `n:href` ist sehr praktisch für HTML-Tags ``. Wenn wir den Link an anderer Stelle, zum Beispiel im Text, ausgeben wollen, verwenden wir `{link}`:
+Das Attribut `n:href` ist sehr praktisch für HTML-Tags ``. Wenn wir einen Link an anderer Stelle ausgeben möchten, zum Beispiel im Text, verwenden wir `{link}`:
```latte
-URL is: {link Home:default}
+Die Adresse lautet: {link Home:default}
```
-Im Code .[#toc-in-the-code]
-===========================
+Im Code
+=======
-Die Methode `link()` wird verwendet, um einen Link im Presenter zu erstellen:
+Zum Erstellen eines Links im Presenter dient die Methode `link()`:
```php
$url = $this->link('Product:show', $product->id);
```
-Parameter können auch als Array übergeben werden, wobei auch benannte Parameter angegeben werden können:
+Parameter können auch über ein Array übergeben werden, wo auch benannte Parameter angegeben werden können:
```php
$url = $this->link('Product:show', [$product->id, 'lang' => 'cs']);
```
-Links können auch ohne Presenter erstellt werden, indem der [LinkGenerator |#LinkGenerator] und seine Methode `link()` verwendet werden.
+Links können auch ohne Presenter erstellt werden, dafür gibt es den [#LinkGenerator] und seine Methode `link()`.
-Links zum Presenter .[#toc-links-to-presenter]
-==============================================
+Links zu Presentern
+===================
-Wenn das Ziel des Links Presenter und Action ist, hat er diese Syntax:
+Wenn das Ziel des Links ein Presenter und eine Aktion ist, hat er diese Syntax:
```
[//] [[[[:]module:]presenter:]action | this] [#fragment]
```
-Das Format wird von allen Latte-Tags und allen Presenter-Methoden unterstützt, die mit Links arbeiten, also `n:href`, `{link}`, `{plink}`, `link()`, `lazyLink()`, `isLinkCurrent()`, `redirect()`, `redirectPermanent()`, `forward()`, `canonicalize()` und auch [LinkGenerator |#LinkGenerator]. Also auch wenn `n:href` in den Beispielen verwendet wird, könnte es jede der Funktionen sein.
+Das Format wird von allen Latte-Tags und allen Presenter-Methoden unterstützt, die mit Links arbeiten, also `n:href`, `{link}`, `{plink}`, `link()`, `lazyLink()`, `isLinkCurrent()`, `redirect()`, `redirectPermanent()`, `forward()`, `canonicalize()` und auch dem [#LinkGenerator]. Auch wenn in den Beispielen `n:href` verwendet wird, könnte dort jede dieser Funktionen stehen.
Die Grundform ist also `Presenter:action`:
```latte
-home
+Startseite
```
-Wenn wir auf die Aktion des aktuellen Moderators verweisen, können wir seinen Namen weglassen:
+Wenn wir auf eine Aktion des aktuellen Presenters verlinken, können wir seinen Namen weglassen:
```latte
-home
+Startseite
```
-Wenn die Aktion `default` lautet, können wir sie weglassen, aber der Doppelpunkt muss bleiben:
+Wenn das Ziel die Aktion `default` ist, können wir sie weglassen, aber der Doppelpunkt muss bleiben:
```latte
-home
+Startseite
```
-Links können auch auf andere [Module |modules] verweisen. Hier unterscheidet man zwischen relativen und absoluten Links zu den Untermodulen. Das Prinzip ist analog zu Plattenpfaden, nur dass anstelle von Schrägstrichen Doppelpunkte stehen. Nehmen wir an, dass der eigentliche Präsentator Teil des Moduls `Front` ist, dann schreiben wir:
+Links können auch zu anderen [Modulen |directory-structure#Presenter und Templates] führen. Hier werden Links in relative zu verschachtelten Submodulen oder absolute unterschieden. Das Prinzip ist analog zu Pfaden auf der Festplatte, nur dass anstelle von Schrägstrichen Doppelpunkte verwendet werden. Angenommen, der aktuelle Presenter ist Teil des Moduls `Front`, dann schreiben wir:
```latte
-link to Front:Shop:Product:show
-link to Admin:Product:show
+Link zu Front:Shop:Product:show
+Link zu Admin:Product:show
```
-Ein Sonderfall ist die [Verknüpfung mit sich selbst |#Links to Current Page]. Hier schreiben wir `this` als Ziel.
+Ein Sonderfall ist der Link [auf sich selbst |#Link zur aktuellen Seite], bei dem wir als Ziel `this` angeben.
```latte
-refresh
+aktualisieren
```
-Wir können auf einen bestimmten Teil der HTML-Seite über ein so genanntes Fragment nach dem Rautezeichen `#` verlinken:
+Wir können auf einen bestimmten Teil der Seite über das sogenannte Fragment nach dem Rautezeichen `#` verlinken:
```latte
-link to Home:default and fragment #main
+Link zu Home:default und Fragment #main
```
-Absolute Pfade .[#toc-absolute-paths]
-=====================================
+Absolute Pfade
+==============
-Die von `link()` oder `n:href` erzeugten Links sind immer absolute Pfade (d. h. sie beginnen mit `/`), nicht aber absolute URLs mit Protokoll und Domäne wie `https://domain`.
+Links, die mit `link()` oder `n:href` generiert werden, sind immer absolute Pfade (d. h. sie beginnen mit einem `/`), aber keine absoluten URLs mit Protokoll und Domain wie `https://domain`.
-Um eine absolute URL zu erzeugen, fügen Sie zwei Schrägstriche am Anfang hinzu (z. B. `n:href="//Home:"`). Sie können den Präsentator auch so einstellen, dass er nur absolute Links erzeugt, indem Sie `$this->absoluteUrls = true` einstellen.
+Um eine absolute URL zu generieren, fügen Sie am Anfang zwei Schrägstriche hinzu (z. B. `n:href="//Home:"`). Oder Sie können den Presenter so umschalten, dass er nur absolute Links generiert, indem Sie `$this->absoluteUrls = true` setzen.
-Link zur aktuellen Seite .[#toc-link-to-current-page]
-=====================================================
+Link zur aktuellen Seite
+========================
-Das Ziel `this` wird einen Link zur aktuellen Seite erstellen:
+Das Ziel `this` erstellt einen Link zur aktuellen Seite:
```latte
-refresh
+aktualisieren
```
-Gleichzeitig werden alle Parameter, die in der Signatur des Befehls `render
+
+Wie entwirft man eine übersichtliche und skalierbare Verzeichnisstruktur für Projekte im Nette Framework? Wir zeigen Ihnen bewährte Praktiken, die Ihnen bei der Organisation Ihres Codes helfen. Sie erfahren:
+
+- wie Sie die Anwendung **logisch in Verzeichnisse gliedern**
+- wie Sie die Struktur so gestalten, dass sie mit dem Wachstum des Projekts **gut skaliert**
+- welche **möglichen Alternativen** es gibt und welche Vor- oder Nachteile sie haben
+
+
+
+
+Es ist wichtig zu erwähnen, dass das Nette Framework selbst keine bestimmte Struktur vorschreibt. Es ist so konzipiert, dass es sich leicht an alle Bedürfnisse und Präferenzen anpassen lässt.
+
+
+Grundlegende Projektstruktur
+============================
+
+Obwohl das Nette Framework keine feste Verzeichnisstruktur vorschreibt, gibt es eine bewährte Standardanordnung in Form des [Web Project|https://github.com/nette/web-project]:
+
+/--pre
+web-project/
+├── app/ ← Anwendungsverzeichnis
+├── assets/ ← SCSS-, JS-Dateien, Bilder..., alternativ resources/
+├── bin/ ← Skripte für die Befehlszeile
+├── config/ ← Konfiguration
+├── log/ ← protokollierte Fehler
+├── temp/ ← temporäre Dateien, Cache
+├── tests/ ← Tests
+├── vendor/ ← Bibliotheken, die mit Composer installiert wurden
+└── www/ ← öffentliches Verzeichnis (Document-Root)
+\--
+
+Sie können diese Struktur beliebig an Ihre Bedürfnisse anpassen – Ordner umbenennen oder verschieben. Anschließend müssen Sie nur die relativen Pfade zu den Verzeichnissen in der Datei `Bootstrap.php` und gegebenenfalls `composer.json` anpassen. Mehr ist nicht nötig, keine komplexe Neukonfiguration, keine Änderung von Konstanten. Nette verfügt über eine intelligente Autoerkennung und erkennt automatisch den Speicherort der Anwendung einschließlich ihrer URL-Basis.
+
+
+Prinzipien der Code-Organisation
+================================
+
+Wenn Sie ein neues Projekt zum ersten Mal untersuchen, sollten Sie sich schnell darin zurechtfinden. Stellen Sie sich vor, Sie klicken auf das Verzeichnis `app/Model/` und sehen diese Struktur:
+
+/--pre
+app/Model/
+├── Services/
+├── Repositories/
+└── Entities/
+\--
+
+Daraus können Sie nur entnehmen, dass das Projekt einige Dienste, Repositories und Entitäten verwendet. Über den tatsächlichen Zweck der Anwendung erfahren Sie überhaupt nichts.
+
+Schauen wir uns einen anderen Ansatz an – die **Organisation nach Domänen**:
+
+/--pre
+app/Model/
+├── Cart/
+├── Payment/
+├── Order/
+└── Product/
+\--
+
+Hier ist es anders – auf den ersten Blick ist klar, dass es sich um einen E-Shop handelt. Schon die Verzeichnisnamen verraten, was die Anwendung kann – sie arbeitet mit Zahlungen, Bestellungen und Produkten.
+
+Der erste Ansatz (Organisation nach Klassentypen) bringt in der Praxis eine Reihe von Problemen mit sich: Code, der logisch zusammenhängt, ist auf verschiedene Ordner verteilt, und Sie müssen zwischen ihnen hin- und herspringen. Deshalb werden wir nach Domänen organisieren.
+
+
+Namespaces
+----------
+
+Es ist üblich, dass die Verzeichnisstruktur mit den Namespaces in der Anwendung korrespondiert. Das bedeutet, dass der physische Speicherort der Dateien ihrem Namespace entspricht. Zum Beispiel sollte eine Klasse, die sich in `app/Model/Product/ProductRepository.php` befindet, den Namespace `App\Model\Product` haben. Dieses Prinzip hilft bei der Orientierung im Code und vereinfacht das Autoloading.
+
+
+Singular vs. Plural in Namen
+----------------------------
+
+Beachten Sie, dass wir für die Hauptverzeichnisse der Anwendung den Singular verwenden: `app`, `config`, `log`, `temp`, `www`. Ebenso innerhalb der Anwendung: `Model`, `Core`, `Presentation`. Das liegt daran, dass jedes dieser Verzeichnisse ein zusammenhängendes Konzept darstellt.
+
+Ähnlich repräsentiert z.B. `app/Model/Product` alles rund um Produkte. Wir nennen es nicht `Products`, weil es sich nicht um einen Ordner voller Produkte handelt (dann wären dort Dateien wie `nokia.php`, `samsung.php`). Es ist ein Namespace, der Klassen für die Arbeit mit Produkten enthält – `ProductRepository.php`, `ProductService.php`.
+
+Der Ordner `app/Tasks` steht im Plural, weil er einen Satz eigenständiger ausführbarer Skripte enthält – `CleanupTask.php`, `ImportTask.php`. Jedes davon ist eine eigenständige Einheit.
+
+Zur Konsistenz empfehlen wir die Verwendung von:
+- Singular für einen Namespace, der eine funktionale Einheit repräsentiert (auch wenn er mit mehreren Entitäten arbeitet)
+- Plural für Sammlungen eigenständiger Einheiten
+- Im Zweifelsfall oder wenn Sie nicht darüber nachdenken möchten, wählen Sie den Singular
+
+
+Öffentliches Verzeichnis `www/`
+===============================
+
+Dieses Verzeichnis ist das einzige, das vom Web aus zugänglich ist (sog. Document-Root). Oft trifft man auch auf den Namen `public/` anstelle von `www/` – das ist nur eine Frage der Konvention und hat keinen Einfluss auf die Funktionalität des Frameworks. Das Verzeichnis enthält:
+- Den [Einstiegspunkt |bootstrapping#index.php] der Anwendung `index.php`
+- Die Datei `.htaccess` mit Regeln für mod_rewrite (bei Apache)
+- Statische Dateien (CSS, JavaScript, Bilder)
+- Hochgeladene Dateien
+
+Für die korrekte Sicherheit der Anwendung ist es entscheidend, den [konfigurierten Document-Root |nette:troubleshooting#Wie ändert oder entfernt man das Verzeichnis www aus der URL] richtig eingestellt zu haben.
+
+.[note]
+Platzieren Sie niemals den Ordner `node_modules/` in diesem Verzeichnis – er enthält Tausende von Dateien, die ausführbar sein könnten und nicht öffentlich zugänglich sein sollten.
+
+
+Anwendungsverzeichnis `app/`
+============================
+
+Dies ist das Hauptverzeichnis mit dem Anwendungscode. Die Grundstruktur:
+
+/--pre
+app/
+├── Core/ ← Infrastrukturangelegenheiten
+├── Model/ ← Geschäftslogik
+├── Presentation/ ← Presenter und Templates
+├── Tasks/ ← Befehlszeilenskripte
+└── Bootstrap.php ← Bootstrap-Klasse der Anwendung
+\--
+
+`Bootstrap.php` ist die [Startklasse der Anwendung|bootstrapping], die die Umgebung initialisiert, die Konfiguration lädt und den DI-Container erstellt.
+
+Schauen wir uns nun die einzelnen Unterverzeichnisse genauer an.
+
+
+Presenter und Templates
+=======================
+
+Der Präsentationsteil der Anwendung befindet sich im Verzeichnis `app/Presentation`. Eine Alternative ist das kurze `app/UI`. Dies ist der Ort für alle Presenter, ihre Templates und eventuelle Hilfsklassen.
+
+Diese Schicht organisieren wir nach Domänen. In einem komplexen Projekt, das einen E-Shop, einen Blog und eine API kombiniert, würde die Struktur so aussehen:
+
+/--pre
+app/Presentation/
+├── Shop/ ← E-Shop Frontend
+│ ├── Product/
+│ ├── Cart/
+│ └── Order/
+├── Blog/ ← Blog
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← Administration
+│ ├── Dashboard/
+│ └── Products/
+└── Api/ ← API-Endpunkte
+ └── V1/
+\--
+
+Bei einem einfachen Blog hingegen würden wir folgende Gliederung verwenden:
+
+/--pre
+app/Presentation/
+├── Front/ ← Frontend der Website
+│ ├── Home/
+│ └── Post/
+├── Admin/ ← Administration
+│ ├── Dashboard/
+│ └── Posts/
+├── Error/
+└── Export/ ← RSS, Sitemaps etc.
+\--
+
+Ordner wie `Home/` oder `Dashboard/` enthalten Presenter und Templates. Ordner wie `Front/`, `Admin/` oder `Api/` nennen wir **Module**. Technisch gesehen sind dies normale Verzeichnisse, die zur logischen Gliederung der Anwendung dienen.
+
+Jeder Ordner mit einem Presenter enthält den gleichnamigen Presenter und seine Templates. Zum Beispiel enthält der Ordner `Dashboard/`:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← Presenter
+└── default.latte ← Template
+\--
+
+Diese Verzeichnisstruktur spiegelt sich in den Namespaces der Klassen wider. Zum Beispiel befindet sich `DashboardPresenter` im Namespace `App\Presentation\Admin\Dashboard` (siehe [#Presenter-Mapping]):
+
+```php
+namespace App\Presentation\Admin\Dashboard;
+
+class DashboardPresenter extends Nette\Application\UI\Presenter
+{
+ // ...
+}
+```
+
+Auf den Presenter `Dashboard` innerhalb des Moduls `Admin` verweisen wir in der Anwendung mittels Doppelpunktnotation als `Admin:Dashboard`. Auf seine Aktion `default` dann als `Admin:Dashboard:default`. Bei verschachtelten Modulen verwenden wir mehrere Doppelpunkte, zum Beispiel `Shop:Order:Detail:default`.
+
+
+Flexible Strukturentwicklung
+----------------------------
+
+Einer der großen Vorteile dieser Struktur ist, wie elegant sie sich an die wachsenden Anforderungen des Projekts anpasst. Nehmen wir als Beispiel den Teil, der XML-Feeds generiert. Am Anfang haben wir eine einfache Form:
+
+/--pre
+Export/
+├── ExportPresenter.php ← ein Presenter für alle Exporte
+├── sitemap.latte ← Template für die Sitemap
+└── feed.latte ← Template für den RSS-Feed
+\--
+
+Mit der Zeit kommen weitere Feed-Typen hinzu und wir benötigen mehr Logik für sie... Kein Problem! Der Ordner `Export/` wird einfach zu einem Modul:
+
+/--pre
+Export/
+├── Sitemap/
+│ ├── SitemapPresenter.php
+│ └── sitemap.latte
+└── Feed/
+ ├── FeedPresenter.php
+ ├── zbozi.latte ← Feed für Zboží.cz
+ └── heureka.latte ← Feed für Heureka.cz
+\--
+
+Diese Transformation ist absolut nahtlos – es genügt, neue Unterordner zu erstellen, den Code darin aufzuteilen und die Links zu aktualisieren (z.B. von `Export:feed` zu `Export:Feed:zbozi`). Dadurch können wir die Struktur nach Bedarf schrittweise erweitern, die Verschachtelungsebene ist in keiner Weise begrenzt.
+
+Wenn Sie beispielsweise in der Administration viele Presenter haben, die sich auf die Verwaltung von Bestellungen beziehen, wie `OrderDetail`, `OrderEdit`, `OrderDispatch` usw., können Sie zur besseren Organisation an dieser Stelle ein Modul (Ordner) `Order` erstellen, in dem sich die (Ordner für die) Presenter `Detail`, `Edit`, `Dispatch` und weitere befinden.
+
+
+Platzierung von Templates
+-------------------------
+
+In den vorherigen Beispielen haben wir gesehen, dass die Templates direkt im Ordner mit dem Presenter platziert sind:
+
+/--pre
+Dashboard/
+├── DashboardPresenter.php ← Presenter
+├── DashboardTemplate.php ← optionale Klasse für das Template
+└── default.latte ← Template
+\--
+
+Diese Platzierung erweist sich in der Praxis als am bequemsten – Sie haben alle zusammengehörigen Dateien sofort zur Hand.
+
+Alternativ können Sie die Templates in einem Unterordner `templates/` platzieren. Nette unterstützt beide Varianten. Sie können Templates sogar ganz außerhalb des `Presentation/`-Ordners platzieren. Alles über die Möglichkeiten zur Platzierung von Templates finden Sie im Kapitel [Suche nach Templates |templates#Finden von Vorlagen].
+
+
+Hilfsklassen und Komponenten
+----------------------------
+
+Zu Presentern und Templates gehören oft auch weitere Hilfsdateien. Wir platzieren sie logisch nach ihrem Wirkungsbereich:
+
+1. **Direkt beim Presenter** im Falle spezifischer Komponenten für den jeweiligen Presenter:
+
+/--pre
+Product/
+├── ProductPresenter.php
+├── ProductGrid.php ← Komponente zur Produktauflistung
+└── FilterForm.php ← Formular zur Filterung
+\--
+
+2. **Für das Modul** – wir empfehlen die Verwendung des Ordners `Accessory`, der übersichtlich gleich am Anfang des Alphabets platziert wird:
+
+/--pre
+Front/
+├── Accessory/
+│ ├── NavbarControl.php ← Komponenten für das Frontend
+│ └── TemplateFilters.php
+├── Product/
+└── Cart/
+\--
+
+3. **Für die gesamte Anwendung** – in `Presentation/Accessory/`:
+/--pre
+app/Presentation/
+├── Accessory/
+│ ├── LatteExtension.php
+│ └── TemplateFilters.php
+├── Front/
+└── Admin/
+\--
+
+Oder Sie können Hilfsklassen wie `LatteExtension.php` oder `TemplateFilters.php` im Infrastrukturordner `app/Core/Latte/` platzieren. Und Komponenten in `app/Components`. Die Wahl hängt von den Gewohnheiten des Teams ab.
+
+
+Model - Das Herz der Anwendung
+==============================
+
+Das Model enthält die gesamte Geschäftslogik der Anwendung. Für seine Organisation gilt wieder die Regel – wir strukturieren nach Domänen:
+
+/--pre
+app/Model/
+├── Payment/ ← alles rund um Zahlungen
+│ ├── PaymentFacade.php ← Hauptzugangspunkt
+│ ├── PaymentRepository.php
+│ ├── Payment.php ← Entität
+├── Order/ ← alles rund um Bestellungen
+│ ├── OrderFacade.php
+│ ├── OrderRepository.php
+│ ├── Order.php
+└── Shipping/ ← alles rund um den Versand
+\--
+
+Im Model treffen Sie typischerweise auf diese Klassentypen:
+
+**Fassaden**: stellen den Hauptzugangspunkt zu einer bestimmten Domäne in der Anwendung dar. Sie fungieren als Orchestrator, der die Zusammenarbeit zwischen verschiedenen Diensten koordiniert, um vollständige Use Cases (wie "Bestellung erstellen" oder "Zahlung verarbeiten") zu implementieren. Unter ihrer Orchestrierungsschicht verbirgt die Fassade Implementierungsdetails vor dem Rest der Anwendung und bietet so eine saubere Schnittstelle für die Arbeit mit der jeweiligen Domäne.
+
+```php
+class OrderFacade
+{
+ public function createOrder(Cart $cart): Order
+ {
+ // Validierung
+ // Erstellung der Bestellung
+ // Senden der E-Mail
+ // Eintrag in die Statistiken
+ }
+}
+```
+
+**Dienste**: konzentrieren sich auf eine spezifische Geschäftsoperation innerhalb der Domäne. Im Gegensatz zur Fassade, die ganze Use Cases orchestriert, implementiert ein Dienst spezifische Geschäftslogik (wie Preisberechnungen oder Zahlungsverarbeitung). Dienste sind typischerweise zustandslos und können entweder von Fassaden als Bausteine für komplexere Operationen oder direkt von anderen Teilen der Anwendung für einfachere Aufgaben verwendet werden.
+
+```php
+class PricingService
+{
+ public function calculateTotal(Order $order): Money
+ {
+ // Preisberechnung
+ }
+}
+```
+
+**Repositories**: stellen die gesamte Kommunikation mit dem Datenspeicher sicher, typischerweise einer Datenbank. Ihre Aufgabe ist das Laden und Speichern von Entitäten und die Implementierung von Methoden zu deren Suche. Das Repository schirmt den Rest der Anwendung von den Implementierungsdetails der Datenbank ab und bietet eine objektorientierte Schnittstelle für die Arbeit mit Daten.
+
+```php
+class OrderRepository
+{
+ public function find(int $id): ?Order
+ {
+ }
+
+ public function findByCustomer(int $customerId): array
+ {
+ }
+}
+```
+
+**Entitäten**: Objekte, die die Hauptgeschäftskonzepte in der Anwendung repräsentieren, ihre eigene Identität haben und sich im Laufe der Zeit ändern. Typischerweise handelt es sich um Klassen, die mittels ORM (wie Nette Database Explorer oder Doctrine) auf Datenbanktabellen abgebildet sind. Entitäten können Geschäftsregeln enthalten, die sich auf ihre Daten beziehen, sowie Validierungslogik.
+
+```php
+// Entität, die auf die Datenbanktabelle orders abgebildet ist
+class Order extends Nette\Database\Table\ActiveRow
+{
+ public function addItem(Product $product, int $quantity): void
+ {
+ $this->related('order_items')->insert([
+ 'product_id' => $product->id,
+ 'quantity' => $quantity,
+ 'unit_price' => $product->price,
+ ]);
+ }
+}
+```
+
+**Value Objects**: unveränderliche Objekte, die Werte ohne eigene Identität repräsentieren – beispielsweise ein Geldbetrag oder eine E-Mail-Adresse. Zwei Instanzen eines Value Objects mit gleichen Werten werden als identisch betrachtet.
+
+
+Infrastrukturcode
+=================
+
+Der Ordner `Core/` (oder auch `Infrastructure/`) ist die Heimat für die technische Grundlage der Anwendung. Infrastrukturcode umfasst typischerweise:
+
+/--pre
+app/Core/
+├── Router/ ← Routing und URL-Management
+│ └── RouterFactory.php
+├── Security/ ← Authentifizierung und Autorisierung
+│ ├── Authenticator.php
+│ └── Authorizator.php
+├── Logging/ ← Logging und Monitoring
+│ ├── SentryLogger.php
+│ └── FileLogger.php
+├── Cache/ ← Caching-Schicht
+│ └── FullPageCache.php
+└── Integration/ ← Integration mit externen Diensten
+ ├── Slack/
+ └── Stripe/
+\--
+
+Bei kleineren Projekten genügt natürlich eine flache Gliederung:
+
+/--pre
+Core/
+├── RouterFactory.php
+├── Authenticator.php
+└── QueueMailer.php
+\--
+
+Es handelt sich um Code, der:
+
+- Sich um die technische Infrastruktur kümmert (Routing, Logging, Caching)
+- Externe Dienste integriert (Sentry, Elasticsearch, Redis)
+- Basisdienste für die gesamte Anwendung bereitstellt (Mail, Datenbank)
+- Meistens unabhängig von der spezifischen Domäne ist – Cache oder Logger funktionieren gleich für E-Shop oder Blog.
+
+Sind Sie unsicher, ob eine bestimmte Klasse hierher oder ins Modell gehört? Der Hauptunterschied besteht darin, dass der Code in `Core/`:
+
+- Nichts über die Domäne weiß (Produkte, Bestellungen, Artikel)
+- Meistens in ein anderes Projekt übertragen werden kann
+- Löst "wie es funktioniert" (wie man eine E-Mail sendet), nicht "was es tut" (welche E-Mail gesendet werden soll)
+
+Beispiel zum besseren Verständnis:
+
+- `App\Core\MailerFactory` - erstellt Instanzen der Klasse zum Senden von E-Mails, kümmert sich um SMTP-Einstellungen
+- `App\Model\OrderMailer` - verwendet `MailerFactory` zum Senden von E-Mails über Bestellungen, kennt deren Templates und weiß, wann sie gesendet werden sollen
+
+
+Befehlszeilenskripte
+====================
+
+Anwendungen müssen oft Tätigkeiten außerhalb normaler HTTP-Anfragen ausführen – sei es Datenverarbeitung im Hintergrund, Wartung oder periodische Aufgaben. Zur Ausführung dienen einfache Skripte im Verzeichnis `bin/`, die eigentliche Implementierungslogik platzieren wir dann in `app/Tasks/` (oder `app/Commands/`).
+
+Beispiel:
+
+/--pre
+app/Tasks/
+├── Maintenance/ ← Wartungsskripte
+│ ├── CleanupCommand.php ← Löschen alter Daten
+│ └── DbOptimizeCommand.php ← Datenbankoptimierung
+├── Integration/ ← Integration mit externen Systemen
+│ ├── ImportProducts.php ← Import aus dem Liefersystem
+│ └── SyncOrders.php ← Synchronisation von Bestellungen
+└── Scheduled/ ← regelmäßige Aufgaben
+ ├── NewsletterCommand.php ← Versand von Newslettern
+ └── ReminderCommand.php ← Benachrichtigungen an Kunden
+\--
+
+Was gehört ins Modell und was in die Befehlszeilenskripte? Zum Beispiel ist die Logik zum Senden einer einzelnen E-Mail Teil des Modells, der Massenversand von Tausenden von E-Mails gehört bereits zu `Tasks/`.
+
+Aufgaben werden normalerweise [über die Befehlszeile ausgeführt |https://blog.nette.org/en/cli-scripts-in-nette-application] oder über Cron. Sie können auch über eine HTTP-Anfrage gestartet werden, aber man muss an die Sicherheit denken. Der Presenter, der die Aufgabe startet, muss abgesichert werden, zum Beispiel nur für angemeldete Benutzer oder mit einem starken Token und Zugriff von erlaubten IP-Adressen. Bei langen Aufgaben muss das Zeitlimit des Skripts erhöht und `session_write_close()` verwendet werden, damit die Session nicht gesperrt wird.
+
+
+Weitere mögliche Verzeichnisse
+==============================
+
+Neben den genannten grundlegenden Verzeichnissen können Sie je nach Projektbedarf weitere spezialisierte Ordner hinzufügen. Schauen wir uns die häufigsten davon und ihre Verwendung an:
+
+/--pre
+app/
+├── Api/ ← API-Logik unabhängig von der Präsentationsschicht
+├── Database/ ← Migrationsskripte und Seeder für Testdaten
+├── Components/ ← gemeinsam genutzte visuelle Komponenten über die gesamte Anwendung hinweg
+├── Event/ ← nützlich, wenn Sie eine ereignisgesteuerte Architektur verwenden
+├── Mail/ ← E-Mail-Templates und zugehörige Logik
+└── Utils/ ← Hilfsklassen
+\--
+
+Für gemeinsam genutzte visuelle Komponenten, die in Presentern über die gesamte Anwendung hinweg verwendet werden, kann der Ordner `app/Components` oder `app/Controls` verwendet werden:
+
+/--pre
+app/Components/
+├── Form/ ← gemeinsam genutzte Formularkomponenten
+│ ├── SignInForm.php
+│ └── UserForm.php
+├── Grid/ ← Komponenten für Datenlisten
+│ └── DataGrid.php
+└── Navigation/ ← Navigationselemente
+ ├── Breadcrumbs.php
+ └── Menu.php
+\--
+
+Hierher gehören Komponenten mit komplexerer Logik. Wenn Sie Komponenten zwischen mehreren Projekten teilen möchten, ist es ratsam, sie in ein separates Composer-Paket auszulagern.
+
+Im Verzeichnis `app/Mail` können Sie die Verwaltung der E-Mail-Kommunikation platzieren:
+
+/--pre
+app/Mail/
+├── templates/ ← E-Mail-Templates
+│ ├── order-confirmation.latte
+│ └── welcome.latte
+└── OrderMailer.php
+\--
+
+
+Presenter-Mapping
+=================
+
+Das Mapping definiert Regeln zur Ableitung des Klassennamens aus dem Presenter-Namen. Wir spezifizieren sie in der [Konfiguration|configuration] unter dem Schlüssel `application › mapping`.
+
+Auf dieser Seite haben wir gezeigt, dass wir Presenter im Ordner `app/Presentation` (oder `app/UI`) platzieren. Diese Konvention müssen wir Nette in der Konfigurationsdatei mitteilen. Eine Zeile genügt:
+
+```neon
+application:
+ mapping: App\Presentation\*\**Presenter
+```
+
+Wie funktioniert das Mapping? Zum besseren Verständnis stellen wir uns zunächst eine Anwendung ohne Module vor. Wir möchten, dass die Presenter-Klassen in den Namespace `App\Presentation` fallen, damit der Presenter `Home` auf die Klasse `App\Presentation\HomePresenter` abgebildet wird. Was wir mit dieser Konfiguration erreichen:
+
+```neon
+application:
+ mapping: App\Presentation\*Presenter
+```
+
+Das Mapping funktioniert so, dass der Presenter-Name `Home` das Sternchen in der Maske `App\Presentation\*Presenter` ersetzt, wodurch wir den resultierenden Klassennamen `App\Presentation\HomePresenter` erhalten. Einfach!
+
+Wie Sie jedoch in den Beispielen in diesem und anderen Kapiteln sehen, platzieren wir die Presenter-Klassen in gleichnamigen Unterverzeichnissen, zum Beispiel wird der Presenter `Home` auf die Klasse `App\Presentation\Home\HomePresenter` abgebildet. Dies erreichen wir mit der `***Presenter`-Maske (erfordert Nette Application 3.2):
+
+```neon
+application:
+ mapping: App\Presentation\**Presenter
+```
+
+Nun kommen wir zum Mapping von Presentern in Module. Für jedes Modul können wir ein spezifisches Mapping definieren:
+
+```neon
+application:
+ mapping:
+ Front: App\Presentation\Front\**Presenter
+ Admin: App\Presentation\Admin\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Gemäß dieser Konfiguration wird der Presenter `Front:Home` auf die Klasse `App\Presentation\Front\Home\HomePresenter` abgebildet, während der Presenter `Api:OAuth` auf die Klasse `App\Api\OAuthPresenter` abgebildet wird.
+
+Da die Module `Front` und `Admin` eine ähnliche Mapping-Methode haben und es solche Module wahrscheinlich mehr geben wird, ist es möglich, eine allgemeine Regel zu erstellen, die sie ersetzt. Zur Klassenmaske kommt somit ein neues Sternchen für das Modul hinzu:
+
+```neon
+application:
+ mapping:
+ *: App\Presentation\*\**Presenter
+ Api: App\Api\*Presenter
+```
+
+Es funktioniert auch für tiefer verschachtelte Verzeichnisstrukturen, wie zum Beispiel den Presenter `Admin:User:Edit`, wobei sich das Segment mit dem Sternchen für jede Ebene wiederholt und das Ergebnis die Klasse `App\Presentation\Admin\User\Edit\EditPresenter` ist.
+
+Eine alternative Schreibweise ist die Verwendung eines Arrays anstelle einer Zeichenkette, bestehend aus drei Segmenten. Diese Schreibweise ist äquivalent zur vorherigen:
+
+```neon
+application:
+ mapping:
+ *: [App\Presentation, *, **Presenter]
+ Api: [App\Api, '', *Presenter]
+```
diff --git a/application/de/how-it-works.texy b/application/de/how-it-works.texy
index ae27a40ede..f58652fbde 100644
--- a/application/de/how-it-works.texy
+++ b/application/de/how-it-works.texy
@@ -1,9 +1,9 @@
-Wie funktionieren Bewerbungen?
+Wie funktionieren Anwendungen?
******************************
-Sie lesen gerade das Basisdokument der Nette-Dokumentation. Sie werden das ganze Prinzip der Webanwendungen kennenlernen. Nizza von A bis Z, vom Moment der Geburt bis zum letzten Atemzug des PHP-Skripts. Nach der Lektüre werden Sie wissen:
+Sie lesen gerade das grundlegende Dokument der Nette-Dokumentation. Sie werden das gesamte Funktionsprinzip von Webanwendungen kennenlernen. Schön von A bis Z, von dem Moment der Entstehung bis zum letzten Atemzug des PHP-Skripts. Nach dem Lesen werden Sie wissen:
- wie das Ganze funktioniert
- was Bootstrap, Presenter und DI-Container sind
@@ -12,90 +12,92 @@ Sie lesen gerade das Basisdokument der Nette-Dokumentation. Sie werden das ganze
-Struktur des Verzeichnisses .[#toc-directory-structure]
-=======================================================
+Verzeichnisstruktur
+===================
-Öffnen Sie ein Beispiel für eine Webanwendung namens [WebProject |https://github.com/nette/web-project] und beobachten Sie, wie die Dateien beschrieben werden.
+Öffnen Sie das Beispiel-Skelett einer Webanwendung namens [WebProject|https://github.com/nette/web-project] und beim Lesen können Sie sich die Dateien ansehen, von denen die Rede ist.
-Die Verzeichnisstruktur sieht in etwa so aus:
+Die Verzeichnisstruktur sieht ungefähr 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
-│ └── Bootstrap.php ← bootende Klasse Bootstrap
-├── bin/ ← Skripte für die Kommandozeile
+├── app/ ← Verzeichnis mit der Anwendung
+│ ├── Core/ ← grundlegende Klassen, die für den Betrieb notwendig sind
+│ │ └── RouterFactory.php ← Konfiguration der URL-Adressen
+│ ├── Presentation/ ← Presenter, Templates & Co.
+│ │ ├── @layout.latte ← Layout-Template
+│ │ └── Home/ ← Verzeichnis des Home-Presenters
+│ │ ├── HomePresenter.php ← Klasse des Home-Presenters
+│ │ └── default.latte ← Template der default-Aktion
+│ └── Bootstrap.php ← Startklasse Bootstrap
+├── assets/ ← Ressourcen (SCSS, TypeScript, Quellbilder)
+├── bin/ ← Skripte, die von der Kommandozeile ausgeführt werden
├── config/ ← Konfigurationsdateien
│ ├── common.neon
-│ └── local.neon
-├── log/ ← Fehlerprotokolle
+│ └── services.neon
+├── log/ ← protokollierte Fehler
├── temp/ ← temporäre Dateien, Cache, …
-├── vendor/ ← vom Composer installierte Bibliotheken
+├── vendor/ ← Bibliotheken, die mit Composer installiert wurden
│ ├── ...
-│ └── autoload.php ← Automatisches Laden der vom Composer installierten Bibliotheken
-├── www/ ← öffentliches Verzeichnis, Dokumentenstamm des Projekts
-│ ├── .htaccess ← mod_rewrite-Regeln usw.
-│ └── index.php ← Anfangsdatei, die die Anwendung startet
+│ └── autoload.php ← Autoloading aller installierten Pakete
+├── www/ ← öffentliches Verzeichnis oder Document-Root des Projekts
+│ ├── assets/ ← kompilierte statische Dateien (CSS, JS, Bilder, ...)
+│ ├── .htaccess ← mod_rewrite-Regeln
+│ └── index.php ← initiale Datei, mit der die Anwendung gestartet wird
└── .htaccess ← verbietet den Zugriff auf alle Verzeichnisse außer www
\--
-Sie können die Verzeichnisstruktur beliebig ändern, Ordner umbenennen oder verschieben, und dann einfach die Pfade zu `log/` und `temp/` in der Datei `Bootstrap.php` und den Pfad zu dieser Datei in `composer.json` im Abschnitt `autoload` ändern. Nichts weiter, keine komplizierte Neukonfiguration, keine ständigen Änderungen. Nette hat eine [intelligente automatische Erkennung |bootstrap#development-vs-production-mode].
+Die Verzeichnisstruktur können Sie beliebig ändern, Ordner umbenennen oder verschieben, sie ist völlig flexibel. Nette verfügt zudem über eine intelligente Autodetektion und erkennt automatisch den Speicherort der Anwendung einschließlich ihrer URL-Basis.
-Für etwas größere Anwendungen können wir Ordner mit Präsentatoren und Vorlagen in Unterverzeichnisse (auf der Festplatte) und in Namensräume (im Code) unterteilen, die wir [Module |modules] nennen.
+Bei etwas größeren Anwendungen können wir die Ordner mit Presentern und Templates [in Unterverzeichnisse aufteilen |directory-structure#Presenter und Templates] und Klassen in Namespaces, die wir Module nennen.
-Das Verzeichnis `www/` ist das öffentliche Verzeichnis oder die Dokumenten-Wurzel des Projekts. Sie können es umbenennen, ohne etwas anderes auf der Anwendungsseite einstellen zu müssen. Sie müssen nur [das Hosting |nette:troubleshooting#How to change or remove www directory from URL] so [konfigurieren |nette:troubleshooting#How to change or remove www directory from URL], dass die Dokumentenwurzel in dieses Verzeichnis führt.
+Das Verzeichnis `www/` stellt das sogenannte öffentliche Verzeichnis oder Document-Root des Projekts dar. Sie können es umbenennen, ohne etwas Weiteres auf Anwendungsseite einstellen zu müssen. Es ist nur notwendig, [das Hosting zu konfigurieren |nette:troubleshooting#Wie ändert oder entfernt man das Verzeichnis www aus der URL], damit der Document-Root auf dieses Verzeichnis zeigt.
-Sie können das WebProjekt auch direkt herunterladen, einschließlich Nette, indem Sie [Composer |best-practices:composer] verwenden:
+WebProject können Sie sich auch direkt inklusive Nette herunterladen, und zwar mittels [Composer |best-practices:composer]:
```shell
composer create-project nette/web-project
```
-Unter Linux oder macOS setzen Sie die [Schreibrechte |nette:troubleshooting#Setting directory permissions] für die Verzeichnisse `log/` und `temp/`.
+Unter Linux oder macOS setzen Sie für die Verzeichnisse `log/` und `temp/` [Schreibrechte |nette:troubleshooting#Einstellung der Verzeichnisberechtigungen].
-Die WebProject-Anwendung ist einsatzbereit, es muss nichts weiter konfiguriert werden und Sie können sie direkt im Browser anzeigen, indem Sie auf den Ordner `www/` zugreifen.
+Die Anwendung WebProject ist startbereit, es muss überhaupt nichts konfiguriert werden und Sie können sie direkt im Browser anzeigen, indem Sie auf den Ordner `www/` zugreifen.
-HTTP-Anfrage .[#toc-http-request]
-=================================
+HTTP-Anfrage
+============
-Alles beginnt damit, dass ein Benutzer die Seite in einem Browser öffnet und der Browser mit einer HTTP-Anfrage an den Server klopft. Die Anfrage geht an eine PHP-Datei, die sich im öffentlichen Verzeichnis `www/` befindet, also an `index.php`. Nehmen wir an, dass es sich um eine Anfrage an `https://example.com/product/123` zugeordnet und ausgeführt.
+Alles beginnt in dem Moment, in dem der Benutzer im Browser eine Seite öffnet. Also wenn der Browser beim Server mit einer HTTP-Anfrage anklopft. Die Anfrage zielt auf eine einzige PHP-Datei, die sich im öffentlichen Verzeichnis `www/` befindet, und das ist `index.php`. Nehmen wir an, es handelt sich um eine Anfrage an die Adresse `https://example.com/product/123`. Dank geeigneter [Serverkonfiguration |nette:troubleshooting#Wie konfiguriert man den Server für schöne URLs Pretty URLs] wird auch diese URL auf die Datei `index.php` abgebildet und diese wird ausgeführt.
-Seine Aufgabe ist:
+Ihre Aufgabe ist es:
1) die Umgebung zu initialisieren
-2) Abrufen der Fabrik
+2) die Factory zu erhalten
3) die Nette-Anwendung zu starten, die die Anfrage bearbeitet
-Welche Art von Fabrik? Wir stellen keine Traktoren her, sondern Websites! Warten Sie, ich erkläre es Ihnen gleich.
+Welche Factory denn? Wir stellen doch keine Traktoren her, sondern Webseiten! Bleiben Sie dran, das wird gleich erklärt.
-Mit "die Umgebung initialisieren" meinen wir zum Beispiel, dass [Tracy |tracy:] aktiviert wird, ein erstaunliches Werkzeug zur Protokollierung oder Visualisierung von Fehlern. Es protokolliert Fehler auf dem Produktionsserver und zeigt sie direkt auf dem Entwicklungsserver an. Daher muss bei der Initialisierung auch entschieden werden, ob die Site im Produktions- oder im Entwicklermodus läuft. Hierfür verwendet Nette eine automatische Erkennung: Wenn Sie die Site auf localhost ausführen, läuft sie im Entwicklermodus. Sie müssen nichts konfigurieren, und die Anwendung ist sowohl für die Entwicklung als auch für den Produktionseinsatz bereit. Diese Schritte werden im Kapitel über die [Bootstrap-Klasse |bootstrap] durchgeführt und ausführlich beschrieben.
+Mit „Initialisierung der Umgebung“ meinen wir zum Beispiel, dass [Tracy|tracy:] aktiviert wird, ein großartiges Werkzeug zur Protokollierung oder Visualisierung von Fehlern. Auf dem Produktionsserver protokolliert es Fehler, auf dem Entwicklungsserver zeigt es sie direkt an. Zur Initialisierung gehört also auch die Entscheidung, ob die Website im Produktions- oder Entwicklungsmodus läuft. Dazu verwendet Nette eine [intelligente Autodetektion |bootstrapping#Entwicklungs- vs. Produktionsmodus]: Wenn Sie die Website auf localhost starten, läuft sie im Entwicklungsmodus. Sie müssen also nichts konfigurieren und die Anwendung ist direkt bereit sowohl für die Entwicklung als auch für den Live-Einsatz. Diese Schritte werden durchgeführt und sind im Kapitel über die [Bootstrap-Klasse|bootstrapping] ausführlich beschrieben.
-Der dritte Punkt (ja, wir haben den zweiten übersprungen, aber wir werden darauf zurückkommen) ist das Starten der Anwendung. Die Bearbeitung von HTTP-Anfragen in Nette erfolgt durch die Klasse `Nette\Application\Application` (im Folgenden `Application` genannt). Wenn wir also sagen "eine Anwendung starten", meinen wir den Aufruf einer Methode mit dem Namen `run()` auf einem Objekt dieser Klasse.
+Der dritte Punkt (ja, den zweiten haben wir übersprungen, aber wir kommen darauf zurück) ist der Start der Anwendung. Die Bearbeitung von HTTP-Anfragen übernimmt in Nette die Klasse `Nette\Application\Application` (weiter `Application`), wenn wir also sagen, die Anwendung starten, meinen wir konkret den Aufruf der Methode mit dem treffenden Namen `run()` auf einem Objekt dieser Klasse.
-Nette ist ein Mentor, der Sie anleitet, saubere Anwendungen nach bewährten Methoden zu schreiben. Und die bewährteste heißt **dependency injection**, abgekürzt DI. Wir wollen Sie an dieser Stelle nicht mit der Erklärung von DI belasten, dafür gibt es ein [eigenes Kapitel |dependency-injection:introduction], wichtig ist, dass die Schlüsselobjekte in der Regel von einer Fabrik für Objekte namens **DI-Container** (abgekürzt DIC) erzeugt werden. Ja, das ist die Fabrik, die vor einiger Zeit erwähnt wurde. Und sie erstellt auch das `Application` Objekt für uns, also brauchen wir zuerst einen Container. Den holen wir uns mit der Klasse `Configurator` und lassen ihn das Objekt `Application` erzeugen, rufen die Methode `run()` auf und starten damit die Nette-Anwendung. Das ist genau das, was in der Datei [index.php |bootstrap#index.php] passiert.
+Nette ist ein Mentor, der Sie dazu anleitet, saubere Anwendungen nach bewährten Methoden zu schreiben. Und eine der absolut bewährtesten heißt **Dependency Injection**, abgekürzt DI. An dieser Stelle möchten wir Sie nicht mit der Erklärung von DI belasten, dafür gibt es ein [eigenes Kapitel|dependency-injection:introduction], wesentlich ist die Konsequenz, dass uns Schlüsselobjekte üblicherweise von einer Objekt-Factory erstellt werden, die **DI-Container** (abgekürzt DIC) genannt wird. Ja, das ist die Factory, von der vorhin die Rede war. Und sie stellt uns auch das `Application`-Objekt her, deshalb benötigen wir zuerst den Container. Wir erhalten ihn mittels der Klasse `Configurator` und lassen ihn das `Application`-Objekt erstellen, rufen darauf die Methode `run()` auf und damit startet die Nette-Anwendung. Genau das geschieht in der Datei [index.php |bootstrapping#index.php].
-Nette-Anwendung .[#toc-nette-application]
-=========================================
+Nette Application
+=================
-Die Klasse Application hat eine einzige Aufgabe: Sie soll auf eine HTTP-Anfrage antworten.
+Die Klasse Application hat eine einzige Aufgabe: auf eine HTTP-Anfrage zu antworten.
-In Nette geschriebene Anwendungen sind in viele so genannte Presenter unterteilt (in anderen Frameworks stößt man vielleicht auf den Begriff Controller, der dasselbe bedeutet), bei denen es sich um Klassen handelt, die eine bestimmte Website-Seite repräsentieren: z. B. Homepage; Produkt im E-Shop; Anmeldeformular; Sitemap-Feed usw. Die Anwendung kann zwischen einem und Tausenden von Presentern haben.
+Anwendungen, die in Nette geschrieben sind, gliedern sich in viele sogenannte Presenter (in anderen Frameworks können Sie auf den Begriff Controller stoßen, es handelt sich um dasselbe), das sind Klassen, von denen jede eine bestimmte Webseite repräsentiert: z.B. die Homepage; ein Produkt im E-Shop; ein Anmeldeformular; ein Sitemap-Feed usw. Eine Anwendung kann von einem bis zu Tausenden von Presentern haben.
-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.
+Die Application beginnt damit, den sogenannten Router zu bitten, zu entscheiden, welchem der Presenter die aktuelle Anfrage zur Bearbeitung übergeben werden soll. Der Router entscheidet, wessen Verantwortung das ist. Er schaut sich die Eingabe-URL `https://example.com/product/123` an und entscheidet auf Basis seiner Konfiguration, dass dies die Arbeit z.B. für den **Presenter** `Product` ist, von dem er als **Aktion** die Anzeige (`show`) des Produkts mit `id: 123` verlangen wird. Das Paar Presenter + Aktion wird üblicherweise durch einen Doppelpunkt getrennt als `Product:show` geschrieben.
-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.
+Also hat der Router die URL in das Paar `Presenter:action` + Parameter transformiert, in unserem Fall `Product:show` + `id: 123`. Wie ein solcher Router aussieht, können Sie sich in der Datei `app/Core/RouterFactory.php` ansehen und wir beschreiben ihn detailliert im Kapitel [Routing].
-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.
+Gehen wir weiter. Die Application kennt nun den Namen des Presenters und kann weitermachen. Indem sie ein Objekt der Klasse `ProductPresenter` erstellt, was der Code des Presenters `Product` ist. Genauer gesagt, bittet sie den DI-Container, den Presenter zu erstellen, denn für das Erstellen ist er da.
-Der Presenter könnte wie folgt aussehen:
+Der Presenter kann etwa so aussehen:
```php
class ProductPresenter extends Nette\Application\UI\Presenter
@@ -107,98 +109,92 @@ class ProductPresenter extends Nette\Application\UI\Presenter
public function renderShow(int $id): void
{
- // wir beziehen Daten aus dem Modell und übergeben sie an die Vorlage
+ // Wir holen Daten aus dem Modell und übergeben sie an das Template
$this->template->product = $this->repository->getProduct($id);
}
}
```
-Die Anfrage wird vom Präsentator bearbeitet. Und die Aufgabe ist klar: Führe die Aktion `show` mit `id: 123` aus. Was in der Sprache der Moderatoren bedeutet, dass die Methode `renderShow()` aufgerufen wird und im Parameter `$id` steht `123`.
+Die Bearbeitung der Anfrage übernimmt der Presenter. Und die Aufgabe lautet klar: führe die Aktion `show` mit `id: 123` aus. Was in der Sprache der Presenter bedeutet, dass die Methode `renderShow()` aufgerufen wird und im Parameter `$id` den Wert `123` erhält.
-Ein Presenter kann mehrere Aktionen verarbeiten, also mehrere Methoden haben `render
-Wir werden lernen, wie man Presenter und Vorlagen in Nette schreibt. Nach der Lektüre werden Sie wissen:
+Wir werden lernen, wie man Presenter und Templates in Nette schreibt. Nach dem Lesen werden Sie wissen:
-- wie der Presenter funktioniert
+- wie ein Presenter funktioniert
- was persistente Parameter sind
-- wie man eine Vorlage rendert
+- wie Templates gerendert werden
-[Wir wissen bereits, |how-it-works#nette-application] dass ein Presenter eine Klasse ist, die eine bestimmte Seite einer Webanwendung darstellt, z. B. eine Homepage, ein Produkt im E-Shop, ein Anmeldeformular, ein Sitemap-Feed usw. Die Anwendung kann von einem bis zu Tausenden von Presentern haben. In anderen Frameworks werden sie auch als Controller bezeichnet.
+[Wir wissen bereits |how-it-works#Nette Application], dass ein Presenter eine Klasse ist, die eine bestimmte Seite einer Webanwendung repräsentiert, z. B. die Homepage, ein Produkt in einem E-Shop, ein Anmeldeformular, einen Sitemap-Feed usw. Eine Anwendung kann einen bis tausende Presenter haben. In anderen Frameworks werden sie auch Controller genannt.
-Normalerweise bezieht sich der Begriff Presenter auf einen Abkömmling der Klasse [api:Nette\Application\UI\Presenter], die für Web-Interfaces geeignet ist und die wir im weiteren Verlauf dieses Kapitels besprechen werden. Im allgemeinen Sinne ist ein Presenter jedes Objekt, das die Schnittstelle [api:Nette\Application\IPresenter] implementiert.
+Normalerweise ist mit dem Begriff Presenter ein Nachkomme der Klasse [api:Nette\Application\UI\Presenter] gemeint, der für die Generierung von Weboberflächen geeignet ist und dem wir uns im Rest dieses Kapitels widmen werden. Im allgemeinen Sinn ist ein Presenter jedes Objekt, das das Interface [api:Nette\Application\IPresenter] implementiert.
-Lebenszyklus eines Presenters .[#toc-life-cycle-of-presenter]
-=============================================================
+Lebenszyklus des Presenters
+===========================
-Die Aufgabe des Presenters besteht darin, die Anfrage zu verarbeiten und eine Antwort zu liefern (die eine HTML-Seite, ein Bild, eine Routing usw. sein kann).
+Die Aufgabe des Presenters ist es, eine Anfrage zu bearbeiten und eine Antwort zurückzugeben (dies kann eine HTML-Seite, ein Bild, eine Weiterleitung usw. sein).
-Am Anfang steht also eine Anfrage. Dabei handelt es sich nicht direkt um eine HTTP-Anfrage, sondern um ein [api:Nette\Application\Request] -Objekt, in das die HTTP-Anfrage mithilfe eines Routers umgewandelt wurde. Mit diesem Objekt kommen wir in der Regel nicht in Berührung, da der Präsentator die Verarbeitung der Anfrage geschickt an spezielle Methoden delegiert, die wir jetzt sehen werden.
+Zu Beginn wird ihm also eine Anfrage übergeben. Dies ist keine direkte HTTP-Anfrage, sondern ein Objekt [api:Nette\Application\Request], in das die HTTP-Anfrage mithilfe des Routers umgewandelt wurde. Mit diesem Objekt kommen wir normalerweise nicht in Berührung, da der Presenter die Verarbeitung der Anfrage geschickt an weitere Methoden delegiert, die wir uns jetzt ansehen werden.
[* lifecycle.svg *] *** *Lebenszyklus des Presenters* .<>
-Die Abbildung zeigt eine Liste von Methoden, die nacheinander von oben nach unten aufgerufen werden, sofern sie existieren. Keine von ihnen muss existieren, wir können einen völlig leeren Presenter ohne eine einzige Methode haben und ein einfaches statisches Web darauf aufbauen.
+Das Bild zeigt eine Liste von Methoden, die der Reihe nach von oben nach unten aufgerufen werden, sofern sie existieren. Keine davon muss existieren, wir können einen völlig leeren Presenter ohne eine einzige Methode haben und darauf eine einfache statische Website aufbauen.
`__construct()`
---------------
-Der Konstruktor gehört nicht direkt zum Lebenszyklus des Präsentators, da er zum Zeitpunkt der Erstellung des Objekts aufgerufen wird. Aber wir erwähnen ihn wegen seiner Bedeutung. Der Konstruktor (zusammen mit der [Methode inject |best-practices:inject-method-attribute]) wird verwendet, um Abhängigkeiten zu übergeben.
+Der Konstruktor gehört nicht ganz zum Lebenszyklus des Presenters, da er im Moment der Objekterstellung aufgerufen wird. Aber wir erwähnen ihn wegen seiner Wichtigkeit. Der Konstruktor (zusammen mit der [inject-Methode|best-practices:inject-method-attribute]) dient zur Übergabe von Abhängigkeiten.
-Der Presenter sollte sich nicht um die Geschäftslogik der Anwendung kümmern, nicht in die Datenbank schreiben und aus ihr lesen, keine Berechnungen durchführen, usw. Dies ist die Aufgabe für Klassen aus einer Schicht, die wir Modell nennen. Zum Beispiel kann die Klasse `ArticleRepository` für das Laden und Speichern von Artikeln zuständig sein. Damit der Presenter sie verwenden kann, wird sie [mittels Dependency Injection übergeben |dependency-injection:passing-dependencies]:
+Ein Presenter sollte nicht die Geschäftslogik der Anwendung handhaben, aus der Datenbank schreiben und lesen, Berechnungen durchführen usw. Dafür gibt es Klassen aus der Schicht, die wir als Model bezeichnen. Zum Beispiel kann die Klasse `ArticleRepository` für das Laden und Speichern von Artikeln zuständig sein. Damit der Presenter damit arbeiten kann, lässt er sie sich [mittels Dependency Injection übergeben |dependency-injection:passing-dependencies]:
```php
@@ -50,44 +50,44 @@ class ArticlePresenter extends Nette\Application\UI\Presenter
`startup()`
-----------
-Unmittelbar nach Erhalt der Anfrage wird die Methode `startup ()` aufgerufen. Sie können sie verwenden, um Eigenschaften zu initialisieren, Benutzerrechte zu prüfen, usw. Es ist erforderlich, immer den Vorgänger `parent::startup()` aufzurufen.
+Unmittelbar nach Erhalt der Anfrage wird die Methode `startup()` aufgerufen. Sie können sie zur Initialisierung von Properties, zur Überprüfung von Benutzerberechtigungen usw. verwenden. Es ist erforderlich, dass die Methode immer den Vorfahren `parent::startup()` aufruft.
`action