Series Introduction & Project Overview
Hi, I'm Chris from Codereviewvideos.com and in this video series we're going to get started looking at Symphony 3 for beginners. So by the end of this tutorial series, you'll have made this app which I'm calling my githut. It's obviously a total ripoff of GitHub and in fact, we're using GitHub's API behind the scenes to pull in this data. The idea is that you can go off to any of the available sort of routes or users, sorry, on GitHub, pull in their profile and see the repositories list and and populate this little sidebar thing here with the with the data.
You don't actually need to have a GitHub account, you don't need to use their, um, you don't have to have like an account yourself to use their API. We just, you can pop in any user's data and just play along, basically. But I figured GitHub, as developers, probably you've got a profile in some way, but you don't need to have like an application setup or anything. So we're not authenticating. You can go ahead and add that in if you wish, but it's really sort of not within the scope of what we're trying to do.
Core Technologies: Symfony, Guzzle, Twig, Bootstrap
So the technologies that we're going to cover off are Symphony 3 obviously. That's going to be what we do like all our code inside. We're going to use Guzzle to talk to the API, so GitHub's API. We're not really going to have to know too much about Guzzle honestly to be able to do this, so don't worry if you've never really played with Guzzle before. But basically, Guzzle is just like a HTTP client for sending requests off to APIs and stuff like that. As I say, we'll cover it as we go through.
We're going to be covering Twig quite heavily and Bootstrap, so that's for our all our layouts. So those are really the core bits that we we'll be looking at as we go through. Now this series is designed for you to sort of follow along whilst watching the videos. So I would advise that you do that. If you're first learning Symphony then the easiest way to sort of get your head around the syntax and stuff is is to sit there and type it in. Honestly, copy paste or just downloading the repo from GitHub, you're not going to learn as much as if you actually go ahead and and type it in yourself.
Configuring the Development Environment
So we're going to be working in an app environment called app_dev, or just development. And the way that we get to that, so Symphony's got two environments set up, and technically three, but two environments that we can sort of get to straight away. We got the concept of app, which is our production environment, and we've got the concept of app_dev, which is our development environment. Obviously in development, you want to be in app_dev as that gives you access to the web debug toolbar, which we'll see in a sec. To get access to that, you can put your IP address into this section. This is sort of a way of restricting down the amount of people that got access to your development environment.
You only really want to put in your IP address, obviously. You will see if you go on to Google and do like an inurl app_dev and then search on that, you'll see quite a lot of people deploy this completely unrestricted into the the big wide web, which is a total fail. So don't be one of those people. And don't just comment this bit out as well, as that's, that that does resolve this immediate problem, but yeah don't be one of those people. So to get your IP address, just Google it if you're unsure, but I know mine is 192.168.1.127. So let's pop that in there. And then if we refresh, now we should see the sort of the welcome page, which is great.
Symfony's Core Concepts: Routing & Controllers
So that's rendering off. Rendering is a term that you'll hear a lot in Symphony, it just means to to take like a template or whatever and then display it out on, send it out as the response from from the web server basically, from Symphony. So that's getting rendered out as I say from inside our default controller. A default controller knows to sort of work, by default obviously, because of the routing setup.
So routing is what controls all the URLs, and in this case, what we're doing is using this resource sort of setting to allow us to put any controllers inside this controller directory. As long as they follow this this controller convention, then they're just going to get picked up and we'll use annotations to set up all our controllers. So that's how that's all sort of just immediately working in case you're you're wondering, as I I remember when I first loaded up a Symphony project, I was like, well it's great, it all seems to work, but I have no idea how it's all, you know, fit together.
Controller Conventions & Best Practices
But yeah, there we go. Um yeah so we've got this default controller and that's what you're seeing as I say. Just to very quickly cover off, so obviously got the route, which is a slash, which just means the root of the website. Then we've named it so that if inside throughout your application, if you want to refer to this route, you refer to it by the name. So that if you change the URL, then you don't need to go through and like find that URL and replace and and whatnot. You can just basically change that as long as everything references the name you're good to go and change stuff around.
The controllers follow a a convention. So everything the name is fine, you can have whatever name you like. And then it has to end in Controller and then also your actions have to end in Action. Like that's the best practice anyway, you may be able to get around that. I think there is some ways around that but the general best practice is your controllers follow that convention, and then this convention for your naming. Request we'll get to as we go through, very common thing that you'll see on a Symphony action. And then all your actions have to return a response. As if it's a controller action, you have to return a response. So a controller, you think about it, it's what receives the the request that comes in, and then it's what sort of hands over to something else to to figure out like the business logic, and then it deals with sending back the response. So that's basically Symphony in a nutshell honestly.
Understanding the render Method
The journey from request to response anyway, there's all this carry on going on here with the getting the parameters out and whatnot and displaying them, you don't need to worry about that at this stage. The important things really are return $this->render. So this is common syntax you'll see throughout. And then this default/index.html.twig is actually coming from resources/views. So you sort of skipped the views bit, but that is where it's, where Symphony's going to look for your views. And then it's living inside this default/index. So that's where that's coming from.
And again, we're going to cover on Twig a lot in this series, so don't worry about it if you don't sort of immediately get it. But that's basically what's happening there. And then this array, so the new PHP 5.6 syntax, I think it is, where we got the newer array syntax. So that's why you're seeing the just the the single bracket there, that's what's going on. It's the same as writing array() like that and then popping it like that. So yeah, it's the same, exactly the same thing but it's a shorthand syntax for array. And we pass in any parameters to our our templates to be rendered off via an array.
Creating the Githut Controller
So we're not going to use that controller at all. In fact, we're just going to go ahead and delete it. And I'm going to go ahead and create one called GithutController. As I say, you can call them literally anything as long as they follow that convention of been named with whatever Controller. And again, if we look inside our routing, you can see anything inside the controller directory is immediately going to get picked up as a valid controller.
So let's just namespace this off. All Symphony follows this this convention. We're inside the controller directory so again AppBundleController, nothing particularly crazy going on there. Our class is going to be called GithutController, so we're just following that same convention of naming it after the file, and we're going to extend Controller, so Symphony's framework bundle controller. So that should be pretty good there.
Defining Routes with Annotations
And then we can go ahead, go ahead sorry, and put in our our function. So just using PHPStorm shortcuts there, just pubf to do, uh pubf and tab to sort of quickly write out a public function. And the way that we're going to start off this is we're just going to call it githutAction. Doesn't really matter what it's called honestly at this stage. And then we're going to pass in the request. We shouldn't really need this but we'll pass it in anyway. So HTTP Foundation. It's one of the tricky things really is um, knowing which one of the sort of auto-suggested parameters to to use, but I guess that just comes over time.
And then we're going to use annotations here, so we'll need to set these up as well. We'll need to use a use statement and it, honestly when you're first starting out in many ways it's just easier to copy-paste from the docs on stuff like this. But it is, as I say, it's nice to type it out so that you start kind of getting used to the way that it it just sort of feels under your fingers I guess. And we'll call this a githut name githut. And honestly you'll probably get your speech marks and stuff messed up as you go through the first few times as well. You can see there it's picking up the fact that we don't have a use statement for this route annotation. So let's see if we can get away with just typing in Route and then seeing if we can find the routing annotation. That should be should be good for us there. We got our request and then so here what we need to do is return and then this render as we saw in the the previous example. Caught myself out with my, uh, with my speech marks, terrible.
Rendering Views and Basic Twig Inheritance
And what we're going to do is we're going to get rid of the default template as well. Uh we're going to get rid of that entire directory in fact. We'll create our own called githut just so that we know it's ours. And then this base template is what we'll, um, we we'll render off to that first in fact. So we'll go with base.html.twig. And then we're going to need to pass in some parameters most likely. Let's just have a quick look at what's inside our base template. Um, in fact we'll be okay not to pass in any parameters here, but we could potentially go ahead and override some things but we we won't to begin with. We'll just render that off, in fact we can just get rid of that as well just to keep it as simple as possible. And we'll see exactly what we get if we go now to our route. As you can see there's nothing there, which is good, because there's nothing actually on that base template. So the base template we could stick something in here just to show that it is rendering off. And there we go, all good.
Using Twig Blocks for Template Extension
But the thing with Twig is that we get these, the concept of blocks. And what that allows us to do is create like inheritance structures with our templates. So we can have another template that sort of sits on top of that. So let's go ahead and create that now. We'll just call this one index.html.twig. You always call it html.twig or .text.twig or whatever, but to to sort of signify that it's a Twig template, you always really do it like that.
And then we're going to use this uh, percent, percentage syntax and we're just going to say extends and we're going to extend that base template. And now because we're extending that template what we can do is put something inside this body tag. So what we're going to do, or block even, so if we redeclare that block, so block body and then just make sure to close it off as well, so endblock. You can do endblock body as well. I generally don't, just do endblock. But yeah so if we put something else in there and then render that off... what we should find... we're not actually rendering that template though are we?
Building the Page Layout with a Base Template
We need to change this up too. So we're now not rendering off the base directly. If you think of like the base as like abstract, so you wouldn't really use it directly. It's just the base and everything else sort of sits on top of that. That's the way that I'm thinking about this. So I'm going to say render off instead, remember you skip the views directory, we don't reference the Resources directory, skip the views. So in this case it's going to be githut/index.html.twig. And if we refresh that now, we see that we get our our sort of our mess.
So let's quickly set this up so that it's nice and Bootstrappy. So if we go across to getbootstrap, get bootstrap, and what we're going to do is just nick the starter templates and also the Styles. Now there is better ways to do this, but for the purposes of demonstration this should see us through. I think that will be enough actually.
Integrating Bootstrap for Basic Styling
Yeah, so what I'm going to do is I'm just going to take this entire link, so effectively just use the CDN link or Content Delivery Network link. Where it says stylesheets, I'm just going to go ahead and just pop that in above. A bit difficult to to see cuz the screen's quite small, but effectively just paste it in the Bootstrap CSS. So immediately I've got access to that.
I don't really need to worry about the stylesheets at this stage, but we will come up with our own stylesheet anyway. So that's got the Bootstrap stuff in there. And then what I'm going to do is just get rid of that bit. And I probably needed to keep that bit open actually. Go to the examples, go to the starter template, just take a copy of the source, or at least the important bits of the source. I'm just going to nick this navbar, just paste this in into our our body there like that. I'm just going to call this off to, so get rid of these bits here, don't really care about them. And I'm also going to get rid of this button thing here, I don't really care about that. And I'm just going to call this my Githut, my Githut and set this to navbar-default. Don't really want the navbar-inverse, I think it's navbar-default. You're free to experiment with this as as you see fit. And then what I want to do is rather than have to keep declaring new sort of get Bootstrap rows and stuff, I'm just going to go ahead and do this, and then put the body inside them. So I'm going to do a new, let's see. So we got the container, let's just nick this bit first and then I'll show you what I mean. So I'll stick that bit there. And then we've got this starter template.
Managing Custom Assets with the asset() Function
Now also I'll need, I will need to put in a stylesheet as this is going to mess up a touch in a sec as we'll see. Yes, it overwraps there because we need to put in this. So if we go into the view source of here, and then go into the starter template, we do need this bit as well. So what you need to do, Symphony best practice, this is a bit weird honestly, but like you've got your views and that up here, you've got your code and that in here in the source directory, and then your CSS actually lives inside the web directory. So I'm going to put it in here, css. I'm going to just create this and call it say my-style.css. Paste that in. I'm going to change this off to saying 90 pixels as that padding is not really brilliant. I'm pretty sure that's right, but we'll see anyway when we when we render this off.
Go back to the base and then I need to add in a another thing here. So I'm going to do link:css like that and just tab that out, PHPStorm shortcut there. Just, I I struggle to remember how to do a stylesheet honestly, so I don't really do them like that anyway. And then what you need to do is wrap this in some parens like this because we're going to use Symfony's asset syntax for this. So asset, and then we will be living, I think it's just my-style, my styles is it? my-style.css. So let's pop pop that in brackets, should be good. asset/my-style. Let's just give this a refresh back on our own page. It's not picked it up. View Source, where are we, my-style, an error occurred because I'm not in the CSS directory. css/my-style. Let's try that again. Right, so we're getting somewhere with that. The styles are a bit weird there. This isn't inside a row as such, and I'm too far down as well I thought. Sort out them styles in a sec anyway. We've got the concept of this container and then our block body is outside that container. So if we put this inside the container and then refresh, we should find that we're now inside that container. This sort of weird starter template thing is pretty much, probably yeah exactly what they've got on that. 90, 90 is far too big I think it must be 60 or something that we want. Just don't want it like sat over the top. Maybe it's even 40, maybe it was this one that's 60 something like that. Let's just give that a shot. Good enough for the moment. So anyway, that's basically where where we're up to with the first bit. That's that sort of Twig weird inheritance thing that you've kind of got to get your head 'round. But basically we're going to get rid of this this starter template section here entirely, and then just start working with our body from the next video.
