Use CRUD where you need to use CRUD

Almost all web applications use CRUD (Create, Read, Update, and Delete) operations. You may find that most of your application's work is CRUD. Rails is aware of this and provides many features to simplify the code that implements CRUD.

Let's explore these possibilities by adding more functionality to our application.

7.1. Single article display

Now we have a view that displays all the articles in our database. Let's add a new view showing the title and content of a single article.

Let's start by adding a new route that points to a new controller action (which we'll also add later). Open config/routes.rb and paste the last route

Since we don't want to output the value returned by @articles.each, we've wrapped this code in <% %>. But since we want to output the value returned by article.title (for each article), we've wrapped this code in <%= %>.

The final result can be seen by visiting http://localhost:3000. (Remember, the bin/rails server must be running!) Here's what happens:

The browser will make a request: GET http://localhost:3000.

Our Rails application will receive this request.

The Rails router will bind the root route to the index action in the ArticlesController.

The index action uses the Article model to retrieve all articles from the database.

Rails will automatically render the app/views/articles/index.html.erb view.

The ERB code is calculated in view for HTML output.

The server will send a response containing HTML back to the browser.

We've put all the pieces of MVC together and now we have our first controller action! Next, we move on to the second action.

These methods are called when a migration is applied and rolled back respectively. The numbers 001 in the file name is the serial number of the migration, it is used to determine the order in which migrations are applied, while rails store its version in the database so as not to apply one migration several times. To migrate a database to a specific version, run db:migrate with the VERSION parameter:

<code>$>rake db:migrate VERSION=0</code>

As a result, the database migrates to the zero version, when no tables have yet been created using Ruby on Rails. This is a convenient way to clean up the database after experimenting with the application. Then you can call db:migrate again without parameters, as a result all migrations will be applied.

The directory is great, but the articles are not formatted.

I hope you have already looked at the catalog and made sure of this. Time to tackle the main task of the application - the formatting of articles.

We already have the code for formatting, now we need to understand how to use it. In the first version, we only had a controller, so the code was located directly in it, now there is an Article model, but if we place the code in a model, we will hard-wire the formatting to a specific model, and this will lead to the fact that we cannot reuse the code , although it does not depend on the model that it will format.

Rake is a replacement for utilities like make, ant, maven.

To find out what Rake can do for us, run the following:

<code class='sh' lang='sh'>$>rake -T</code>

We get a long list of tasks that Rake can do. Tasks are written in Ruby and reside in a Rakefile. Initially, the file contains only a standard set of tasks that are included using require 'tasks/rails'. For example, the description of the db:migrate task looks like this:

The beauty of Rake is that the task description is just plain Ruby-on-Rails code. This greatly simplifies adding new tasks compared to ant or maven.

Martin Fowler has a great article on Rake (in English).

We will get acquainted with Rake as needed. Now we already know that the db:migrate task runs migrations, and you can both apply and roll back changes. If we look in the db/migrate/001_create_articles.rb file, we will see that the CreateArticles class has two methods: up and down.