The next thing we want to tackle is our battle()
function, with its array, inside our BattleManager class. It's not obvious at all what's inside the $outcome
variable, or whether the keys it has now might be missing or different in the future. To rectify this we're going to create a new BattleResult model class with some properties and methods that will clean things up and remove the need for weird associative arrays. Our BattleManager::battle()
function will return a nice BattleResult object, and we'll be in full control of what public methods we put on that.
We now have a BattleResult
class, and we type-hinted the two Ship
arguments. But now, if you look at the battle()
function, there's a case where the ships can destroy each other. When that happens, there is no winning or losing ship—they're both null. Since null
is not a Ship
object, PHP gets angry and throws an error. In this PHP tutorial we'll fix that problem by creating a isThereAWinner
semantic method in our BattleResult
class.
In this PHP tutorial we're going to update some information in our ship object and see another way that objects are different from arrays—objects are always passed by reference. We need to add a new feature to our app so that after the battle we can display the final health of the battling ships. One will be zero or negative, but how much health did the other have left? Let's take a look at how we can update the ships to reflect their new health after a battle.
So far we've been hard-coding our ships in the ShipLoader
class. In this tutorial we'll take things up a notch by fetching that information from a database. First we're going to create a new database to hold our data, using PDO
. (If you are not familiar with working with databases in PHP, you can check out the PHP for Beginners Part 3 series, which covers database fun.) Once we have the database created and filled with some ship data, we'll learn how to fetch that data back out again as an object our app can work with.
In the prevous tutorial we set up our app to fetch the ship objects from the database, but now our app ship select lists are not working properly. To deal with that, in this PHP tutorial, we're going to add a ship ID property to our class and then we will use the ShipLoader
class to query for individual ships. Lastly, we will once again need to turn the array that we fetch into an object that our app can use. As an added bonus we'll also update the PHPDoc so we can get autocompleting method names.
Our database is working well, but we currently have things set up so we are duplicating the database information, and that is going to be a nightmare to maintain. In this tutorial, we're going to clean up our database code by isolating the PDO
creation in the ShipLoader
class. Even with that in place though, we also need to make sure we only return one PDO
object. We don't need a new database connection every time it gets called on a page. We'll fix that with a little bit of logic in our PDO
code.
Things are working pretty well, but we still have some things to clean up. In this tutorial we're going to review some best practices. Our current problem is that at the bottom of ShipLoader
, our database connection information is hard-coded. That's a problem for two reasons. First, if this works on my computer, it probably won't work on production, unless everything matches up. Secondly, what if we need a database connection inside some other class? Right now, we'd just have to copy and paste those credentials into yet another spot, which is definitely not ideal.
Here's the goal: move the database configuration out of this class to somewhere more central so it can be re-used. The way you do this is fundamentally important to using object-oriented code correctly. The concept we are going to implement here is called dependency injection. The idea here is don't put configuration inside of a service class. Replace that hard-coded configuration with an argument. This allows anyone using your class to pass in whatever they want. The hard-coding is gone, and your class is more flexible.
Additional resources
Dependency Injection and the Art of Services and Containers series
Related to the previous tutorial where we implemented best practices to centralize our configuration, we also want to minimize the number of database connections. We want one connection that every class uses. In this tutorial we'll move the new PDO()
call out of ShipLoader
so that it can be created in a central location and used by everyone. How? By using the same strategy we just learned with configuration. If you want to move something out of a service class, add it as a __construct()
argument and pass it in.
So far we have to create our service objects by hand and this stuff is duplicated. We need to centralize our service objects to make our lives easier. To do that, in this tutorial we'll create one special class whose only job is to create these service objects. This class is called a service container because, well, it's basically a container for all the service objects. We're going to create our service container and then update our code to use it properly.
To wrap things up with our app, the last bit of housekeeping is to make one container responsible for creating every service object, like PDO, but also ShipLoader
and BattleManager
. The problem is that if we called $container->getPDO()
twice on the same request, we'd still end up with multiple PDO
objects, and so, multiple database connections. Ok, if we're careful, we can avoid this. We can do better though—let's guarantee that only one PDO
object is ever created. We did this previously in ShipLoader
, so now we'll move this into our container.
We've got a nice little app working now, using our service container well. Good work! In this final lesson for this series we're going to have a review of working with containers. We'll look at why this is such a good practice, discuss model classes versus service classes, and take a moment to acknowledge best practices versus the real world implementations you can end up with.
Additional resources
What Is Pantheon?
FreePantheon is more than just a hosting service. It is a powerful tool to manage your websites, and handle deployments. Pantheon provides a great framework for development best practices as well as making sure the platform you are running on is truly optimized for Drupal sites. In this overview presentation we'll introduce you to the features Pantheon provides and why you would use them to host your Drupal sites.
Additional resources
To get up and running with Pantheon, you'll need to create an account. In this tutorial we'll get signed up and create our first site. Then we'll take a tour of the user dashboard and site dashboard to see what you have to work with. We'll also make sure to point out where you manage your SSH keys for Git and get your connection information to start working on your new site.
Additional resources
Pantheon registration
How to Generate SSH keys (pantheon.io)
Pantheon SSH Keys (pantheon.io)
In the last tutorial we created a new site from scratch on Pantheon. What if you already have a site that you want to move to Pantheon though? In this tutorial we'll provide an overview of how to import your site into Pantheon. We'll discuss what the various parts of a site are that you need to work with, and some important points about what Pantheon expects. We'll also discuss the different methods you can use to import your site and the guidelines for which method to use, especially when working with large Drupal sites.
Additional resources
Importing an Existing Drupal Site to Pantheon (pantheon.io)
Now that we have a site archive file, we need to get this imported into our Pantheon account. In this tutorial we will do just that. In the process we will look at the two different interfaces for doing an import. For our single-file site archive, we can use the default interface, but if you have three separate files for the database, code base, and files, we'll look at how to get those uploaded as well. If your site is too large to import using the Pantheon dashboard UI, then you should check out the instructions for Importing a Large Site on the Pantheon website.
Additional resources
Importing an Existing Drupal Site to Pantheon (pantheon.io)
Importing a Large Site (pantheon.io)
With your site created or imported into Pantheon, it's time to begin getting some work done on it. In this presentation we'll provide an overview of how Pantheon is set up to support your development workflow, from making changes to your code base on dev to getting your site launched on live. We'll discuss the three environments that Pantheon provides—Dev, Test, and Live—and review how to get access to your code.
Additional resources
Using the Pantheon Workflow (pantheon.io)
In this tutorial you'll learn how to access and use each Pantheon environment. We'll start by assuming we have done a bunch of work in our initial Dev environment and we're ready to create the Test and Live environments. Once we have all three environments up and running, we'll make some changes to our site code in Dev. With that done we'll merge the code changes in Dev with the Live database in Test so we can make sure everything looks good. We'll also run a site check on Test. Once everything looks clear, we'll deploy the code changes to the Live environment. After deployment we'll see how to pull the Live database back down to our Dev environment whenever we need to.
You can access your code using either SFTP or Git. In this tutorial we'll be using Git. If you'd like to learn more about Git, or get a refresher, you can watch our Introduction to Git Series.
Additional resources
Using the Pantheon Workflow (pantheon.io)
Introduction to Git video series
By default Pantheon provides you with three environments: Dev, Test, and Live. A lot of work can happen in Dev though, and it would be really great to be able to manage all the different branches of work that may be happening simultaneously. Pantheon's Multidev feature will do this for you. You can always create as many branches as you need for development in Git, but Multidev takes that a step further by actually providing an entire duplicate environment for each of your branches. This way you can see exactly what the site looks like with those code changes before you actually merge everything into your main Dev environment. In this presentation we'll explain the benefits that Multidev gives you and walk through the terminology you'll encounter. The Multidev process and terminology is based on Git workflows so you'll be getting a short Git overview as well.
Here is a quick list of the terms and workflow we'll be reviewing:
- environment: Independent infrastructure for a site, including code, DB, and files.
- fork: To divide in branches, copying source code to start independent development. Pantheon also copies content (files and database) when forking. commit: Record snapshot to history.
- branch: Movable pointer to a set of commits, allowing independent development and history.
- master: Name of default branch; deployed to Pantheon Dev, Test and Live environments.
- merge: Combine contents of a branch into another, like a bug fix branch into master.
Additional resources
Pantheon Multidev Workflow (pantheon.io)
In this tutorial we're going to dive into using Pantheon's Multidev feature. To demonstrate how this works we'll first create a new Multidev environment by cloning the existing Dev environment. Once switched over to this new branch in Git, we'll quickly edit some code and push that to our repo. We'll use Multidev to review the new code in our dashboard, and then merge that branch into the Dev master branch. With the full process complete, we can delete that branch, and the environment with it.
Additional resources
Pantheon Multidev Workflow (pantheon.io)
Pantheon is specifically designed to make managing multiple sites very easy. The Pantheon for Agencies service is perfect for agencies or organizations that manage many sites. Getting access to Pantheon for Agencies requires that you fill out a separate registration form, and once approved, you gain access to a whole new dashboard for managing your sites and teams. In this tutorial we'll take a tour of the features you get for managing your sites, including tags and filtering. We'll also learn how to manage the people on your teams, and how you can assign different permissions to team members based on which sites they have access to. We'll finish up by explaining what upstreams are and how that can be beneficial to your organization.
Additional resources
Pantheon for Agencies (pantheon.io)
Permissions and Change Management on Pantheon (pantheon.io)
Running a Custom Upstream on Pantheon (pantheon.io)