People love the MeBay site, but there’s a problem. Because MeBay was nervous about people having too much access to the data, sellers have to phone in details of their items to MeBay and wait while the system administrators create new ads for the sellers. As the number of people sending in ads has grown, so has the wait time. A lot of people are taking their business to other advertising sites now.

So MeBay has relented. After some discussion, they’ve decided that people should be allowed to post their own ads on the site using a page that looks like this:

The ads only go one way in the current application. The ad records are read from the database by the model, which converts them into ad objects that are then sent to the view by the controller. It works like this:

Sharpen your pencil Solution

Draw a diagram to show how you think the new ad-posting feature will work. Be sure to include the main components of the application and add notes to describe what each component will do.

Saving data to the database is similar to publishing ads from the database, except it works the other way round. Instead of a page template to display an ad, you need a page template to submit an ad. Instead of a controller action method to send an ad to a page, you need a controller method to read data from a page and turn it into an object. And instead of the model reading a record and converting it into an object, you need the model to convert an object into a new record in the database.

You need a new page template to create the HTML form. Because it will be used to enter new ads, we’ll call this template new.html.erb.

The “New ad” page will need to appear at

http://mebay.com/ads/new

and the form will be submitted to:

http://mebay.com/ads/create

So we also need to create a new route in routes.rb.

Sharpen your pencil

The controller method will need to create an ad model object from the data in the form. Can you see an attribute in the model that does not have a field in the form? Why is that?

Missing attribute: ___________________________________________

Reason it’s missing: _________________________________________

______________________________________________________________

What will the route look like that will connect /ads/new to the new.html.erb file, and /ads/create to the create method in the ads controller?

______________________________________________________________

______________________________________________________________

Sharpen your pencil Solution

The controller method will need to create an ad model object from the data in the form. Can you see an attribute in the model that does not have a field in the form? Why is that?

What will the route look like that will connect /ads/new to the new.html.erb file, and /ads/create to the create method in the ads controller?

The top of your config/routes.rb file should now look like this:

There are close relationships between many parts of a Rails application.

After all, the model contains the data for the application, the view allows the user to access that data, and the controller provides the logical glue that connects everything together.

But is there some special relationship between a form and a model?

Apart from the generated id, the fields in the form match the attributes of an ad object.

At some point the application is going to have to transfer data between the form and model. The name field will match to a name attribute, the description field will match to a description attribute and so on.

What if the model creates objects with default values in the attributes? Should the code that generates the default values in the form duplicate the model code?

After all, when the data in the form is received by the controller, should the form treat the fields as individual values? Or should all of the field values be associated together, like the attributes of an object?

Could Rails make use of the relationship between form fields and a model object when creating a form?

Rails can use a model object to help create a form. That means two things:

So how can a name associate a field with an object? Let’s look at what it would mean for the ad form. This is the HTML that will be generated for a form that’s based on an Ad object:

Form Object Magnets

It’s time to write the new.html.erb page template. The <% form for %> tag is used to generate a form using a form object. Complete the fields in the form using the magnets below:

Form Object Magnets Solution

It’s time to write the new.html.erb page template. The <% form for %> tag is used to generate a form using a form object. Complete the fields in the form using the magnets below:

Test Drive

The page template for the “new” form is in place and it should generate HTML in the same way that we generated the “show” pages. There’s also a route in place that connect the “/ads/new” path to the “new” template. So let’s see if it works by going to:

http://localhost:3000/ads/new

The page crashed!

The problem is caused by the @ad object. By default, a variable like @ad is set to a special value called nil, which means no value. If @ad is set to nil, instead of being set to an Ad object, it won’t have attributes like @ad.name, @ad.description, and so on.

If @ad doesn’t have attributes, does that cause a problem for the form?

You bet! The form is based on the @ad object, and the form accesses each of the object’s attributes to generate the initial values of the fields in the form. But as soon as the first attribute is called, nil is returned, and that causes an error.

So how can we avoid this problem?

When the page with the form is generated, the initial values of each of the form fields will come from one of the attributes of the associated object.

