Thanks for the heads-up DC! I'm happy to shift toward creating pull requests to help streamline things. I'm also honored to be invited to create videos for the Trongate channel. I haven't really created tutorial videos before but I'd love to get involved. Please let me know the best way to get started!

Thank you, one and all, for the positive responses. I'm very grateful.

At the moment, I'm not in front of my working computer. So, I'm not able to do any kind of serious coding shenanigans.

Rest assured, any and all pull requests are gratefully received. It's a huge time saver and I'll be delighted to pull them in as soon as I'm back at my desk (tomorrow at the latest).

Regarding the YouTube channel, I'm very excited about that and have created a separate post. I have a funny feeling about that one. I really think it could do well.

Anyway, I'll come back and confirm when I have had a chance to pull in the various changes.

Many thanks!

Oh, and Simon - you and I should enjoy a good old laugh about this. You'll know by now that I'm completely rubbish at forums. I can barely last two minutes without saying something stupid and offending somebody. It always happens. It's why I keep banning myself! To be honest, I don't enjoy forums. To me, this is no fun at all.

So, I'm at peace with the thought that forums aren't my thing. If you happen to be the other way around from me and you're not really up for the YouTube thing then that's obviously super cool. We're just glad to have you around.

Following Simon’s recommendation, I have created a PR on the validacious repository including an illustration of Modules::run gotcha

Im creating a site currently in v2, and doing a menu items module, I have an admin form to add and update the db data for the module table. I can give it a real world test if you're still looking.

Kind regards

Keith

Hi folks,

Apologies for disappearing for a few days. It has been an outrageously busy time. However, I have now had a chance to think about some of this and I would like to offer some feedback. This is going to be a somewhat lengthy essay. I apologise for that but I think the things we're talking about are important. You'll agree, I'm sure, that we should make decisions pertaining to the framework based on a sober assessment of all the technical information available and how any proposals fit in with the overall direction of the framework.

Anyway, thanks for the pull requests and all the help. The pull requests that do not pertain to "Sasin's Tweak" should all be fine.

THE LATEST NEWS

I have given Balazs access to the Trongate YouTube channel and he is going to be uploading some content for us soon. I am very excited about that. Once he has done that, I will put an announcement out on my own channel and, hopefully, I will also be able to formally declare that the validation module is ready. I think we might be looking at a timeframe of about one week or so. I will also be formally declaring our leaderboard winner, which is long overdue, and awarding the spectacular prize. Happy vibes all round and community ahoy!

SASIN'S TWEAK - IT'S COMPLICATED

I am going to talk at length about Sasin's Tweak because I have been thinking about this a lot. In fact, I even recorded two (private!) videos for you discussing it, but decided not to upload them.

What we are about to discuss has huge implications for the framework and is also highly technical. We cannot afford the luxury of being offended here. Sasin's genius status is confirmed, and we are obviously very glad to have him here. We're very grateful for his pull request. With that said, I would like to focus purely on the technical aspects and do so without fear of offending anyone.

Broadly speaking, I think there should be three major considerations when it comes to pull requests:

1). Will this create a breaking change?
2). Will this slow down the framework?
3). Will this introduce more than one way of doing something?

If the answer to any of these questions is "yes", then, with very rare exceptions, I think the pull request should be rejected.

The first two items are self explanatory. The third is absolutely mission critical. One of the main goals of the framework is to be the world's most AI friendly framework. By "AI friendly", I mean you going to the beach and relaxing while your computer automatically builds Trongate apps for you. It is a huge ambition and it might never happen. Nevertheless, I would like us to behave as if we are building something that AI systems will love. I cannot stress enough how important this is.

I should also say that the transition from Trongate v1 to v2 has not been a bed of roses. There are still some AI tools using $this->model to query the database instead of $this->db. Very recently, some popular AI tools have started to recognise the differences between v1 and v2, but it takes time. Interestingly, the essay pages seem to play an important role in "training" of popular AI tools like Gemini.

Forgive my rambling. The point is that I do not want to do anything that will make things more confusing for those AI tools. If we introduce a second way of doing the same thing, I worry that it will become Hallucination City USA.

If we apply the three key considerations to Sasin's Tweak, I think it looks like this:

1). Will it create a breaking change?
* No.

2). Will it slow the framework down?
* Possibly, but we are not yet certain.

3). Will it introduce two ways of doing the same thing?
* Yes.

MORE CONCERNS

There are a few additional concerns worth highlighting.

From an MVC best practice perspective, view files in PHP should remain simple. Typically, they contain variables, basic control structures such as loops, and presentation logic. That is a well established convention.

Trongate already stretches convention by allowing modules to be called from view files, which many HMVC implementations would not encourage. It also allows modules to be entirely self contained, including the storing of assets within modules, which is uncommon in many PHP frameworks. The point is that we are already pushing boundaries. With Sasin's Tweak, we push them even further by making view files more complex. The idea of a view file being tightly coupled to a class structure does not sit well with me.

So, while Sasin's Tweak is technically impressive, I believe it encourages poor practices.

