DEV Community: Artur

Construction report: we prepare the controller to create and edit the user

Artur — Fri, 23 Apr 2021 19:58:08 +0000

I'm already lost as to which post is this. Today a short episode with two actions: login and registration. In this post we extended the functionality of the default user devise controllers, today we will add some code to them.

One step at a time, we'll start by editing the user registration controller. First, we need to tell our application that we have slightly modified the user model and need different data for registration than the default required. So we add at the beginning of our controller two magic lines that influence what parameters will be required from us by the registration and login form.

class Users::RegistrationsController < Devise::RegistrationsController
  before_action :configure_sign_up_params, only: [:create]
  before_action :configure_account_update_params, only: [:update]

At this point, we have told our controller that we want to override the default devise actions for the update and create methods. So we need to add two functions:

def configure_sign_up_params
    devise_parameter_sanitizer.permit(:sign_up, keys: [:email, :name, :surname, :password, :password_confirmation, :role])
  end

  def configure_account_update_params
    case current_user.role
    when 'trainee'
      trainee_attributes = [:weight, :height, :date_of_birth]
      keys = [:email, :name, :surname, :role, trainee_attributes: trainee_attributes]
    when 'trainer'
      keys = [:email, :name, :surname, :role, trainer_attributes: [:description]]
    end

    devise_parameter_sanitizer.permit(:account_update, keys: keys)
  end

Both define what fields we want to edit in the form, but it is immediately noticeable that the update function is much more powerful. Why?
While creating a new user requires the same data, regardless of the role, editing looks a little different. The trainee can change his weight or height - this is important for the trainer, and the trainer can change his description - this is important for the trainee. Therefore we have to, depending on the role of the user, require different values in the edit form.

The first subscribers are on their way. They don't know what they're getting into yet.

We still need to distinguish which layout to use for these two actions - we need a different one for logging in and another for editing data where the user is already logged into the application. So we add at the beginning of the controller, after the above two lines with before_action

layout :resolve_layout

And after the two methods written earlier, we add one more

  def resolve_layout
    case action_name
    when 'edit'
      'dashboard'
    else
      'application'
    end
  end

We will develop these features later, but for now we are satisfied with this state.

In Poland we don't say 'well done'. We say 'gra gitara' and I think it's beautiful. The controller we have prepared, in its entirety should look roughly like this:

class Users::RegistrationsController < Devise::RegistrationsController
  before_action :configure_sign_up_params, only: [:create]
  before_action :configure_account_update_params, only: [:update]

  layout :resolve_layout

  def create
    super do
      case current_user.role
      when 'trainee'
        trainee = Trainee.new(user_id: current_user.id)
        trainee.save
      when 'trainer'
        trainer = Trainer.new(user_id: current_user.id)
        trainer.save
      end
    end
  end

  protected

  def configure_sign_up_params
    devise_parameter_sanitizer.permit(:sign_up, keys: [:email, :name, :surname, :password, :password_confirmation, :role])
  end

  def configure_account_update_params
    case current_user.role
    when 'trainee'
      trainee_attributes = [:weight, :height, :date_of_birth]
      keys = [:email, :name, :surname, :role, trainee_attributes: trainee_attributes]
    when 'trainer'
      keys = [:email, :name, :surname, :role, trainer_attributes: [:description]]
    end

    devise_parameter_sanitizer.permit(:account_update, keys: keys)
  end

  def resolve_layout
    case action_name
    when 'edit'
      'dashboard'
    else
      'application'
    end
  end
end

In the next post we will crate views for these two methods-create and edit user, and install tailwindcss.

Cover photo: It's late, Luna's asleep

Construction report: we create tables for trainers and trainees

Artur — Thu, 22 Apr 2021 17:19:02 +0000

Third post and 5 followers, please contact with collaboration proposals for influencers on priv.

Today a continuation of an earlier post, we will add a model and database tables for trainer and trainees. The assumption is that these two roles will have separate tables, where after registration a new record will be added with a foreign key referring to the users table.

Here we go!
The console our best friend, so we type:

rails g model trainer

which generates two files containing the model and the migration with the new table. We are going to edit the migration file, which is similarly named: 20210425185512_create_trainers.rb

class CreateTrainers < ActiveRecord::Migration[6.1]
  def change
    create_table :trainers do |t|
      t.references :user, index: true, foreign_key: true
      t.string :description
      t.timestamps
    end
  end
end

A few words about what magic has just happened here. The first field is actually a foreign key to the users table. We are extending this table in a 1:1 relation. Then we have a text field in which the trainer can describe their activity. Timestamp is generated by default by rails CLI. Amazing, isn't it?

We already have trainers, we can slowly think about a marketing campaign. Now it is time for the trainees. The wonders that happen here will stay in your memory for a long time. Of course, the console:

