Practice English Speaking&Listening with: CS169 v13 w5l1s1

Difficulty: 0

OK, well, we are back and we are continuing our whirlwind tour

of Eails. We structured our tour around the the idea that what

most Rails applications do really is they manipulate models.

Models is where the action is and that there's these four basic

operations to create, read update and delete that you can do on

them. And we're now going to deal with forms, which are going to

take us to the create and update actions. Really, we just dealt

with read before. So, you've all dealt with forms. They allow

you to fill in little stuff on a website, submit it to a server

and, for our purposes, the interesting thing that we're going to

realize is that creating a form usually takes two interactions

because the first thing you have to do is you have to do some

action that causes the form to be served to the user. Then the

user fills in some stuff and then the user submits it. So you

really need two actions. You need one that knows how to generate

the form and one that knows how to accept the form submission.

So we're going to treat those as separate cases. So we have to

figure out how do we generate the form? That's an action. When

the user fills in their values, how do we get access to the

information they've filled in? And when we're all done with

that, what do we return or what do we render? Remember we're

dealing with HEDP, which is a request reply protocol. That means

every request, something has to come back and be rendered. So

what is the right answer to do that for these different kind of

form interactions? So, continuing our cookbook things that we

know how to do with Rails. Here's how you submit a new

submitable form and we're going to walk through each step of

this process. First we have to identify the action that serves

the actual form, the blank form that the user's going to fill

in. Or we'll see it could be a form that already has some

information pre- populated. For example, if you're making a

change to an existing resource, the form might show up already

populated with the old info and then you can type in new info.

Then you have to indentify which action is going to receive the

submitted form and that's where we're going to get access to

whatever the user entered. We have to make sure we have routes,

controller actions and views for each of these two things. And

as we'll see, when we create the form, the name attributes on

all the form elements is how we're going to get our hands on the

data that the user typed. They're going to appear as keys in

this magical hash- looking thing called params that we saw

briefly before and we're going to see a couple of times during

this segment and the next couple of segments. And as we see, as

with so many things in Rails, the common case is provided for by

a number of different helpers that you can call so that you

don't have to manually deal with all the form construction. In

fact, it's fair to say that the Rails view of a form is that

it's really a thing that ultimately gets backed by a model. So

what you'll see is that a lot of the helpers for creating and

dealing with forms are really based on the idea that a form is

exactly a view of a model, but it's an updatable view because

the user can type stuff. So, let's talk first about how we're

going to creat the form. We need an action that's going to serve

the form to the users so that they can fill it in. And to do

that, we're going to look at a very simplified version of a form

in HTML. So, a couple of things to notice about a simple HTML

form. Here is a simplified version of the form for creating a

new movie. And a couple of things to notice. First of all, the

actual form tag, that encloses everything has to have at least

an action and method. This is really what's going to determine

where the form is submitted. And remember we've kept saying that

a route consists of both an HETP method and a URI and a D. You

see them both here. The HETP method is going to be post. And

here is the path portion of the URI. And then, inside the form,

we have a number of elements. Input elements and select elements

are examples of things where the user can specify values and

you'll note that all of those have a name attribute and the name

attribute is going to be the key of how we get that information

in the controller method. Now, it might look a little bit weird

if you're coming from other web environments that the names of

these attributes have brackets, like movie bracket title, movie

bracket rating. And in a moment we're going to see why that

turns out to be a useful naming convention. The names can more

or less be anything you want, but there's a good reason to make

them look like this. So we're going to generate the name form.

Only the the inputs that have name attributes are going to be

submitted. And we can often use a URI helper with the action

part of that form. Remember, we said the whole point of the

Rails routing sub- system is to avoid having to hard- wire URIs

all over the place. In fact, it gives you these helper methods

that generate the URIs associcated with various restful actions,

including the crud actions. And we actually already saw an

example of that. We're going to take a look now at the Rails

code for creating that simple form. So, here's the form as it's

going to appear as it arrives at the browser. But looking

briefly at what this looks like in Hamel. And what I did here

is, underneath each line of Hamel, I included one or more lines

of the HTML that would be generated from that Hamel, so you can

see what the mapping is. So, this line with the action and the

method that we saw in the HTML form actually came from this

Hamel tag. This is just a Ruby method called Form Tag. It takes

one argument, which is the URI of the receiving action for this

form. And we're using one the URI helpers so we don't have to

hard code a URI in here. That's why it said form tag movie path.

I could have just as well said form tag quote slash movies, as

long as I have a way of specifying the path portion of the URI

that's going to receive that form. The form tag has got a body.

You pass it a block with do and inside of the body, you can see,

for example, that some of the fields in the form - here's an

example of the text field where the user would type in a name

for a new movie. What it comes from in Hamel is this text field

helper method. What's going on here is that you're telling text

field that there's such a model called movie. One of its

attributes is a title. And what I want you to do is to generate

a form element suitable for editing that attribute. So again

it's really much that the view is not you're designing the form,

the view is that you're designing an editable version of the

information already associated with the model. So that's why the

form tag helper is like text field. You don't have to use these.

You could code the raw HTML in Hamel if you wanted, but the

benefit of doing that is it reveals intent and allows you to

connect the form very obviously to which attributes of the model

it's supposed to be editing.

The Description of CS169 v13 w5l1s1