As you are developing your Reusable Mindset, I want you to think about implementation and business logic. More specifically, think about how to separate a specific implementation from the business logic. This design pattern makes your code reusable. For example, in our project, we have 2 custom meta boxes. Yet, both are using the same code. Imagine pulling the implementation out of the code and abstracting it into a configuration file. Now imagine that our business logic is rebuilt to accept a configuration file and then it processes it. Why? In doing so, our business logic is built once. It […]
Labs
Labs are hands-on coding projects that you build along with Tonya as she explains the code, concepts, and thought processes behind it. You can use the labs to further your code knowledge or to use right in your projects. Each lab ties into the Docx to ensure you have the information you need.
Each lab is designed to further your understanding and mastery of code. You learn more about how to think about its construction, quality, maintainability, programmatic and logical thought, and problem-solving. While you may be building a specific thing, Tonya presents the why of it to make it adaptable far beyond that specific implementation, thereby giving you the means to make it your own, in any context.
Improving the Render
Let’s improve the render function, as we have too much going on in that function. We’ll abstract away the task of fetching the metadata from the database for our custom fields’ values. Why? Our render function’s job is to render the view. It needs the values, but does not need to know how to do it. Rather, just gimme the values for the custom fields. We’ll also add a WordPress filter event to extend our meta data, allowing an external process to filter the values, do some processing, or just run before we render out to the browser.
Rethink the Save Functionality
Our current save function is not reusable. As we’ve done with the register and render functions, we need to remove the implementation and allow the saving process to accept a configuration and then process it. Let’s rethink our save function, split up the different parts, and prepare for how to refactor it.
Merging Configuration with the Defaults
If we run our code as it is right now, the meta boxes did not appear. Why? Because we only configured what was different in the Portfolio and Subtitle configuration models. We need to merge each of those with the default configuration parameters. Let’s do that in this episode. You’ll be using the PHP function array_replace_recursive to merge all levels within our multidimensional arrays. When you get done with this episode, both custom meta boxes will now render for a post. WooHoo!! Pat yourself on the back, as you did a lot of work to get to this point. Keep […]
Wire Meta Box to the ConfigStore
Let’s wire up our meta box and module to load the configurations and then go fetch what we need. We’re getting closer to having a working reusable metadata module for multiple meta boxes.
Architect the ConfigStore – Part 1
Let’s architect our configuration store. We’ll start with identifying what it’s purpose is and why it exists. We’ll look at it from a reusable mindset to ensure that it can accept any configuration, as long as it follows our defined structure. In Part 2, we’ll walk through developing the structure of our API in procedural format. The intent of our store is: Load a configuration file from the filesystem one time only. Load the configuration into our store (container) – one time only. Retain the configuration in the store such that it’s available in the app to get parameters throughout […]
Configuration Model – Add Parameters
Let’s start mapping out our default configuration model. We’ll start with the add/register meta box function.
Plan It Out
Before we build anything, let’s sit down and plan out what we are going to build. We’ll take a high level, big picture view of we are trying to accomplish and then map out the buildable blocks.
The Reusable Mindset
Let’s talk about code reusability and the reusable mindset. The first step is to identify repeating code patterns where you can separate the implementation from the code. The next step is abstract the code, building it in such a way that it can accept an input(s) to pass in or configure the implementation. Then this black box code that you’ve abstracted handles everything for you based upon the input you provide and delivering an expected behavior every single time. For our code, imagine moving the meta box add/register, render, and save functionality into a module that generates your custom meta […]
Add Another Meta Box – Portfolio
Let’s demonstrate the amount of work it takes right now to add another custom meta box. Hmm, let’s add a portfolio details meta box to collect the client’s name and URL.