Gateway Extension Building Process

The process of building Gateway extensions is still being constantly refined. We are still asking the same question that drove us to build Gateway in the first place. How can we automate all these stupid annoying and time consuming steps in order to turn concepts into working applications faster?

The building blocks of applications (which is the term we use to broadly refer to functionality and features that you build with Gateway) revolves around the collection. The collection is an extension of the Eloquent model, and comes with the full capabilities of Eloquent models including the very powerful relationship management.

Anything we want to build that is actually useful will typically require not one or two collections, but instead 3 or 5 or 10 or 20. Why? Because that’s the reality of application development. Every tutorial always centers around one data model like a task in a todo list. Maybe they add categorization or some other related model. It’s still unrealistic. Applications, even simple apps, are trees of interconnected data models. That’s why it’s so important first to have a solid data model, and secondly to have robust relationship management between models.

Take for instance building a portfolio. If this was a typical WordPress tutorial designed to introduce basic concepts we’d probably say make a “portfolio” custom post type. Then register a custom taxonomy and relate it to our portfolio. Is this realistic? Not really. The structure we actually want is likely to look more like this:

• Portfolio a type of portfolio (such as design, development) that groups projects, aka portfolio items.
• PortfolioItem a single project or other form of item you want to showcase in the portfolio.
• PortfolioItemCategory a category tree that relates to the PortfolioItem records.

How do you create a system that is paradoxically, quite robust and inherently complex, yet use building blocks are techniques that are simple and easy to understand? That’s why collections work. A collection can be as short and simple as:

<?php 

namespace PortfolioPlugin\Collections;

class Portfolio extends \Gateway\Collection {

}

That’s not a skeleton or pseudo-code, the mere act of extending collection creates a collection, and it is function because conventional asset names are inferred. This collection will expect a database table named wp_portfolio will be available for it with an id and timestamp columns. And the existence of this collection will trigger Gateway to make that migration code available, running dbDelta() with a table create SQL statement. The good news is this process is consistent, has been tested heavily and just plain works. You typically won’t need to worry about the mechanics under the hood. Just focus on providing the configuration you need, which will be predominantly the creation of fields and relationships between collections.

In short the process is:

• Make a collection
• Make another collection
• Relate collection A to collection B
• Create and edit fields to store the right data
• Create testing records
• Make more collections.
• Relate the collections to each other.
• Make fields.
• Make collections.
• Make fields.
• Make relationships.
• Make fields.