Trongate Framework Documentation

trOnGAtE

Welcome
- Table of Contents
- Welcome To The Revolution
- Trongate's Free Forever Promise
- About These Docs
Getting Started
- A Word About MariaDB And MySQL
- Installing PHP and MySQL
- Let's Get Trongate!
Basics Concepts
- A Few Words About Coding Style
- The Structure of a Trongate Web App
- Introducing Modular HAVC
- The Problem With MVC
- Isn't this the same as HMVC?
- What's Inside A Module?
Understanding Routing
- What Is Routing?
- 404 Error Pages
- How Basic URL Routing Works
- Reading Values From The URL
- Preventing Methods From Being Invoked Via The URL
- Advanced Custom Routing
Controllers
- What Is A Controller?
- The Structure Of A Controller
- Defining A Default Controller
Views
- Understanding View Files
- An Example Of A View File Being Used
- Passing Data Into View Files
- Returning Views Output As A Variable
- Best Practices
The File Asset Manager
- Why We Need A File Asset Manager
- Basic Example - Part 1
- Basic Example - Part 2
- The Module Assets Trigger
- Additional Information
Modules Calling Modules
- Calling Another Module From A Controller
- Calling Another Module From A View
Super Modules & Sub Modules
- Complete Video Tutorial
- What Are Super Modules And Sub Modules?
- Accessing Sub Modules Via The URL
- Loading View Files From Within Sub Modules
- Accessing Sub Modules From Other Modules
Templates
- What Are Templates?
- How To Create Your Own Website Template
- Loading Templates
- Passing Information Into Templates
- Passing View Files Into Templates
- Template Partials
- About The Admin Template
Trongate CSS
- Introducing Trongate CSS
- Features and Benefits
- Trongate CSS Examples
- JavaScript Components
- Trongate CSS Video Tutorial
- Working With YouTube Videos
Helpers Explained
- Helpers Introduction
- The URL Helper
- The Form Helper
- The Form Validation Helper
- The Flashdata Helper
- The File Validation Helper
- The Pagination Helper
- Other Helpful Features
Form Handling
- Trongate's Approach To Form Handling
- Getting Started With Form Building
- Creating A Books Database Table
- Manually Building A Form
- Improving Our Form
- Form Validation (The Pipe Method)
- Form Validation (The Array Method)
- Displaying Form Validation Errors
- A Closer Look At The Post Method
- Repopulating Forms
- Creating Records
- Reading Records
- Table Joins
- Updating Records
- Deleting Records
- Custom Validation Callbacks
- CSRF Protection
Database Interaction
- How Trongate Works With Databases
- Getting Started
- How To Use Debug Mode
- The 'Get' Method
- The 'Get Where' Method
- The 'Get Where Custom' Method
- The 'Get One Where' Method
- The 'Get Many Where' Method
- The 'Count' Method
- The 'Count Where' Method
- The 'Count Rows' Method
- The 'Get Max' Method
- The 'Insert' Method
- The 'Update' Method
- The 'Delete' Method
- The 'Query' Method
- The 'Query Bind' Method
- The 'Insert Batch' Method
- Graphical Query Builder Video Tutorial
Uploading Files
- A General Overview Of File Uploading
- Building An Uploader Form
- Understanding The Upload Process
- Uploading Pictures
Working With Images
- How To Build Picture Uploaders - Video Demo
- Understanding Single Picture Uploaders
- The Submit Upload Method
- A Closer Look At Picture Settings
- The Drag 'n' Drop Multi File Uploader
- Controlling How Multi-File Uploaders Behave
The Module Import Wizard
- What Problem Does This Solve?
- How To Use The Module Import Wizard
Authorization and Authentication
- Section Introduction
- What We Are Trying To Achieve
- How Trongate's Token System Works
- The Three Security Tables
- Generating Tokens (JavaScript Friendly Version)
- Generating Tokens (PHP Friendly Version)
- Fetching User Data From Tokens (JavaScript friendly version)
- Fetching User Data From Tokens (PHP Friendly Version)
- More Useful Features
- Destroying Tokens (JavaScript Friendly Version)
- Destroying Tokens (PHP Friendly Version)
- Understanding HTTP Response Status Codes
The API Explorer
- An Introduction To The Trongate API Explorer
- API Terminology Explained
- Trongate's Built-In Endpoints
- Getting Started With The API Explorer
- Building Your Api Settings File
- Testing Your API Endpoints
- Optional Additional Parameters
- Before Hooks And After Hooks - General Overview
- Before Hooks - Deep Dive
- After Hooks - Deep Dive
- Querying Endpoints
- Understanding API Authorization
- How To Attach Tokens To Requests
- Wide Open Authorization
- Role Based Authorization
- ID Based Authorization
- User ID Segment Authorization
- User Code Segment Authorization
- User Owned Segment Authorization
- Custom API Endpoints
Before You Launch
- Hiding Your Admin Login URL
- Pre Launch Checklist
- Web Hosting Advice

switch to dark mode

Isn't this the same as HMVC?

For some of you, HAVC may all sound a little familiar. There's a well known design pattern by the name of HMVC that has been getting used in the PHP community by a significant subsection of developers.

Whilst HMVC is similar HAVC, they are not the same. For instance:

HMVC does not offer developers a truly modular app structure
HMVC apps are prone to code repetition - particularly within model files
HMVC (in its strict form) does not allow modules to be called from view files

Let's imagine that you're building a discussion forum for a web app. Let's further imagine that your discussion forum contains CSS code, JavaScript and even an assortment of icons (in the form of images) to make your pages more interactive and attractive.

HMVC leaves developers in the dark when it comes answering to the question:

'Where exactly are we going to store all of the assets that our discussion forum needs?'

Enter HAVC!

Do you see that little 'A' inside HAVC? Until now, we've been saying that it's for storing 'assets'. That's true and it is. However, for clarity, you can think of the 'A' as being a folder for storing anything.

This means that you now have a folder within each of your modules for storing anything you like. This includes; JavaScript files, images, audio files, CSS files, movies and much more!

Top Tip

From time to time you may find yourself wondering where a particular asset should be stored. For example, let's say you're building a shopping cart and a part of the shopping cart contains an image of some credit card logos. There's a perfectly valid case for storing those kinds of images within your 'shopping cart' module. However, some developers might prefer to store all of their images in the 'public' folder - perhaps inside an 'images' directory. When you're using Trongate, the best answer to all of those kinds of questions is, "use the solution that feels good for you".

As for the 'model'? Trongate has a model.php file. However, it's stored within the 'engine' folder.

And finally...

HAVC has one more trick up its sleeve that you will not find in HMVC.

Modules within HAVC applications can contain... wait for it... other modules!

This means that for the first time, it's possible to have very advanced features (such as an entire online shop, for example) contained within literally one folder. Those advanced features can then, quite literally, be copied and pasted from one app to another. No 'vendor/autoload'. No Composer dot phar. No Packagist.

For the first time, the PHP community has a framework that makes drag and drop web development a reality!

â€‹

Just To Let You Know

If any of this seems confusing or if any of this has got you asking lots of questions about site structure... relax! The key takeaway is that Trongate has a very flexible structure that is very easy to work with. Even though lots of incredible things are possible with Trongate, that does not mean that you have to do them. With Trongate, there's not really a 'right' and 'wrong' way to structure an app. Instead, you get a general "framework" and you get to decide how you'd like to build your apps

â€‹

HELP & SUPPORT

If you have a question or a comment relating to anything you've see here, please goto the Help Bar.