CONCLUSION (FOR NOW)

Taking everything into account, I think Sasin's Tweak fails on the third test.

Trongate already has:



While Sasin's Tweak may offer a more object oriented interface for invoking functionality, it ultimately introduces an alternative way of achieving something that is already possible via Modules::run().

So, it is a fail and the pull request should be rejected.

Decision made.

Conversation finished.

Right?

Well, maybe not quite, and this is where it becomes more interesting.

BUT WAIT!

Even though I do not think Sasin's Tweak should be merged as it stands, I wonder if it contains hidden genius. Indeed, it might open the door to one of the most significant architectural upgrades in the history of PHP frameworks.

Allow me to explain.

Frameworks like CodeIgniter provide both classes and helpers. A helper is typically a collection of procedural functions that can be made available without instantiating a class, usually by loading or autoloading the helper. For example:



A class, on the other hand, is a more structured construct that requires explicit loading and method calls. Whether functionality is implemented as a helper or a class is a design decision made by the framework maker.

Take fetching posted values as an example. In CodeIgniter 3, this is handled via an Input class:



In Trongate, we made the same functionality available as a simple helper function:



As you can see, Trongate's syntax is simpler and requires fewer characters. In addition, with Trongate, you don't have to actively load helpers. Everything just works. Frankly, it's a better framework.

"EVERYTHING IS A MODULE" (SORT OF)

Trongate v2 moves strongly towards the idea that everything is a module. As a result, many components were moved from the "engine" directory into "modules", including pagination, templates, and validation. The result is an engine directory with significantly less code.

However, we did not go all in. There are still many helper functions within the engine directory. This represents a considerable amount of logic sitting outside the modular system.

The hidden genius of Sasin's Tweak is that it opens up the possibility of moving those helper functions out of "tg_helpers" and into "modules". Imagine a module called "form" that contains functions like form_open().

In that scenario, the engine directory could become extremely small, perhaps even under 500 lines of code. From an AI perspective, this would be hugely beneficial. It would also allow Trongate v2 to more fully realise the idea that everything is a module.

I hope can now see why Sasin's Tweak is potentially huge ...and in a positive way!

THE TRICKY PART

To be clear, I do not want people writing code like this in view files:



I believe that would be poor practice. If I ever see a developer writing that in a view file then I wouldn't want to work with them. I certainly wouldn't hire them! I'm aware that I may have expressed a desire to have that kind of syntax, previously, but that was a poorly-thought out, throw-away comment. Frankly, I was wrong.

Instead, I want developers to continue writing:



However, I would like a way to map those functions to individual modules without introducing breaking changes or unnecessary performance overhead.

If we can achieve that, then Sasin's Tweak goes from being a rejection to potentially becoming the gateway to one of the best updates we have ever made.

This concludes my thoughts on Sasin's Tweak. I know this was a lot to read but it means a great deal to me and I appreicate you giving this your time and energy.

Please let me know your thoughts below.

DC

PS - Kivision, what you're doing sounds great. However, I think you should wait until the new validation module is formally released. It won't be long! Hail to you!

good point about adding more APIs for the same thing, I completely understand if it gets rejected.

As for follow-up changes from adding it, moving helpers to module classes and invoking via Modules::run(…) in the helper could work but would add a tiny bit of runtime overhead — likely nothing of real impact. The real cost would be in inodes (no. Open files). But with OPCache that’s likely of very little concern and still completely dwarfed by most frameworks the moment a autoloader like Composer is introduced.

As for cost of creating two closures (bindTo clones the closure with new scope), we’re talking maybe 2 microseconds but likely nanoseconds as most don’t repeatedly call [code=“php”]Trongate::view(…)[/code] — I doubt anything materializes on benchmarks.

In any event, please do let me know if there’s anything I can help out with.
— on topic of joining video, at the moment I don’t have a camera and only a scuffed microphone.

Thank you. In that case, it's probably a non-starter.

I looked into this and - unless I'm mistaken - there's no way to reassign functions using native (pure) PHP. The following is the best I can think of but it's far from perfect...

Well well well.... maybe I'm a genius too!

I explained this whole thing to Gemini and asked for an in depth analysis with a conclusion that takes a balanced view - based on all the pros and cons.

I'll paste in what Gemini said but I draw your attention to two things:

1). Google Gemini estimates a 90% reduction of helper file sizes.
2). Google Gemini also estimates that this change could make the framework even faster - potentially by up to 5%!

Have a look and do tell me what you think:

It’s an interesting theory, delegate pattern = less to parse into an AST = less lexical load. I hadn’t thought that may have much effect as PHP compiles into opcodes in OPCache once.

If nothing else, smaller helper files = easier to read and helper module classes may be easier to glance over in directory tree

Keep me posted, piqued my curiosity

Thank you. I do think it's a winner.

Let's do the validation thing first. After the validation thing has been nailed then perhaps we can turn our attention to this new thing.

Here's an article I've just put up that discusses this (with more than a little help from Gemini and Chat GPT!):

https://trongate.io/essays/how-to-make-the-fastest-php-framework-even-faster