When working with arrays in PHP, specifically in the context of WordPress (which is obviously the norm around here), it’s become pretty common to see code using the foreach construct versus a vanilla for loop when working through an array.

Personally, I think it’s easier to read and that it works especially well when working with an associative array. That is, it’s really useful when you need to iterate through a collection that’s indexed with a unique set of keys that aren’t necessarily in numerical order (which is something you’re more like to see in a for loop).

Most who have been working in WordPress, let alone PHP, for sometime are likely familiar with everything that’s just been said. That is, when it comes to working with a collection, it’s easy to think

“Okay, so I’ve got a collection of information and I need to iterate through it. Working with a `foreach` loop is easy because it will allow me to traverse the list just like a `for` loop without having to initialize a variable, set an upper limit, and increment the iterator.”

Granted, maybe that’s a bit of a mouthful – maybe we just say “foreach loops are easier” – regardless, there’s another way that we can think about using language constructs like this.

That is, rather than think of them as ways to simply iterate through collections of data, we can also think of them as ways that inform the decisions that we make when building a user interface.

Top Down or Bottom Up?

Often times, I find that developers tend to think in one direction whenever they are building a solution. That is, we tend to approach a problem from either the top down (that is, from the user interface down to the database) or from the bottom up (from the database upwards to the user interface).

Regardless of which approach we opt to use, said approach will ultimately inform a number of decisions that we make about:

  • how the user will input information into the application
  • how the application will process, sanitize, validate, save, and retrieve information
  • how the data will be stored in whatever data store is being used (databases, flat files, etc.)

And this is something that’s normal. Most developers do this. But at some point in our careers – some earlier than others (or later, in my case :) – you stop thinking about things in one direction and start thinking about the solution holistically.

There and Back Again

A Hobbit’s Developer’s Tale

When you do this, you start creating more elegant solutions where the design and approach that you’ve taken to solving a problem is evident throughout the codebase. You’re able to see the thought from the UI down to the database and back again.

A Small Example

Granted, I think that larger examples or snapshots of code would serve us better than anything else but dissecting an application is topic for an entire blog all its own.

So in an attempt to give some type of practical example of this, here’s an [incredibly] small example of how to think through this:

Let’s say that you’re working with something in the WordPress dashboard and you need to display all of the comments for a given post in a meta box. Furthermore, let’s say that for each comment, you want to display a checkbox to denote whether or not some arbitrary action has been taken (such as it’s received a response).

There are a number of ways to think through this – naturally, some of which are better than others – but we’re looking for a way to render and store information that shows deliberate thought from the top-to-bottom and bottom-to-top of the stack.

Here’s a high-level of what we need:

  • A list of checkboxes that display the content of a comment
  • A way to save and retrieve all of the comments and the values of their associated checkbox

Relatively straightforward, right? Since we’re dealing with input elements on the front-end of the site, then it makes sense to treat them as an array of comments. This will also help us to retrieve the information from the database (via the WordPress API) when it comes to displaying it.

In the most basic way, we can retrieve all of the comments and index them by their comment ID like this:

Then we can enter the serialization code:

And finally, the code for retrieving it:

Honestly, the code could be refactored a little bit more such that the retrieval of the comments and the array_key_exists call are abstracted out of the view and made into a single function call. Though, for this post, that’s besides the point.

As I mentioned, this is a really, really simple example but the goal is to demonstrate how to think about how data is displayed, stored, and retrieved in a way that also leverages the natural constructs of the language(s) being used, as well.

Ultimately, it’s about letting the constructs of the language help contribute to how a solution is architected. No, they aren’t the only thing that help drive the solution, but they can help with thinking about how data will be stored, processed, and retrieved.