Can you think what the problem is with that?

The problem is that before the form can be generated, the new ad object needs to already exist. Of course, until the user completes the details of the ad, the object won’t be saved to the database—but even so, the object needs to be created before the page template is called.

Brain Power

Where in the application would you create the new ad object? If it’s a template or method, what would it be called?

The ads controller now has one method for each of the page template files. Rails will always call the controller method before generating a page from the page template.

It’s the combination of a controller method and a page template that make up an action. That’s why the action name appears in the name of the controller method and in name of the page template file.

Do this!

Now you have the controller creating the new ad object before the new.html.erb page template runs, it’s time to see if the code works.

Test Drive

With the controller code in place, it’s time to try the application again by opening a browser at:

http://localhost:3000/ads/new

Now enter some data:

The form page displays perfectly, but when you enter some data and submit the form, Rails returns an error telling you that you haven’t written a create action. The create action? That was the action you decided would receive the ad from the form.

What will this action need to do? It’ll read the data from the form and use it to create a new ad.

But what does the form send back to the application?

The form was generated using an Ad object. But what exactly does the form send back to the server when the form’s submitted?

Because the form uses HTTP, it can’t send the form object over the network. Instead it sends data.

But how is the data FORMATTED?

Think back to how routing works. When a request arrives, Rails sends the details of the request to the routing system, which inserts values into a data structure called params[...], with values for the action and the controller.

The params[...] data structure wasn’t created just for routing. It can also be used to store any data submitted to the application by a web form.

A form’s fields are recorded in the params[...] table along with the name :ad. Then, the value of the :ad variable is actually another table of values, a table that maps a field name to a field value:

Note

Actually the data structure is more properly called a Hash, or an Associative Array.

But what happens to this data when the controller receives it? And how can we actually USE this data?

Rails can only use objects to talk to the database, so before an ad can be saved to the database, you need to find some way to convert the form data into an Ad object.

The model can create objects from raw form data

How do you do that? Well, remember when you created a new blank Ad object to use with the form?

The Ad.new method can also be called with a set of hash table of values that will be used to initialize the attributes of the new Ad object. And the form data just happens to be contained in a hash object:

The whole reason for converting the form data into an object was so you could save it.

How do you do that? With

@ad.save

When save is called on the model object, Rails inspects the attributes and generates a SQL insert statement to update the database:

With the save in place, the controller’s create method is complete:

def create
       @ad=Ad.new(params[:ad])
       @ad.save
end

Test Drive

Update your controller’s create method, and try out the updated ad creation form. When you click Create, an error page is sent back complaining about a missing template:

Rails was complaining because it had no way of generating a RESPONSE to your request

HTTP works using pairs of requests and responses. For every request, there’s got to be a response.

When the controller’s create method completed, a new record was created successfully. Then Rails needed to generate a response page, so it looked for the page template that matched the current action. The current action was create so it looked for create.html.erb. But that template doesn’t exist!

So we need to write a create.html.erb page template. But what should the template have in it?

Exercise

Create a create.html.erb file to tell users that the record has been created and provide a link to the new record.

Exercise Solution

You should have created a create.html.erb file to confirm that the record’s been created and to provide a link to the new record.

Test Drive

Now that you have the create.html.erb page template in place, it’s time to try out the application.

Soon the users have posted dozens of new ads. But even though it’s really popular, some people have one small complaint...

Brain Power

Is there a problem showing a link to the new ad in the create page?

If so, what is it?

The users don’t want to see the intervening confirmation page generated by create.html.erb. They just want to go straight to their ad. So what do you do?

You could edit the create.html.erb page template so that it displays all of the new ad’s details, right? After all, the @ad variable is visible from the page template and it contains all of the details of the new ad.

But that would be a bad idea. Why? Because that would mean that the create.html.erb page would be exactly the same as the show.html.erb page template you use to display each ad.

That’s duplication, and it would mean you had more code to maintain in the future. It would be much better if the create action in the controller can choose to display the show.html.erb page.

A controller method works together with a template to form an action. In all of the examples you’ve seen so far, both the controller method and the page template have been exclusively used for one action.

