In the intro in this section of the course we are going to walk through controllers.

I'm going to click in our pivotal tracker dashboard, open up controllers and we can see our tasks. Our tasks in this section of the course are a little bit more vague than some of the other ones. If you notice a number of the other ones such as in data management were things like implement validations create data relationships, those are a little bit more specific. In this section they're a little bit more vague, I have things like data flow review, working with sessions, analyzing parameters and some things like that.

This section is really important when it comes to once again understanding how data flow works. I know I've said it once I will probably say it a few thousand times in this course. If you understand how data flow works you are going to be able to understand and build rails applications. It is that important. I've been doing it for years now and the thing that keeps on coming back is that if you can understand

• the way that data comes in
• how you can work with it
• then how you can manage it

you're going to be able to successfully build Rails apps.

That is one of the big points of this section and specifically we're going to talk about data flow and then we're going to dive into sessions.

We're actually going to be doing both of those in this specific guide along with analyzing params, this is less about specific features and it's more about learning the way the system actually works. Don't worry we are going to build a very cool feature. One of the features we're going to be building in this section is the ability to have landing pages that are dynamically created and then you can use those landing pages to be able to essentially track users as they navigate through your sites. Very cool feature will be building that in one of the guides in this section. These are more of the topics that I wanted to cover so that you can get an even better idea of how controllers and sessions work inside of rails.

With that being said, let's switch over to the terminal and git checkout -b controller. With that open let's come to the code and I want to start with our routes.rb file. Here I have our portfolio route, this is the one I want to use as kind of our initial starting point in talking about data flow review. This is a specific route that takes in a id parameter and then it's mapped to the show action.

Start up the rails server, I'm going to open up a new tab and go to localhost:3000/portfolio/4

When I open this, we can see that we have a perfectly rendered show page.

Let's talk a little bit about data flow, let's look in the terminal, when we went to this page you can see that this is where everything started.

It started the "get" action and then it went and it said OK here is the route that he went to, this is /portfolio/4. This is the data that we initially have to work with, then it has a time stamp and some things like that. From there, It knows because of the routing engine, If you look back (routes.rb line 5) it catches this route and knows to map it to the show action in the portfolios controller. Right here it says "processing by PortfoliosController#show as HTML." The reason why it knows to use HTML is because that's the only option we have and also because we're accessing it in the browser. If we had an API then we would be able to access this for say json data or XML. Since this is just a regular user in the browser it says let's just show him HTML.

The next item is something very important which is the parameters. This is something that you will have access to when you're working with the controller and it's incredibly important.

I know that we have talked about this already, if we open up the portfolio_controller.rb we've talked about how this could work in terms of doing things like working with the params in the forms but then also whenever you're finding it. An example would be in the show action right. We have portfolio and then we're taking the params, this param right here where it says params[:id] is a way that you select this (Parameters: {"id"=>"4"}, which is in the screen shot above).

We have access to parameters, it's not called params but this is the way rails actually treats it, params is a special word. In this case we just have parameters and then the id, that is something that is very important to know.

Let's walk through how we can actually see this in even more detail. Open up the portfolio show page show.html.erb on the very bottom you can add an hr tag just so it can be clear what we're doing. With embedded ruby, write the code exactly like this:

<=% params.inspect %>

Params are a very special construct in rails, it is is a hash data structure. If you're familiar with ruby and hashes, it's just a ruby hash that allows us to keep key value pairs. Looking at the terminal, you can see the key value of "id" is a string and then a value of "4". This is saying it has the parameters have an ID of four. Hit save and switch back to the browser.

If I hit refresh, you can see right here that we now have a parameters hash that's available to us.

As users go through your site, this is in the background and it's hidden. This is something you have access to. Right here is the reason why you have access to it in all of these controller actions. Remember we have a direct data flow connection between the controller action and the view that it's associated with.

Params is something you could think of it is kind of just being under the layer of everything that's going on it's something that the browser knows about and it's something that your application knows about and that it can work with.

If you look at this, you can see that the parameters we have more than just the idea 4, that's only one parameter that got parsed by the router. We have the action show and we also have the controller and portfolios, as you saw we have the ability to pass in a specific item that we want.

Say we just want the id, right here and you can see it's 4. If we only want the action, you can see this is the show action. There's no crazy rail's stuff going on with this, this is just ruby code in terms of being able to select a value out of a hash. This is something that can be very handy, I have seen multiple times and I've implemented this where we wanted to build something that could dynamically change the behavior on the page based on the controller that was accessing it. This is when you get into some more advanced dynamic views that have the ability to have multiple controllers.

For right now, all I want you to focus on is the fact that there is underlying data that you have access to as you go from page to page.

In review, what this is doing is we're saying that when this came in, the router got their request, it mapped it and said Okay that is an id, we know this is an id. If you go back to the routes, right here portfolio/ is looking for an id. This is where it all starts, the router needs to say OK I need to find a route that matches this pattern, ok, we have one called portfolio and it is expecting some type of set of parameters. It's going to grab those and then it's going to store those in the hash. From that point, the controller takes over in the show action. The show action takes it, It says ok I have the parameters, I'm going to run a database query in the portfolio model, store it in the instance variable and then all of this gets passed here.

Something that's really important, I am going to show you this and I'm going to say that I'm showing it to you to say you will never ever do this in an application because it's a horrible practice. At the same time I want to show this to you because it really helps in terms of understanding data flow. Once again for demonstration purposes only!

If I want to do something like <%= Portfolio.find(params[:id]) %> if this looks familiar it's because it is its exact code right here.

We store it in an instance variable so that it's easy to manage the data properly but here we can just grab this object if we really want to. Open this up, hit refresh and look there is our portfolio object.

If I want to call anything like title on it, I can call this just like I'm doing up here <%= Portfolio.find(params[:id]).title %>. Hit refresh, now I have portfolio title number three and the same would apply for all of these other things.

We could even do it for technologies <%= Portfolio.find(params[:id]).technologies %> and look there is our technology active record relation with all of the associated technologies.

This goes to show that everything started at the router and then it got passed into this params hash and the params hash is where the controller took over and it was able to say ok, I think this is important in a store this in an instance variable and make it available to the view.

I'm going to get rid of because you wouldn't ever do that in a real life application. The reason why is this is a very basic application, think if you were to do this rebuilding Facebook or some big social media application, if you had calls to the model all over the view your code would get so messy within minutes that it would become completely unmanageable. Whenever you had to add a new feature or anything like that you'd need to find everything right inside your view code and it would just be a mess.

I have seen rails applications like that but every time I did I was being hired to come fix them because whoever built it made it in a way that it couldn't ever really be altered and had to be completely refactored.

I've talked about having a direct communication between routes and portfolios and that how you should think about it. However the params is kind of the intermediary step, the params is what makes all this possible. Technically there's a loose coupling, meaning that there's a loose connection, between the route and the controller. There's a connection here in mapping but in regards to how you can grab this, you still need the parameters hash. I wanted to show how you can access that even in the view.

That is our review on parameters and on how to work with them in the view and controller as well as, how you can access data in Rails.