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 […]
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.
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.
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 […]
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.
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 […]
Let’s start mapping out our default configuration model. We’ll start with the add/register meta box function.
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.
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 […]
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.