Bringing It All Together

So far, we have seen how to use controllers, views, and models in a somewhat detached manner. In the previous chapter (Models, Databases, and Active Record), we manipulated data on our database. However, we didn’t see how to interact with the database data from our controller, much less how to load that database data into our view. In this chapter, we are going to see how everything comes together – that is, we’ll load a model from the controller and pass the model data to our view so that the end user will see data on the browser. We will also do the reverse, which is getting data from the user into our database, starting from the view and ending on the model. Furthermore, we will also learn the Rails way to perform these actions, as they are quite different from the way we would do these tasks in PHP.

With models, views, and controllers in mind, in this chapter, we will cover the following topics:

• Setting up our initial application...

Technical requirements

To follow along this chapter, we will need the following:

• Any IDE to view/edit code (e.g., SublimeText, Visual Studio Code, Notepad++ Vim, Emacs, etc.)
• For macOS users, you will also need to have Xcode Command Line Tools installed
• Ruby version 3.1.1 or later installed and ready to use
• A Git client installed on your local machine

The code presented in this chapter is available at https://github.com/PacktPublishing/From-PHP-to-Ruby-on-Rails/.

Project preparation

Prior to setting up our application, we are going to do some additional configuration, depending on the operating system. We will separate the configuration into two sections – Windows configuration and Linux-based systems (including macOS).

Windows configuration

In Chapter 7, we configured our Windows environment to use rbenv to be able to use Ruby 2.6.10. If you haven’t done so, please go back to the Installing Ruby on Rails in Windows section, as this is required for this chapter. For Rails 7 (which we will install in this chapter), we will require Ruby 3.1.1 installed and some dependencies that aren’t easily available for Windows. We will use the Git SDK’s bash shell (which we also installed in Chapter 7) to solve this issue. So, let’s open a Windows PowerShell and type the following command:

C:\git-sdk-64\git-bash.exe

This will open a Git Bash console, which looks and behaves a lot like a Linux shell. Let’...

Setting up our application

For this exercise, we will have a hypothetical scenario in which we are Thomas A. Anderson, and we work for a respectable software company. We will play the part of a junior web developer in terms of our knowledge of Rails, and we will be assigned a simple task. The client has requested a simple address book structure where they can save their friends’ contact information – name, last name, email, and phone number. So, let’s get to work. Make sure you have Ruby version 3.1.1 or above installed, or we might encounter issues with the project. We could download a template application that we already have or clone it from GitHub. In case you haven’t done so, open a terminal and type the following git command:

git clone https://github.com/PacktPublishing/From-PHP-to-Ruby-on-Rails.git

If you’ve already done so, just navigate into the chapter09/rails7_original folder inside our project with the following command:

cd From...

Processing data

Up until this point, we’ve manually modified data within the database. By manually, I mean all inside the Rails console. However, as our project requirement is to let the users handle the friends entries, we will do so by integrating our model with our controller and our view so that a user can see the friends entries in a friendly interface. We will be creating a CRUD interface. Yes, it sounds ugly, but it’s the acronym software engineers came up with. It stands for CReate Update Delete, which is exactly what we are going to build – an interface to create, update, and delete records.

Setting up the CRUD interface

The first step is to confirm that the data is, in fact, in our database. From our previous chapter, we know that we can call the Rails console for this, so let’s do that by running the following command:

bundle exec rails console

This should change our shell to look like this:

Loading development environment (Rails...

Do not, I repeat, do not repeat yourself

If you’ve worked with frameworks in the past, you may be familiar with the Don’t Repeat Yourself (DRY) principle, even though the principle is more focused on coding and coding style. If you’re not, or just need a reminder, the DRY principle simply states that you should not repeat yourself.

You can find out more details here:

https://docs.getdbt.com/terms/dry

As much as we possibly can, we should try not to repeat our code. As an example in this application, we repeated the code on the edit and new views. Using the DRY principle, we should refactor our code so that it uses the same form for both actions. In the same manner, instead of building everything on your own and from scratch, you should reuse functions, tools, and even libraries altogether. One task that we as developers have done over and over is to authenticate users. If you have an authentication code that works, you may have even copied it from a previous...

Summary

Wow! We covered a lot of ground in this chapter. We learned how to load data from a model to a controller to finally show data on the view. We also learned how to interact with forms and impact the database with the MVC architecture of Rails. Last but not least, we learned how to integrate the Devise gem with our application to leverage our authentication mechanism, instead of building one from scratch.

Now, we are ready for our last chapter, where we’ll explore some additional information regarding hosting our Rails application on a server.