Hi, I'm Jason, the Ruby teacher here at Treehouse.

In this Rails Scaffolding Workshop we're going to take a look at how scaffolding

works in a Ruby on Rails application.

Now, what scaffolding is going to do is set up a few different things for you.

Models, routes, views, and a controller.

Now we're gonna take a thorough look at how to use a scaffold

in your Rails application.

Now scaffolding is just meant to get you up and running with a resource.

Generally you'll replace all of this over time

as you build out your application's feature.

But anyway let's take a look at how scaffolding works now.

Okay, so let's take a look at how Rails scaffolding works.

Right now I am inside of a Rails application called example app.

This is a freshly generated Rails application.

There's nothing inside it.

Now, we use scaffolding to set up resources in our application.

So, let's go ahead and set that up now.

Setting up resources is kind of a fancy way of saying that it's gonna create

a model, controller, migration, templates, and some other files for us.

So, let's go ahead and pretend that we are creating a to-do list application.

So, first let me go ahead and create the databases.

There we go, that should have created all my databases.

Now, let's go ahead And, say, we're gonna generate a scaffold for

a todo_list.

And, when we are generating a scaffold, let's go ahead and

just say, our todo list has a title and that's a string.

We're not gonna get too complicated right now.

So, we do this, we generate the scaffold todo list, press enter,

and now we can see a whole bunch of things just happened.

It created a whole bunch of files, and added routes for us.

Let's go ahead and see what it did.

So, it created this migration file called create todo lists, let's go ahead and

take a look at that.

Now I'm using Sublime Text here, you can use any text editor on your system.

So here we go, it says it created a migration called CreateToDoLists,

and you'll notice it's got a string for the title attribute.

And the title attribute was what we had on

the command line when we generated the scaffold.

So it also created a model for todo list.

Let's go ahead and look at the todo list model.

So here's the todo list model, it is just an empty model.

Let's go back and see what else happened, we have a test for

it as well as a fixture.

Let's go ahead and load up the fixture and see what that looks like.

So we open up the test directory, fixtures, TodoList.yml And

this created two different fixtures for us.

Fixtures are going to be inserted into our database and

it's just some test data for us to work with.

It added a resource to our routes called to do list.

Let's go ahead and look at that.

So if we open up our config directory and open up the routes file,

we now have this line added, resources, to-do lists.

So that sets up our todo list routes for us.

Which is going to go to the todo lists controller,

which is also the next thing that was generated for us.

Let's take a look at that.

So if we open up this to do list controller we can see we

have a few different actions here.

We've also got this before filter that sets the to do list for

these particular controller actions show, edit, update and destroy.

Let's scroll down and see what that looks like.

Well, it looks we have this set TodoList method.

This sets up an instance variable, which finds a to do list by the ID parameter,

and also where set up the TodoList params itself.

This is going to be part of strong parameters.

And, it says, inside of the controller,

that we need this TodoList parameter for the parameters to be sent in.

And, we are permitting the title attribute.

So, set_todo_list is set.

Then, we can call it in the destroy method.

Update method.

Create method sets it up itself based on the TodoList params.

Edit method, all set.

To do list just creates a todo list and

show method also gets it from the set todoList method.

Now if we were building up a real TodoList controller, this would be a good start.

This wouldn't be everything that we needed because

odds are we're gonna be replacing parts of this throughout the application.

We might decide that we need more attributes inside of the todo list.

Maybe we are going to respond to more than just HTML and JSON.

Or, maybe we need to manipulate the todo list in some way,

perhaps to add the ability to add files, not really sure.

The scaffolding is just meant to be a starting point for this application.

So let's see what else it generated.

Looks like we have some views here for index, edit, show, new, and

the form template Let's go ahead and see what those look like.

So here is the index file.

We are listing the todo lists, and it goes through, and this is interesting.

It actually displays the title for us and

then links to all of these different actions.

Go back here. It's the same thing for the edit,

show, and new pages.

Let's go ahead and take a look at new though.

We just render the form same thing on the edit page.

Here is the form file.

The form template partial just specifies it's a form for the todo list.

Shows you any errors that happen if we tried saving the to do list.

And then it creates a field for the title and a submit button.

And this is all done for us.

Finally we get a controller test and a todo list helper.

The controller test, let's take a look at that.

It's down here.

Now this is going to go through.

It uses the fixtures that were set up and just asserts that all these

things are working as expected which is that things are going to require a title.

It's given a title for us and

everything is kinda just happening as we expect it to inside of a controller.

Helper is going to be empty because we

don't know what we're going to need inside of the to do list.

So helpers are going to be used for adding view logic inside of method.

So if we wanted to say something like display to do list header.

Maybe that has the title of the to do list and

