I’m sorry it came across as smug and cryptic. I simply tried to keep it straight to the point, updating Templates.php to wrap the render logic in a closure then using $render_closure ->bindTo($calling_controller); can be a way to support $this->validation->validation_errors() in view files.

In v2 I believe it’s in Trongate.php on view method.

[code lang=“php”]
$cb = function (string $view_path, array $data): string {
extract($data);
ob_start();
require $view_path;
return ob_get_clean();
};
$cb = $cb->bindTo($this, static::class);
$html = $cb($view_path, $data);
[/code]

One sharp edge I can see with this approach though, Calling Modules::run(“module”, “render_something”); leads to different $this than parent, if accessing the parent module from effectively the child here is desirable then consider passing $this to Modules::run and binding it as $parent

I followed what you were saying up until the last part.

Look, your intelligence is not in doubt and you're probably fifty steps ahead of all of us. All I can tell you is I read your comment from earlier on about an hour or two before going onto YouTube and it completely threw me.

Anyway, let's not worry about it. Maybe you're a genius and that's the takeaway!

As for your post? It's very late at night and I don't entirely understand it. Hopefully somebody else who's much smarter than me can shed some light on it. If not then hopefully I'll have time to look into whatever you're saying in the near future.

Macho love to you!

DC

By the way, I had a little glitch towards the end of my demo on YouTube. Don't worry about it. I should have it fixed very soon. I'm on the case.

DC,

I found the cause of the glitch; in Validation->set_rules(), as you're looping through $tests_to_run, you now break out of the loop on the first validation error. Previously, all tests were run.

So, for example, in the code shown in the live stream, in Tasks.php, if you change 'required|min_length[5]|max_length[55]|callback_title_check' to 'callback_title_check', it will work.

---

Unrelated to the glitch, I tested the validation public interface against the current version of the framework, focusing on validation->set_rules(), validation->run(), and the validation_errors() helper.

The issue mentioned above is the main thing I've found. A smaller point is that the validation_errors() HTML output is different, previously the errors were listed in paragraphs with hardcoded inline styles, now they're in an unordered list where the list element has two classes.

I don't have an objection to either, I'm just reporting changes in behavior.

Thank you for that.

It turns out the validation module was cool and last night's error was just a coding mistake from me.

I've just uploaded a new video explaining all and also mentioning the error behaviour that you correctly identified.

The URL is: https://www.youtube.com/watch?v=GXyvrpHe7i8

Cheers!

Hey DC,

The validation module looks rather solid. However, I found a couple of edge cases, where if you were to change language more than once in a single request, it would result in displaying incorrect translated errors.

`$this->validation->set_language('en'`) to `$this->validation->set_language('fr')` then back to `$this->validation->set_language('en')`

1. The model is not aware of the language change.
The set_language() function only updates the $_SESSION variable. However, the Validation_model is instantiated when validation begins, so it retains the default language translations. If the language changes mid-request, the model does not update automatically.

Fix: Modify set_language() within Validation.php so it explicitly refreshes the model’s language data:
and change `load_validation_language()` in `Validation_model.php` from `private` to `public` - see below snippet.

2. `require_once` prevents multiple validations within a single request
When handling multiple forms in different languages during the same request, require_once causes issues. For instance, switching from English to French and then back to English will fail because PHP will not include the English file again. As a result, the translation dictionary is not reloaded, and the system falls back to generic English error messages.

Fix: In Validation_model.php, make load_validation_language() public and replace:
Here is a test module `Language_tester.php` to see what I'm talking about:


Cheers,
Si

Very nice Simon

VALIDATION MODULE - TEST REPORT (March 21, 2026)

Form validation:
----------------
✅ [PASS] General validation errors: all input types are validated correctly.
✅ [PASS] Inline validation errors: all input types are validated correctly.
⚠️ [WARNING] The first time I open the form after login, there is an empty, red validation errors container at top of the create form. (If form is using general validation errors.)

Screenshot:


⚠️ [WARNING] The first time I open the form after login, the form shakes as if there were validation errors. (If form is using inline validation errors.) I think the cause might be the same as with the general validation errors.

Document tester:
-----------------
✅ [PASS] File type check: OK
✅ [PASS] File size check: OK
⚠️ [WARNING] Deprecated: Function finfo_close() is deprecated since 8.5, as finfo objects are freed automatically in /Users/zatik/www/validacious/modules/file/File.php on line 682
⚠️ [WARNING] Document_tester.php line: 39: $filename is always empty, perhaps the segment() method should be used here?

Image Validator Tester:
-----------------------
✅ [PASS] Is image: OK
✅ [PASS] Allowed types: OK
✅ [PASS] Dimensions check: OK
✅ [PASS] Security threak: OK
⚠️ [WARNING] Deprecated: Function finfo_close() is deprecated since 8.5, as finfo objects are freed automatically in /Users/zatik/www/validacious/modules/image/Image.php on line 360
⚠️ [WARNING] Deprecated: Function imagedestroy() is deprecated since 8.5, as it has no effect since PHP 8.0 in /Users/zatik/www/validacious/modules/image/Image.php on line 825

