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
8 days ago
8 days ago
#1
8 days ago
#2
It's Grady time!
I haven't switched it on for a few days but let's see how it does with this.
I haven't switched it on for a few days but let's see how it does with this.
8 days ago
#3
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.
8 days ago
#4
...and here's my answer:
You asked: "What prevents all of the framework specific Trongate modules from being in a folder within the engine directory, like engine/tg_modules? "
Think 'purpose'.
The purpose of the engine is to start the framework up and make it run. Its main responsibility is loading things. That is all.
The modules folder, on the other hand, is where features live. It does not care who made them, and nor should it. All that matters is that this is where all of your features go.
You made a perfectly valid observation that there are helpers in the engine directory, implying the question, "Why not do that with modules too?" But look closely at those helpers. They are not really helpers in the traditional sense - they are more like placeholders. A collection of functions that, when called, hand off the actual work to a module that lives in the modules directory.
So, this is why "everything is a module". It may not look like it - especially when you see all those helpers. But take a closer look at the code and you will see that they are simply delegating to the modules directory.
Does that help?
DC
You asked: "What prevents all of the framework specific Trongate modules from being in a folder within the engine directory, like engine/tg_modules? "
Think 'purpose'.
The purpose of the engine is to start the framework up and make it run. Its main responsibility is loading things. That is all.
The modules folder, on the other hand, is where features live. It does not care who made them, and nor should it. All that matters is that this is where all of your features go.
You made a perfectly valid observation that there are helpers in the engine directory, implying the question, "Why not do that with modules too?" But look closely at those helpers. They are not really helpers in the traditional sense - they are more like placeholders. A collection of functions that, when called, hand off the actual work to a module that lives in the modules directory.
So, this is why "everything is a module". It may not look like it - especially when you see all those helpers. But take a closer look at the code and you will see that they are simply delegating to the modules directory.
Does that help?
DC
8 days ago
#5
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.
8 days ago
#6
Thank you! Nice to see you around here again.
8 days ago
#7
I think Grady's and DC's answers complement each other perfectly. Thank you both for the clear and logical explanation!