Over the past three weeks, some of us have been in the process of completely re-writing the documentation for the Trongate framework. It has turned out to be a huge job but an extremely interesting one.
Trongate may never be finished. There will always be opportunities for the framework to grow and improve. That's a good thing. Nevertheless, I think that Trongate has now reached a sort of 'settled' state. The underlying architecture and the main feature sets of the framework are in good shape. In short, I'm happy. I hope others are too.
Now, at this interesting time, I find myself looking back at all of the assets that have been built for Trongate, over the last four years or so. Trongate has tonnes of features - many of which are industry firsts. Don't believe that? Okay, go ahead and show me any framework of any language that has a graphical query builder for easily generating SQL queries. I'm guessing you won't find one. The fact is, Trongate is feature-packed. We have everything from code generators to our own JavaScript libraries.
For a long time, I felt as though Trongate's greatest assets were either the API manager or the code generator. A great deal of effort went into these things and I'm happy with how they turned out. Now, as I look back upon what we've created, one feature suddenly - and rather surprisingly - shines above all else like a glowing beacon. That feature is Trongate Pages.
Trongate Pages is the content management system that comes pre-installed with the Trongate framework. It has a WYSIWYG facility. It's outrageously fast. It's super easy to use. Best of all, it uses no third-party libraries at all. Personally speaking, I had always fancied the idea of building a good content management system. Something that could be compared against offerings from the likes of WordPress, Drupal, and others. My expectation was that I'd build this a few years into the future. I had no plans of throwing my hat into the CMS ring. Nevertheless, it became clear to me about a year ago that Trongate deserved to have a good content management system of its own. So, Trongate Pages was rushed out. From memory, it took about a month to build and it required a boat-load of JavaScript. I do not consider Trongate Pages to be a work of perfection. Nevertheless, as I look back upon everything we've made, I think Trongate Pages - that simple little rush job of a CMS - might just be Trongate's best feature!
At the time of writing, Trongate Pages is a sort of hidden feature. Even for experienced developers, it's not immediately clear how Trongate Pages fits into the bigger picture. For one thing, the pages that get generated (at the time of writing) have strange URLs that all contain the string 'trongate-pages/display'. Furthermore, the default homepage is (again, at the time of writing) completely disconnected with Trongate Pages. In other words, it's just a sort of random module. An afterthought.
All of this is going to change. One change that you'll notice is that Trongate Pages is going to be taking front and center stage for the Trongate framework. For example, instead of having a default homepage that displays hard-coded content from a view file - the default Trongate homepage (that comes with each installation) will display dynamic content that has been generated from Trongate Pages. You're also going to have nice URLs being generated by default. So, if you build an 'about' page, the URL for your new page will be your base URL followed by 'about'. There's more. As things stand, if you build a page with Trongate Pages and your new page results in the creation of a URL string that conflicts with an existing URL string, a random alphanumeric string gets concatenated on the new URL string. That's also going to be improved. Now, we can have Trongate Pages generate beautiful search engine-friendly URLs in cases where there are potential conflicting URL strings. In practical terms, this means that, instead of having a URL path of, 'trongate-pages/display/about2345dfdsere3' - you will now have a URL path that is more of the form '/about-information'.
The changes that I've described above have already been written. These improvements are due to be uploaded within the next seven days.
But this is just the beginning.
It's easy for me to visualize a massive number of exciting improvements that could be made to Trongate Pages. In short, I think we have a really good blank canvas upon which to build lots of cool stuff.
It's Not All Sunshine And Smiles
As indicated above, Trongate Pages - in its current form - was a bit of a rush job. When it was written, I had no plans of making it take center stage nor any plans of making it an open-source asset that people might wish to build upon and upgrade. The goal, at the time, was to provide something that could be used for building simple text-based pages and nothing more. From memory, I think I wrote about three or four thousand lines of JavaScript to make Trongate Pages work. None of that JavaScript will be pleasant to look at or easy to work with. So, I think there's a good chance that there may be a rebuilding of the inner workings of Trongate Pages in the future. If that happens, the main goal would be to give developers a motivation to get involved. I'd like developers to be able to look at the code, understand it, and change it. That would certainly be exciting. The trouble is, JavaScript can sometimes be a bit of a rat's nest to read. For Trongate Pages to reach its full potential, I think we'd need to unleash our greatest asset of all. The community. In order to get developers interested in Trongate Pages and motivated to participate in improving it, I think we'd be well advised to ditch the rat's nest of JavaScript and replace it with something that is capable of using and presenting simple HTML. My visualization is something similar to HTMX. That type of system, if it was ever to be made, is something that could be easily understood by 90% of developers. If we had this, the upshot is, we'd have a super cool CMS that was really easy to customize, down to the last pixel.
Another downside of Trongate Pages is that - by putting it front and center stage - we'd be tethering the Trongate framework to the MySQL/MariaDB database combo. If you're going to assume the role of framework purist then having a framework strongly tethered to a particular database is never ideal. Having given this some thought, I think there are several valid counter-arguments - the strongest of which might be the argument that Trongate is losing no functionality whatsoever. In other words, you'll still be able to use Trongate with any database system you like or even no database. All we'd be doing is making a choice about how Trongate is going to work out of the box and by default. It's the same choice that was made by the people who made some of the most popular content management systems in the world. So, why not us?
What's Coming Up?
At the time of writing, Trongate Pages is going through some last-minute tweaks. Very soon, however, we'll be making Trongate Pages the module that provides the content that goes on every default Trongate framework homepage. As always, Trongate will continue to be a stability-first framework. We remain committed to continuous improvement but without breaking your pre-existing code.
Thank you to those of you who have stood by Trongate. Exciting times are ahead.
DC