That’s why the controller methods and the page templates have included the action name somehow. When you were performing a show action, you used the show method in the ad controller and the show.html.erb page template.

And we still want to use a controller method and a page template to complete the action, but now we want to be able to choose which page template gets called with the controller.

We need a way for the controller to say that the output is found at a different URL.

A redirect is a special kind of response from the Rails application to the browser. A redirect tells the browser to go to a different URL for output. So even though the browser sent the form data to /ads/create, a redirect sends the browser to ads/17 (for example, if 17 is the id number of the new ad).

def create
  @ad = Ad.new(params[:ad])
  @ad.save
  redirect_to "/.........../#{...........}"
end

Sharpen your pencil Solution

The redirect command will forward the browser to the URL of the new ad. Fill in the URL:

Test Drive

Go ahead and update your controller. Now it’s time to see if our redirect sends users to their newly created ads:

When a new ad is created the browser automatically jumps to the new page.

Some users have made mistakes in their ad creations, and want to make changes to their ads. So they want more than just display and creation forms. Users now want to be able to edit their ads.

This means the system need to allow updates as well as inserts. Will that be difficult to do?

Even though the system can’t currently edit ads, will it be a lot of work to add an editing feature?

Think for a moment about the sequence the system goes through to insert an ad into the system:

Suppose you want to change a page. What would you expect to see? Maybe a form with the ad details that you can re-submit and have the changes saved, which is kind of the same sequence you used to create ads. Let’s look at the change sequence in more detail...

When someone edits an ad, they’ll use a form just like before. The user will change the details and the ad data will be saved. So just how similar is the change sequence to the creation sequence?

You can see that the sequence between the two operations barely differs at all. In the creation sequence, a new ad object is created and saved to the database. In the change sequence an existing ad is read, updated, and saved to the database.

So you need to make sure you take the differences between the two operations into account. You’ll need to keep track of things like the ad id number in the change sequence.

Do you think you could add an edit feature to the application as it stands?

Long Exercise

Add an edit link on each show page to a URL (like ads/17/edit) that calls a new edit action to look up the ad and display it in a form.

The form will submit its data to an action called update at a URL like /ads/17/update. Create the routes that would connect /ads/17/edit to the edit page and /ads/17/update to the update action, making sure the ad id number is stored in a request parameter called :id in each case.

Note

Write the two routes here.

______________________________________________________________

______________________________________________________________

Now create a new page template, edit.html.erb, to allow the user to edit the ad details. It’s similar to new.html.erb except it displays the ad’s name in the page heading and it will use the ‘update’ action instead of the ‘create’ action.

Note

Write the edit.html.erb code here.

You’ll need two action methods in the ad controller to provide data to the editing form and also to update the ad in the database. The edit method will provide data to the edit form, and the update method will update the database. Given that:

—will update the @ad object on the database, write the code for the edit and update methods of the ad controller below:

______________________________	_______________________________
______________________________ Note Write the edit method here.	_______________________________ Note Write the update method here.
______________________________	_______________________________
______________________________	_______________________________
______________________________	_______________________________

Long Exercise Solution

Your job was to add an edit link on each show page to a URL (like ads/17/edit) that calls a new edit action to look up the ad and display it in a form.

The form submits its data to an action called update at a URL like /ads/17/update. So you should have created the routes that would connect /ads/17/edit to the edit page and /ads/17/update to the update action, making sure the ad id number is stored in a request parameter called :id in each case:

Your job was to create a new page template edit.html.erb to allow the user to edit the ad details. It’s similar to new.html.erb except it displays the ad’s name in the page heading and it will use the ‘update’ action instead of the ‘create’ action:

<h1>Editing <%= @ad.name %></h1>
<% form_for(@ad,:url=>{:action=>'update'}) do |f| %>
  <p><b>Name</b><br /><%= f.text_field :name %></p>
  <p><b>Description</b><br /><%= f.text_area :description %></p>
  <p><b>Price</b><br /><%= f.text_field :price %></p>
  <p><b>Seller</b><br /><%= f.text_field :seller_id %></p>
  <p><b>Email</b><br /><%= f.text_field :email %></p>
  <p><b>Img url</b><br /><%= f.text_field :img_url %></p>
  <p><%= f.submit "Update" %></p>
