DEV Community

loading...

Forms and Params!

stevea2c profile image Steven Stieglitz Updated on ・3 min read

During my Sinatra project, wherein I built a project to create a custom Among Us character (a separate blog post is available on this project), I came across the following issues which I will be addressing more thoroughly herein:

  1. Making a form and ensuring requests are structured properly; and
  2. The structure of params.

Making A Form

As for making the form, the attributes of the form allows the software engineer to customize how the request is sent once the user fills in the required fields and hits the submit button. The two most crucial attributes to use when creating a proper form is the action attribute and the method attribute.

Action Attribute

The action attribute defines where the information will be sent. For example, in my application, I give the user the ability to edit their character after it has been created through utilization of a form, with the following code:

<form action="/characters" method="post">
    <label style="color:white;"><i><b>Name</label>
    <input type="text" name="name">
Enter fullscreen mode Exit fullscreen mode

The form action attribute is stating that the URL that the data should be sent to is set to a base of localhost:9393/, then it is followed by characters. This allows for the data to be sent to the general index of all characters.

Method Attribute

With the understanding that the Action Attribute is what allows a software engineer to determine where the date will be sent, the Method Attribute determines how the data will be sent. It is important to note that there are five (5) basic HTTP verb (or methods), which are:

  1. Post;
  2. Get;
  3. Put;
  4. Patch;
  5. Delete.

The most common of these five methods are Get and Post, as the Get method is used to read a resource as opposed to permitting an alteration of any attribute in the database. Conversely, the Post method is generally used to create new resources.

It is important to understand how Get and Post work together, because the Get method, in my project, “gets” the form for the user to input information for the creation or editing of a new character, whereas the Post method will take the information that user “posts” and change the database accordingly.

Therefore, as shown through the above-referenced code snippet, the method is “post” because I am stating that this method should be posting this information to the database, not simply getting or rendering a form for the user to interact with. A get request is shown below:

        get '/characters' do
            require_login
            @characters = Character.all
            erb :'characters/index'
        end
Enter fullscreen mode Exit fullscreen mode

Params

Parameters (often shortened to “params”), which are heavily used in Sinatra Params, are a hash of key/value pairs coming from the browser and encoded in an HTTP request. There are two types of parameters possible in a web application, the first being parameters sent as part of the URL (“query string parameters”). The second type of parameter is referred as a Post data, generally coming from an HTML form which has been filled in by the user and can only be sent as part of an HTTP Post request.

The routes which I primarily used in my application specified a path with a symbol (colon), which alerts Sinatra that any input from the user will be accepted here (see the below code snippet where the :id is being accepted for the parameters of the character's id)

        get '/characters/:id' do
            require_login
            @character = Character.find_by(id: params[:id])
                if @character
                    erb :'characters/show'
                else
                    redirect '/characters'
                end     
        end
Enter fullscreen mode Exit fullscreen mode

Therefore, Sinatra will look for the key for :id and add it to the params hash, setting the string from the URL inputted by the user. Therefore, if the user goes to their localhost followed by "/characters/1", the Sinatra application will return the character with id of 1 (assuming that the user is permitted to view that character).

Another thing you should note is that the controller method defines the route a /characters/:id, which is a dynamic route. This is because the controller action has the :id parameter, which specifies that whenever a Get request is sent to the /characters path with an additional parameter, the parameter should be equal to the id key.

This is crucial for user interaction, because I could have simply rendered the show page of any character I so chose (‘/characters/15 or ‘/characters/3), but it would make for a terrible web application if I, as the software engineer, told the user what character they should be looking at. That is why the dynamic routing is so important, because it allows the user to look at the character that they want to by identifying the id of the character through the params.

I hope I have explained the above information clearly, but for more information please visit (https://webapps-for-beginners.rubymonstas.org/sinatra/params.html).

Discussion (0)

pic
Editor guide