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.