<% end %>

Note

Don’t worry if you didn’t get everything right in this exercise. It was a pretty tough one. But read through the answers and check that you understand what’s going on.

You need two action methods in the ad controller to provide data to the editing form and also to update the ad on the database. The edit method provides data to the edit form, and the update method updates the database. So given that:

@ad.update_attributes(__params[:ad]__)

—updates the @ad object on the database, you wrote the code for the edit and update methods of the ad controller:

Test Drive

The edit.html.erb page template is in place, as well as the routes and the additional methods in the ad controller. So now it’s time to test the new editing feature:

The code’s in place and the editing feature works. So we’re done... right?

The application can now create and update data. But that means anyone who can create an ad can update all ads. And that’s a problem.

The MeBay owners want anyone to be able to create ads, but they don’t want everybody else to be able to change the ad once it’s been posted.

One way of preventing just anyone changing ads is to protect the update function with a username and password.

The guys at MeBay have decided that only system administrators will be able to change ads. So they want the new update functionality secured with an admin username and password.

Fortunately, Rails makes it really easy to drop security right in. We’re going to use a special kind of web security called HTTP Authentication. This is the kind of security that pops up a dialog box and asks for a username and password when someone tries to enter a secure area of a web site.

Ready Bake Sign-In Code

To add login security to the application, you need to add two pieces of code to the ad controller: a login method that checks a username and password, and a filter that calls the login method whenever certain methods in the controller are accessed:

Test Drive

Now that the security code is in place, it’s time to open up your browser and try to edit an ad.

Now only people who know the admin username and password can edit ads on the site. Nobody else can get at the edit page or the update function.

Is it important to secure both the page and the update function? The edit page should be off limits to prevent people accidentally accessing it and wasting their time entering data. Not only that, but the update function (the code that does the actual database update) also needs to be secure in case a hacker tries to access it directly without using the edit form.

You’ve manually built a system that can create, read, and update ads... and is secure!

The site is up and running, and everything’s going great, but after not too long there’s a problem: even after stuff gets sold, the ads stay there.

MeBay could use their own data entry systems to remove ads from the site, but they were so impressed by how simple the change function was, they’d like you to add a delete function to the website.

The feature will only be available to MeBay administrators, so they want the same security that was applied to the change functionality. Also, because there’s been a ton of spam as well as some spoof ads posted onto the site, they’d like to make the delete function easily available from the index page. That way they can remove inappropriate content with a single click.

Let’s look at what we need to do...

Long Exercise

Update index.html.erb to add a delete link next to each ad. If the ad has id = 17, then link to /ads/17/delete.

Create a route that will connect paths like /ads/17/delete to an action called destroy in the ad controller. Remember to record the id number as a request parameter.

______________________________________________________________

Note

Write the route here.

Complete the ad controller code to delete an ad and send the user’s browser back to the index listing all the remaining ads.

To do this you will need to use a method we have not seen yet—the “destroy” method. This will delete an ad object from the database.

Long Exercise Solution

You should have updated index.html.erb to add a delete link next to each ad.

You also should have created a route that connects paths like /ads/17/delete to an action called destroy in the ad controller. Record the id number as a request parameter:

Your job here was to complete the ad controller code to delete an ad and send the user’s browser back to the index listing all the remaining ads:

Test Drive

The destroy action means users can delete ads from the site with a single click. It uses the same security as the amend feature, so before anyone can delete an ad, they must first prove that they’re an administrator.

Now that the system can delete ads, your application can perform all of the basic CRUD operations:

But then, so could scaffolding... so why write your own code?

You can choose what functions are available.

You can add additional features like security.

And now you understand how to create code that inserts, updates and deletes data, you’ll be able to amend the code that scaffolding generates.

You’ve got Chapter 3 under your belt, and now you’ve added the ability to manually create applications that can insert, update and delete data.