Elegant Presenter Structuring

6 months ago by David Grudl  

Do you appreciate order and structure? When everything is exactly where it should be, making it easy to navigate? Of course—who wouldn’t. Nette Framework 3.2 introduces a new way to organize presenters and their templates in your application.

Nette now allows each presenter to have its own separate directory. This means you can keep all files related to a specific presenter, from PHP files to Latte templates, together in one folder. This facilitates navigation in your project and enhances clarity.

Imagine this structure:

├── @layout.latte
├── Home/
│   ├── HomePresenter.php
│   ├── HomeTemplate.php
│   └── default.latte
├── Article/
│   ├── ArticlePresenter.php
│   ├── ArticleTemplate.php
│   ├── add.latte
│   └── edit.latte

Each presenter has its folder containing everything needed. No more lengthy searches for templates in subdirectories.

How does it work?

Thanks to the new wildcard ** in mapping, you can define that a presenter should be in its eponymous folder:

application:
    mapping: App\UI\*\**Presenter

This setting ensures that, for example, the presenter Admin:Dashboard is mapped to the class App\UI\Admin\Dashboard\DashboardPresenter.

What about templates?

If you prefer to keep templates in a separate folder as before, there’s no need to worry. Nette now intelligently searches for templates both in the templates folder and in the presenter’s folder, if the templates directory does not exist.

Similarly, it works with @layout.latte. If the templates directory does not exist, it searches first in the presenter’s folder and then in the parent folders, up to the level of module nesting.

How to start using this new feature?

Just update the mapping and move the files. In PhpStorm, press F6 above the class name to change the namespace. Template files need to be moved manually.

This directory structure is also used in the nette/web-project skeleton. The folder that contains all the presenters, their templates, and any auxiliary classes is App\UI. It’s not the usual Module because such a name isn't very informative and is quite similar to the commonly used Model. If you are considering where to place various other auxiliary classes, consider using an Accessory folder:

app/
├── UI/
│   ├── Accessory/
│   │   ├── FormFactory.php
│   │   └── AdminLayout.php
│   ├── Dashboard/
│   │   ├── DashboardPresenter.php
│   │   └── default.latte
│   └── ...

This method not only simplifies the file organization but also aligns with modern coding practices by making your application structure more modular and easier to maintain.

Comments

  1. Thanks! I like this new structure.

    6 months ago

Sign in to submit a comment