nette/application 3.2: presenters in their own directories

David Grudl

I've added native support for placing presenters in their own separate directories to Nette Application 3.2. (Currently in the 3.2.x-dev branch).

I mean this structure, where XyzPresenter and its templates are located in the Xyz folder.

├── <b>@layout.latte</b>
├── <b>Home/</b>
│   ├── <b>HomePresenter.php</b>
│   └── <b>default.latte</b>
├── <b>Article/</b>
│   ├── <b>ArticlePresenter.php</b>
│   └── <b>add.latte</b>
│   └── <b>edit.latte</b>

In the mapping definition, the pair Xyz\Xyz is represented by **. The following entry, for example, maps the presenter Admin:Dashboard to the class App\Modules\Admin\Dashboard\DashboardPresenter:

application:
	mapping: App\Modules\*\**Presenter

What about templates? If there is no templates/ subfolder (or superfolder), the presenter's formatTemplateFiles() method now also looks for templates directly in the presenter's folder. The same applies to the formatLayoutTemplateFiles() method, which also allows placing a layout template one folder up, i.e., at the same level as the presenter directories (see structure).

I would be glad if you could test this and write any comments and suggestions.

Rick Strafy

Nice step forward, mainly because nowadays we have HomeTemplate.php and ArticleTemplate.php in same folder and a lot of new people have problem with configuring the right mapping, since default web app and sandbox are without default module and there is very simple mapping.

I'm against ditching merging* php and template files, but I know that lot of people use it this way in nette so I guess as a fallback it's OK, if it's not encouraging people to use it this way, in another frameworks (laravel, django, symfony, js frameworks) there is a separated folder, almost always at the top level outside the app sources.

Combined option is good for simple apps, but when app is getting bigger, there are latte files for sidebar, header, navbar, footer, modals, breadcrumb, and then it becomes messy and php code structure needs to adjust to template directory structure and vice versa.

Last edited by Rick Strafy (2024-04-29 00:12)

David Grudl

What you mean by “ditching php and template files”?

After many years of working with different directory structures, I think it is ideal to have the presenter, its templates and various other possible helper classes (like a PHP template) together in one folder. It may even contain a subfolder with components if it is a component used exclusively in this single presenter.

Modules then, in the simplest case, represent groups of such directories. However, there are often other directories with model classes, or CLI commands etc. Units are therefore grouped by domain, not by file or class type.

The directory structure used in other frameworks, i.e. grouped by type, seems to me to be obsolete. I find group by feature more practical. But of course Nette never dictated any structure, it's purely up to the taste of the programmer.

Rick Strafy

After many years of working with different directory structures, I think it is ideal to have the presenter, its templates and various other possible helper classes (like a PHP template) together in one folder. It may even contain a subfolder with components if it is a component used exclusively in this single presenter.

It's great how it can be branch out like a tree into another components and helper classes, or even another submodules (for instance Admin → Domain module on webhosting where are all associated presenters like Ftp, Email, Dns..).

Modules then, in the simplest case, represent groups of such directories. However, there are often other directories with model classes, or CLI commands etc. Units are therefore grouped by domain, not by file or class type.

Console commands are maybe better off in app/Module/Console, it's on same level as Front/Admin module, they are all entry-points into the app, http or console and they work with Model (business) code, that is usually all separated into app/Model, because having model logic inside controller layer is not very clean approach, but that's also a personal preference. I can't imagine having combined model and controller layer into same folders, but I'm curious to see and try such a codebase.

I'm just against mixing latte templates with php code, it's my personal preference, I've seen a lot of codebases and I find separate template folder more organized with better flexibility to create directories based on specific layout, and it's more standardized across another frameworks. But I know this is a controversial topic and maybe 1/2 of nette programmers have templates amongst presenters.