its due date for some of the items on there.

We don't know.

That would be logic that we encapsulate inside of this module, but

there's nothing to do yet.

But rail sets it up for us.

And finally we have the index.json.jbuilder and

the show.json.jbuilder.

If we were creating an API we would be using these different files.

Sorry the, here's the json builder.

We would be using the json builder files to say okay, here's our todo list,

give me the ID, title, created_at and updated_at attributes.

These created_at and updated_at attributes are set inside of the migration,

that's what this timestamps method does, creates created_at and updated_at.

And then when you create or

update a record, those are automatically updated for you in Rails.

And then finally we have a CoffeeScript file generated as a JavaScript file.

And a todo_lists style sheet created as well

in these could be used inside of our application.

This is where we would put our JavaScript logic if we had something just for

the todo list controller.

And, the same thing.

If we had todo list stylesheets that just needed to be applied to todo lists.

But, let's go ahead and look at the assets here.

By default, the application in JavaScript includes everything.

So that is going to include the todo list CoffeeScript file.

You can change this if you wanted to.

Take it out of the required_tree if you wanted more

fine grain control over when these things are loaded.

If not, it's going to apply to the whole application and

not just your todo list controller.

So, that's up to you.

Same thing occurs in the style sheet.

And this scaffold CSS file is something that's generated by Rails automatically.

It just gives you some basic styling for Rails application.

It's created when you generate a scaffold if it doesn't exist already.

So we ran the scaffold.

I'm gonna clear my screen here and let's go ahead and migrate the database, okay.

And let's see what this actually did for

us now that we saw all the files that were generated.

So if we open up the Rails application right now we can see

this is the default Ruby on Rails page.

If we wanted to get to what we just created.

We would go /todo_lists and

this would be the scaffold that was generated.

So I could create a todo list and

this will tell me the todo list was successfully created.

I could view it, could edit it if I wanted to.

And I could also destroy it.

So that's a Rails scaffold.

I'm gonna go ahead and stop the server here and clear the screen.

Now let's say we wanted to generate another scaffold for todo items.

We could do the same thing, rails generate scaffold todo_item,

and we will say that has a title, which is a string,

and a due_at column, which is a date time.

And furthermore, let's go ahead and

say that these to do items belong to the to do list.

We could say that by saying that the to do item references the to do list.

We could say, to do list.

And we give it this key, references.

Now here's something neat that you can do with scaffolding.

I'm gonna use a dash and the letter P and

that's going to pretend to create the scaffold for me.

So this didn't do anything, but it said it was going to.

It was going to create a migration and it's going to create a model.

Basically everything that was created last time.

But if we look inside of the application here,

we can close these, we'll notice that we didn't

get the controller, we didn't get the models either.

So adding -p as a flag will pretend to generate this scaffold for us.

Now, I'm gonna go ahead and just generate that.

Okay.

Now, let's take a look at this references.

If you want to set up a relationship of some sort.

Here, we're using references for todo_list.

And we're indexing that database column and also giving it a foreign key.

So if we where to migrate the database right now.

Okay, we create the todo_items table, and

if we look back at the todo item model, we can say that it belongs to a to do list.

What you'll notice is that the scaffold does not tell the to do

list that it has many to do items.

So if we wanted to do any kind of different relation

we would have to add that in this migration as well.

Now in addition to being able to pretend what we wanted.

Let's go ahead and take a look at the scaffold generator help.

So if we add two dashes and the world help.

We can see we have a bunch of different options here when we are generating

the scaffold.

And this will give us more control

over the different scaffolds that are generated.

So let's say we were scaffolding the to-do items like we just did,

and we wanted to index the name.

We could say, indexed field, give it a type, and also another colon at the index.

Now as far as options go,

here's everything we can pass to a scaffold generator.

Are we generating style sheets?

This defaults to true.

Are we generating style sheets with SCSS?

The default is SCSS.

Now we could say that We want to skip asset generation entirely which

includes JavaScript by saying no assets or skip assets.

Are we scaffolding a controller?

The default is scaffold controller.

We also get active record options.

Do we want to generate migrations, timestamps,

parents which will also add indexes and references for belongs_to columns.

You'll notice that defaults to true

which is what we said on the command line before with references.

As we scroll through we can see we have all of these built in options.

So, in addition to pretend, with -p, which is what we added before,

we can also call that with two hyphens and pretend.

If we wanted to make sure that everything was completely overwritten,

we could use the force, or -f option.

We could suppress output by doing --quiet, or -q.

Then we could skip files that already exist by typing --skip, or -s.

Now we can change all of these things from the defaults as we're generating

the scaffolds.

It tells you what the defaults are in the regular general command with help.

And those are the basics of working with Scaffolding in a Rails application.