rails g model trainee

Open the migration file (20210425185842_create_trainees.rb) and write:

class CreateTrainees < ActiveRecord::Migration[6.1]
  def change
    create_table :trainees do |t|
      t.references :user, index: true, foreign_key: true
      t.references :trainer, index: false, foreign_key: true
      t.integer :weight
      t.integer :height
      t.date :date_of_birth
      t.timestamps
    end
  end
end

Here we are already rubbing up against machine learning, artificial intelligence and interplanetary expeditions. A brief explanation so as not to get lost. The first item, as with the coach, is a reference to the user table. Next we have references, this time to the trainers array, with which we have a many-to-one relation - one trainee has one coach, but one trainer has many trainees. Then we have two fields with weight and height and another one with date of birth.

We have the migrations ready. Let's launch the rocket! In the console:

rake db:migrate

And it's done!
We will expand these tables later, but for now we want to run applications with basic functionality. Let's now move on to editing models. First up for editing is the trainer model, which for now will look more or less like this:

class Trainer < ApplicationRecord
  belongs_to :user

  has_many :trainees
end

In a nutshell, this class is just indicating to our application the relationship between the tables. We have almost the same thing in the trainee model:

class Trainee < ApplicationRecord
  belongs_to :user
  has_one :trainer
end

With little difference in the relation. The trainee has one trainer.

And what's in the next episode? We will create a login and registration form. Stay tuned!

Cover photo: Luna is crazy today and took my flip-flop!

Extending the default user devise

Artur — Wed, 21 Apr 2021 19:16:00 +0000

Blogging day two, as a seasoned blogger I had a full head of ideas for this post (which is about two, both of them bad). Welcome to my 3 faithful followers, welcome to all who have not yet joined this elite group. Today I might even be able to show some code. I warn you that after seeing this your therapist will need therapy himself.
And this is just the beginning.

Now seriously, first a few words about what I write: an app for personal trainers and their trainees. Arranging workouts, diets, etc. To make things clear, this is a commercial project for which I will be paid and the client has agreed to make the repository public, which you can find here: https://github.com/kubacky/FitHustle

For today's workshop, we will take an extension of the default rails devise with the user's name and roles. To use devises at all, we need to add a gem with them. This is not very complicated and is limited to adding one line in our gemfile

gem 'devise'

Then we need to run

bundle install
and

rails generate devise:install

in the console. It would also be useful to have devise views in our application, so:

bundle exec rails g devise:views

and finally:

rails generate devise User

We still need to migrate the changes generated by the above command

rake db:migrate

We got it!
To extend the default functionality we need to extend the available devise controllers, so in the console we quickly type:

rails generate devise:controllers users

and voilà. Almost the first coaches can arrange diets for their players. What's left is to extend the default user table with first name, last name and roles. The console is of course on standby at all times, so here we go:

rails g migration add_name_and_role_to_users name:string surname:string role:string

This will create a file in the folder: db/migration with a strange name like: 20210420195443_add_name_and role_to_users.rb

We can now preview this file, which should look like this:

class AddNameAndRoleToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :name, :string
    add_column :users, :surname, :string
    add_column :users, :role, :string
  end
end

And again in the console:

rake db:migrate

In the next post we will add the tables for trainers and trainees in the database ;)

Cover photo: Luna think she’s an ostrich

I am a construction site worker and I learn Rails

Artur — Mon, 19 Apr 2021 21:07:23 +0000

There are more blogs than you can imagine. About programming, about cooking, about cars, about travel. Give me some random topic and I'll find at least five blogs on it. People write about everything and nothing, several posts a day or one a month, with or without meaning, more or less, but they write. Since practically all topics in practically all fields are exhausted, why do I also decide to write another one among a million others, a blog about programming?

My goal for this year is to become a Ruby on Rails programmer, with this blog I want to document my progress with learning Rails.

What's so special about it? In the learning itself probably nothing, while what I do outside of learning I think is not an everyday occurrence. I'm a construction worker, I'm a paving and laying pipes every day, I work in trenches several meters long and with excavators several tons long (we dig those bitcoins, but we haven't found anything yet).

Will working in IT be something new for me? No. In Poland I worked for a few years, mainly as an administrator and as a freelancer I managed to write a few smaller or bigger applications, mainly in php + angular stack. So I have some experience as a programmer, but I have never worked in a team. I have an irresistible impression that I am stuck in so-called noobville from the beginning. I have superficial knowledge in a few areas, but I'm an expert in none.

The first post is just a hello and it won't be anything special, starting tomorrow I'll be adding more and more technical content.

PS. Cover photo: meet Luna, who will accompany me (and you) in learning Rails