Over the past few years, I’ve spent a significant amount of time writing about a lot of things on how to achieve certain things in WordPress. And I don’t regret it (after all, it’s my career and it’s even the subtitle and focus of this blog).
But one of the things that I’ve opted to neglect is a focus more on topics that interest me such as object-oriented analysis, programming, design, and implementation. (And, of course, doing so within the context of WordPress.)
And sure, there are some articles where I’ve touched on it but I recently took a week off of pretty much everything except my [growing] family and during that time, I took stock of a variety of things.
One of those things included this particular site, its content, and the general focus of my career.
If you’ve read this blog for any length of time, specifically in the last two or three years, then you know I’m a fan of object-oriented programming especially so in the context of WordPress.
And if you’ve followed me on Twitter, you know that – like many of you – I’ve met many people who I consider to be legitimate friends (versus the bastardization of the phrase by sites such as Facebook)
On top of that, you know one of my favorite past times on Twitter is trolling said friends. So far, though, this entire post is all about my friends and me and, ahem, trolling.
So what’s the point?
Ultimately, it’s to give you a heads up something that’s been released today, that’s been a long time in the making, that’s finally available, and that’s going to help anyone who wants to be a better WordPress developer.
When it comes to creating classes for WordPress plugins, I’ve been asked about why I bother separating functionality into subscribers and into other classes.
I think this is a good question because it helps to understand two things:
- the role of a subscriber as it relates to the WordPress architecture,
- the role of the other classes as it relates to what it is you’re building (and how this can help with other things like unit testing and so on).
So I thought why not respond in the form of a short post? It’ll document the why behind the what [and it will give me a place to update if things change in the future].
When I set out to create a members-only section of my website, it was to do two things:
- provide members with access to high-quality articles for how to approach object-oriented programming in WordPress,
- grants discounts to other products and services that I found useful via friends, acquaintances and other services.
Periodically, I do get questions about the content that I’ve produced thus far. If you’re interested in reading the full, detailed list, you can see them here.
But the gist of what I have so far is here:
And that’s the content that I have for site members thus far. But that doesn’t answer the question of what’s next (nor does it answer the question as to why I’ve laid things out the way that I have), so I thought I’d take a post to do that.
When we talk about the concept of Models in object-oriented programming, we’re usually referring to a class that is a representation of the data stored in the database.
That is is, when information is stored in rows and columns, we populate a class, its attributes, and so on with that information so that we’re able to pass it around the application, manipulate it as needed, and then possibly serialize the data back to the database.
But in a web application, it’s fair to assume that the model might need to be possible to the front-end to be used. That is, imagine a front-end request making a call to the server, requesting a model (or a collection of models), and then rendering them on the front-end.
Though this particular post isn’t code-oriented, I still think it’s worth thinking through the process of translating a model from the server and then rendering it on the front-end of the web application.