The previous post demonstrates a lot of work in taking something that was once a rapid prototype and taking that prototype to code. If you haven’t been following along, we’ve done the following:

1. talked about and built a prototype for a plugin,
2. diagrammed out one object-oriented approach may work,
3. and refactored our prototype to actual code.

At this point, there are a few more things we can do to improve our code. Namely, we can introduce the concept of namespaces. This takes the organization a step further and can pay dividends for larger projects.

So here’s a look at how this plays out in our current project.

Continue reading

As far as rapid prototypes and WordPress are concerned, we’ve done two things thus far:

1. planned the plugin,
2. sketched out a diagram for how the code can be organized

At this point, we’ve done enough work to warrant beginning to refactor our code. That is, we’re going to start converting the prototype to code. But this is something that’s going to need to be done in two phases.

First, we’re going to simply introduce classes that represent the diagrams from the previous post and that encapsulate the responsibility of each project.

After that, we’ll look at organizing the code into namespaces and packages. Before we can do that though, we need to make sure the code is object-oriented and remains functional. So that’s what’s going to happen in this post.

Continue reading

In the previous post, I started walking through the process of taking the idea for a plugin that rapidly prototyping it into something that works within WordPress. And though it works, it doesn’t necessarily follow any object-oriented principles, nor is it in a place that we can easily continue to add features.

No, this isn’t an argument for why object-orientation is better. It happens to be my preferred way of writing code so I’m approaching it this way.

I know that the example code I’m giving is simple and I know that a case can be made that something like this can be left as it is. But the point of this is to show how to take a concept, prototype it, and then move it into something that follows object-oriented principles.

And, in my experience, it’s much harder to do that with a complex example from the outset. if you lose readers from the beginning, then what hope is there for them to understand what’s coming?

So with that said, we’re going to take a look at the code from the previous post and do a bit of a concept analysis on it to see what might work well within a class and how we might begin to organize it using classes, namespaces, and so on.

Continue reading

I’ve talked about using WordPress as a tool for rapid application development in a past article.

But the longer I work with WordPress and the more code I see, the more potential I realize it has as both a platform for rapid prototyping and then taking those prototypes to fully developed applications.

These plugins can be web applications, plugins, themes, websites, whatever. For the purposes of this post, it doesn’t matter. Instead, what matters is that for example:

• you have an idea for a plugin,
• you want to see how it might work within WordPress,
• you quickly put something together,
• you begin refining it.

For many who are getting involved for more serious WordPress development, I thought it might be worth taking a look at what this looks like. Namely, I’ll take an idea for a plugin, prototype it, and then refine it into a well-organized, object-oriented plugin.

So in the next series of articles, I’m going to walk through that process.

Continue reading