Please let me know if you need further clarification on any of the points above or want me to do a deeper dive into any part of the validation module.

All in all, the new validation module is solid and a work very well done.

Balázs

Thank you one and all.

REGARDING THE SASIN THING

I appreciate the explanation and that was a great explanation from Dafa. Thanks! I was completely off the mark with that. We've changed some of the internals of the framework so that we can call validation_errors() from a view file, while having all of the validation management handed over to the validation module – where it belongs.

I had erroneously assumed that Sasin had come up with an alternative mechanism for tracking the module to be called (i.e. the 'validation' module). It turns out he was, in fact, discussing a way of having view files call methods from their parent modules.

For example:


If I have now understood correctly, the caveat is that $this may not work when used in a Modules::run() scenario. However, that's not a pattern that anybody uses! So all we'd have to do is just say in the docs, "hey, don't use $this when invoking modules::run()".

I'm now about 80% sure that I've understood this. If I've got things wrong, I apologise. If you're reading this and you haven't got a clue about this whole thing then ...welcome to my world!

CONCLUSION

"Sasin's Tweak" is awesome. It brilliantly solves the following problem:

'How does the view file access the methods that belong to its associated controller file?'

However, even though it's an awesome tweak, it's not directly related to the validation module. Indeed, I think it's probably best to introduce that as an upgrade that stands on its own merit.

To be clear: I really enjoyed the YouTube "launch" the other day. Doing those little launch videos from time to time sends out the message that the framework is active and growing. It may not be on the same scale as the Apple Town Hall but the feedback from doing that has been great. We are NOT yet at the stage of having this framework actively marketed. That happens after other things have been built. When "active marketing" kicks in, you'll see other YouTubers who are more popular than me talking about the framework. Nevertheless, I see the launch videos as a key component for promoting the framework.

That being said, I think I'd like to hold off on Sasin's Tweak until the next launch event. When that time comes, perhaps we can have Sasin come on as a special guest to introduce the thing.

I hope that is cool.

A FEW COMMENTS REGARDING DAFA'S STUFF AND NINJA'S SUGGESTIONS

That was all brilliantly explained and thank you. In the case of Dafa, you described the problem then showed us the actual code for solving the thing. It's difficult to imagine a better response.

In the case of Ninja's thing: Whatever mysterious black magic you used to produce those test results, I want it!

QUICK AND INAPPROPRIATE CHANGE OF TOPIC!

Recently, I've been thinking about ways that I can have you two appearing on YouTube doing tutorials for the framework. I hope it happens and if it does happen, it'll be super cool. This is probably not the time and place to open up that conversation but I'm just letting you know that it's on the cards. For now, just know that there's a (very neglected) "Trongate" channel on YouTube.

The Trongate channel only has about 600 subs but it's not (I repeat NOT) blacklisted by YouTube. So, unlike my personal channel – which loses subs every day – the Trongate channel acquires subs any time you put something out. I'd really like to delete all of the videos that are currently on the Trongate YouTube channel and then relaunch it using the same sort of format as "Free Code Camp".

So, that means different guests coming on every week educating the rest of us. The more people who come on board, the better.

Please do consider coming on board for that idea. It would be really healthy for the framework and it'll make you completely rich and famous, with beautiful women throwing themselves at you (one or more of those claims is, as yet, unverified).

Same goes for Dan, Sasin and all the others. My YouTube channel may be dead because I've spent too much time offending people and swearing like a drunken sailor. The Trongate channel is different and it's going to be a winner. So, please DO think about coming on board for that. We need you!

QUESTION

I think I can go through the comments that have been left and address each of the things, one by one.

That's cool. It's doable.

But I'm going to push my luck.

We have the validacious app on GitHub at:

https://github.com/trongate/validacious

Would it be possible for us to get into a habit of rocking pull requests and things of that nature? It
would save me a boatload of time and it would eliminate the chances of me making a stupid mistake?

DC

Hey DC,

PR created. That should streamline things and remove any risk of things going sideways.

I’ve taken down the SASIN post for now. I wasn’t completely satisfied with my implementation and would prefer Jonas take the lead on that. I still have the code and may revisit it if needed. It has strong potential as a feature, provided it comes with zero impact on core performance.

Regarding the Trongate YouTube channel, I’d strongly recommend archiving rather than deleting the existing content. It’s high-quality material and still valuable as a reference, especially for those working with v1.

On the content side, I appreciate the invite. At this stage, I’m better suited to contributing through code, testing, and written input rather than producing video content. Time is a factor, and content creation isn’t really my strength. That said, I’m always happy to support behind the scenes where I can add the most value.

Cheers,
Si