We've got our Twig template files, and in this lesson we're going to take a closer look at working with creating links with the Twig path function, and making our dates make sense of the Twig date filter.
Additional resources
We have the application looking a lot better, and now, to see things fleshed out a little more we're going to load fixtures, which are dummy data we put into the database. When we started the project, we downloaded the Symfony Standard edition—our pre-started project that came with Symfony and other tools like Doctrine. Unfortunately, it didn’t come with any tools for handling fixtures. To do this yourself, you're going to learn to use Composer and KnpBundles.com to take care of things.
A fixture is just a PHP class that puts some stuff into the database. To get your dummy data set up, in this lesson, you'll write a fixture and then load it up.
Autoloading is the magic that lets us use classes without needing to require or include the file that holds them first. An autoloader has a tricky job: given any class name, it needs to know the exact location of the file that holds that class. In many modern projects, including ours, Composer handles this for us, and there are two pieces to understanding how it figures out what file a class lives in. In this lesson we're going to get an overview of how directory structures and namespaces make autoloading work.
Additional resources
In this lesson we'll going to look at a few shortcuts we can use in our controller, using the SensioFrameworkExtraBundle
, which comes with the standard Symfony project. We're going to review how to use @Template
rendering, annotations, and working with routes.
Additional resources
In this tutorial we're going to wrap things up by taking a look at some quick, simple tips for working with Twig. We're going to explain what GlobalVariables is, and then play with the block function and clean up some whitespace issues.
Additional resources
In this PHP tutorial we are going to continue to remove the flat functions in our code. We'll refactor one of them to a private function and create a new ShipLoader
service class to clean up the rest. With this refactoring in place, we'll be able to rename the functions.php file since it won't contain any functions any longer.
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.