Ahoy!,
One of the things that happens when you build a PHP framework is you get ignored. Then, you get ignored some more. Then, you continue to get ignored. Then, after you get ignored ...if you're really lucky, you start to get a few people using the framework. Then, if you're outrageously lucky, you get suggestions for new features and improvements. Some of the suggestions are good. They're always from well-intentioned developers. Occasionally, however, they are from developers whose approach amounts to, "Trongate is good, but I cannot use it and it will never succeed unless you build the things I'm asking for." This type of approach is rare. However, when it happens, it is tantamount to bullying. I can assure you, you would be astonished when you see how angry and entitled some people can become when you say 'no'. Today, I'd like to take a moment to recognize some of the perfectly good ideas that I'm saying 'no' to.
Support For SQLite, PostgreSQL And Other Databases
Trongate has been built for MySQL and MariaDB. The Trongate Model class, which is responsible for database interaction, uses PDO for simplicity and security. PDO is a free extension that comes with most modern PHP installations. When I made the decision to run with a PDO-based solution (instead of building an outrageously complicated ORM), it was because PDO can work with a large variety of databases, including some slightly obscure ones. Go check out the list for yourself. As you can imagine, that's all welcome news.
Personally speaking, I haven't used lots and lots of different databases. So, I'm in no position to offer expert advice on matters to do with slightly more exotic databases. However, I'm delighted by the news that some Trongate developers have managed to get Trongate working with SQLite, along with one or two of the other alternative databases. How they did it and what this all means is a bit of a mystery to me. However, it's great news and three cheers to anybody who has taken the time to figure these things out.
Unfortunately, the prospects of anyone investing massive amounts of time into making Trongate "multi-db friendly" (whatever that means!) are slim.
If a pull request came in tonight that promised "this one makes Trongate work with 'x'," the pull request would probably be declined. At least... it would be at first. That's because in order to accept something of that nature, there would have to be a genuine need for the feature along with a deep understanding of how the (let's say) interesting database works. On the first point, we're struggling to see a need. On the second point, I just haven't got time to learn about exotic databases, and I am pretty sure the same can be said for the others who are heavily involved with the framework. Making Trongate work with 'x' is not a bad idea. It's a good idea. Sadly, it's just an idea that requires too much time investment and too many unknowns. By the way, nobody has submitted a pull request that makes Trongate work with an exotic database. The person who made this request simply asked me to add it. Initially, I asked if we could meet on Skype. My hope was that he'd be able to teach me a little more about his exciting database of choice and how it all works. That particular person was too busy, and - come to think of it - so am I.
Radio Buttons And Checkboxes For The Desktop App
Another one that came in recently (from the same person) was a request for radio buttons and checkboxes for the Desktop App. This is a slightly strange request because the Desktop App already generates checkboxes when you choose a form field type of 'boolean' with the code generator. I don't think it automatically generates radio buttons. However, the framework does have the form_radio() function to assist with that.
Now, before we get dragged into a conversation along the lines of, "Oh, but it needs to do x, y, and z...", let's pump the brakes for a moment.
The code generator that we have for Trongate is nice. Building it took a long time, and I'm happy with how it turned out. As a matter of fact, I think it's the most beautiful code generator that I've ever seen. Of course, I would say that since I'm the guy who built it. Nevertheless, I'm grateful that people are taking an interest in the code generator.
Unfortunately, I can exclusively reveal that there are no plans to add any significant new functionality to the Trongate Desktop App. If you're waiting for it to get 'such and such,' then - I regret to say - you may be disappointed.
What I've discovered recently is that when you delve into Trongate, there comes a moment when you stop using the Desktop App. Other developers whom I talk with during my daily live streams are at this point. As for me? I've only recently reached this point. It may sound a little bit arrogant, but I dare say one of the hallmarks of a Trongate expert is that they hardly ever use the code generator. Far from adding new features, I find myself moving away from it as of late.
There is one huge upgrade that will be happening soon that's to do with the Desktop App. Soon, we'll be building it into the actual framework. When that happens, you'll be able to enjoy the full Desktop App experience but without actually downloading or using the Desktop App. This is going to be a huge upgrade, but it's one that I'm super excited about.
You Have To Choose
I'm sure I could add a few thousand more words to this article and make it even more depressing by discussing more of the fabulous things that we're not able to do. However, I think it might be more valuable if I just give you an explanation of the reason why things are the way they are.
Framework makers have to choose. Every time you say 'yes' to a new feature, you're taking on board more bloat. The reason why Trongate is the fastest PHP framework (prove me wrong) is because we've said 'no' to lots and lots of really great ideas. That has to be the default policy moving forward, or else we're basically just rebuilding Laravel. I don't want to build a Laravel clone. Laravel is already doing a fantastic job of being Laravel. Trongate is different. Originally, I had planned on making it a micro-framework. The fact that we have accumulated a large catalogue of intellectual assets is something of a miracle. The API Manager, Trongate Pages, the Desktop App, the Module Market, the Graphical Query Builder, the CSS Library, the date-pickers, the time pickers, the automatic updating mechanism and (last night!) the launch of our new discussion forum. These are just some examples of the things we've created out of thin air.
The real issue - however - is the fact that keeping everything working is a HUGE job. Actually, it's literally a full-time job, and I cannot begin to express how difficult it is. Right now, for example, the Trongate website (this website) is a mess. It's a complete mess! There are faults all over this website and even right here on the news section. To me, that's embarrassing, and I'm the one who is to blame. I'm responsible.
Yes, the framework is good, but the website (this website!) is indeed an embarrassing mess. Even more pressing is the issue with our documentation. The documentation that we currently have - for Trongate - is not fit for purpose. The good news is, we're about halfway through writing new and beautiful documentation. Unfortunately, however, these things take massive amounts of time, and that is the real challenge.
The good news is, the framework itself is in beautiful condition. I think the framework has to be the first priority, and I'm delighted with the current state of the framework. It's a shame that our website, the documentation, the Learning Zone, the Module Market, and some other bits and pieces are not yet perfect. It's my life's goal to make all of these things perfect soon. Just to give you an idea of the scale of the task that is in front of us, the goal is to have the Trongate ecosystem perfect by November this year.
Just to state the obvious, if I jump off of the train and start faffing about with Postgres, it would be valuable time taken away from writing the documentation or rebuilding this website. It's a shame that we have to choose, and it's a shame that some of the decisions being made are kind of boring. However, we simply must get these fundamentals (docs, the website, etc.) perfect before we can start looking at more esoteric upgrades. Anything that deviates from this policy would be downright irresponsible.
Therefore, please do not take it personally if you have an idea for Trongate and - eventually - you get told 'no'. The problem is not necessarily that your idea is bad. The biggest challenge - as always - is time. If Team Trongate (meaning everyone who looks after the framework) are put in a position where we have to choose between doing something boring (like finishing the docs) and doing something exciting (like adding a fancy new feature to the Desktop App), we choose the boring option every time. We have a burden of responsibility and we take our responsibilities seriously.
Finally, please never tell me that you're thinking about using Trongate but that you can't unless I accommodate your wish list. That kind of behavior is entitled and unreasonable. I've been at the receiving end of that kind of manipulative behavior recently from someone who describes himself as an ex-Laravel developer. In the past, I would have responded to his angry demands with ridicule. However, I'm not going to do that, nor am I going to name him.
This is the Age Of Integrity. I've changed. Trongate has changed. Those of us who belong to Team Trongate have a responsibility to conduct ourselves in a responsible and graceful manner. We accept the challenge.
DC
