Developing Front-to-Back

Developing Front-to-Back is a strategy that we like to use on existing codebases (and sometimes new ones), where we start at the most visible and immediate to the user - the design, then proceed to front-end development, and then eventually do back-end development last.

What this does is allows Design and Front-end Development to set the data structure that they prefer when building the front-end, ensuring that data's cleanly formatted.

Building the Front End

The front-end can be delivered in a fully completed state, meaning that all markup, CSS and JS are 100% finalized and ready for launch.

Whenever we want to get information from the CMS/Backend of the application, we "stub" that content in, or make static, pre-formatted information come from the controller, with the intention of having another developer properly hook up the backend logic later.

Adding Stubbed Data to the Controller

Examples of Stubbed Data:

Starting Backend Development

Once we receive a finished front-end, the job of the backend developer is then to find the stubbed content, and replace the static values with dynamic information coming from the back-end or CMS.

In this video, we briefly cover the responsibilities of the front and back-end developers, and explores "stubbed" content.
Creating a Post Object
In this video, we follow the browser request through from the browser URL ,through the router to the Controller, and Model. Because we're in WordPress, we want an associated CMS object for this controller, so we make one of those as well.
Creating and Identifying Existing Fieldsets
In this video, we talk about how ACF Custom Field sets work, adding fields to the WordPress Post Object, and identify existing fields we could use to do the work we need to do.
Getting Data from the CMS to the Controller
In this video, we talk about how we append data to the model, and how to access model data from the controller. This allows us to follow the path of info from the CMS fields on the post object all the way to the view, where it's rendered for the user.
Setting up your fields for ease of access
In this video, we add fields to our fieldset and talk about how to properly set those fields up for ease of access when connecting information from the fieldset to the model.
Leveraging Existing Functionality
In this video, we work on a slightly more complicated set of information required by our controller. Because we're working on an existing project with lots of functionality, we don't need to rebuild everything from scratch, we can use existing stuff.
Refactoring Functionality into Content Layers
In this video, we move some functionality that's currently unique to our controller, and create a re-usable content layer than can be used anywhere on the site. There's a bit that goes into this layer, including mapping data to a custom ACF Field, but some of that is truncated to not get distracted.
Finishing the Controller

We follow the examples above to replace all of the stubbed content with real, dynamic content. Once that's done, our job is complete, and the app should be pretty much ready for QA.