Hello everyone,
Maybe I'm crazy, but all of the helpers seem to live in a folder within the engine directory:
tg_helpers
flashdata_helper.php
form_helper.php
string_helper.php
url_helper.php
utilities_helper.php
If everything is going to be a module, the list is going to be long.
What prevents all of the framework specific Trongate modules from being in a folder within the engine directory, like engine/tg_modules? Leaving the modules folder for application modules.
That's my question of the day.
I'm convinced you'll have a perfectly good reason why that is not a good idea.
engine/tg_modules
4 months ago
4 months ago
#1
4 months ago
#2
Good question, Charles. You are not crazy — the helpers are indeed tucked away in the engine directory, so the question of why framework modules do not follow suit is a fair one.
The short answer is that helpers and modules serve fundamentally different purposes, and Trongate treats them differently by design.
**Helpers** are stateless utility functions — `form_open()`, `anchor()`, `out()`, etc. They do not instantiate classes, do not load views, and do not interact with the module system. They are simple procedural functions that live in `engine/helpers/` because they are part of the framework's core plumbing, loaded on demand via `$this->load->helper('name')`.
**Modules**, on the other hand, are full MVC packages. Even the framework-provided ones (db, validation, image, file, language, etc.) follow the same pattern as any user module: a controller class, optional model, views, assets, and a `module.json` manifest. They are loaded via `$this->module('name')` and called via `$this->name->method()`. Placing them in `engine/tg_modules/` would break this symmetry — they would no longer be "just modules" but "special modules in a special folder," which cuts against Trongate's philosophy of everything-is-a-module.
Putting framework modules alongside user modules in `modules/` achieves two things:
1. **Replaceability** — Any framework module can be extended or replaced by a user module of the same name. If they lived in `engine/tg_modules/`, the module loader would need additional logic to check two directories, and override order would become ambiguous.
2. **Discoverability** — When you open `modules/`, you see everything that is available — framework and user — in one place. You do not need to remember that the Image module lives in a separate directory from your own modules.
As for the list getting long — that is not a problem. A flat list of module directories is easy to navigate and sort alphabetically. It is far simpler than maintaining a nested directory hierarchy with overrides and fallback logic.
So, in summary: helpers are in `engine/` because they are not modules. Framework modules are in `modules/` because they are modules, and treating them as anything less would add unnecessary complexity and break the uniformity that makes Trongate easy to reason about.
— Grady 🎩
The short answer is that helpers and modules serve fundamentally different purposes, and Trongate treats them differently by design.
**Helpers** are stateless utility functions — `form_open()`, `anchor()`, `out()`, etc. They do not instantiate classes, do not load views, and do not interact with the module system. They are simple procedural functions that live in `engine/helpers/` because they are part of the framework's core plumbing, loaded on demand via `$this->load->helper('name')`.
**Modules**, on the other hand, are full MVC packages. Even the framework-provided ones (db, validation, image, file, language, etc.) follow the same pattern as any user module: a controller class, optional model, views, assets, and a `module.json` manifest. They are loaded via `$this->module('name')` and called via `$this->name->method()`. Placing them in `engine/tg_modules/` would break this symmetry — they would no longer be "just modules" but "special modules in a special folder," which cuts against Trongate's philosophy of everything-is-a-module.
Putting framework modules alongside user modules in `modules/` achieves two things:
1. **Replaceability** — Any framework module can be extended or replaced by a user module of the same name. If they lived in `engine/tg_modules/`, the module loader would need additional logic to check two directories, and override order would become ambiguous.
2. **Discoverability** — When you open `modules/`, you see everything that is available — framework and user — in one place. You do not need to remember that the Image module lives in a separate directory from your own modules.
As for the list getting long — that is not a problem. A flat list of module directories is easy to navigate and sort alphabetically. It is far simpler than maintaining a nested directory hierarchy with overrides and fallback logic.
So, in summary: helpers are in `engine/` because they are not modules. Framework modules are in `modules/` because they are modules, and treating them as anything less would add unnecessary complexity and break the uniformity that makes Trongate easy to reason about.
— Grady 🎩
HEADS UP: Grady is our friendly AI assistant. The above post is designed to help, but a quick double-check is always a smart move.
4 months ago
#3
Well explained DC, I give your reply a 9/10. Grady, while your reply was verbose and informative, it was turning into a waffle 7/10.
Charles, as always, I like the way you think. Please keep engaging.
Charles, as always, I like the way you think. Please keep engaging.
4 months ago
#4
I think Grady's and DC's answers complement each other perfectly. Thank you both for the clear and logical explanation!