I've built a simple web application, coined "Virtual Passport," that has a variety of features building an interactive user experience. A user is able to create an account or log in, and then add, edit, or delete their own entries, where an entry contains the name of a country they have visited, the dates visited, any "must-see" locations, and a short description of their trip. While anyone logged-in can view all of the countries listed in the database, only logged-in users are able to add, edit, and delete information. Any user is able to see the descriptions and other posted data listed with the entries. Each user has the option to view only their own entries by navigating to their unique profile, too.
Designing the Virtual Passport from a back-end standpoint was not so much difficult as it was informative. Having built out the various models, views, and controllers using conventional Sinatra and Ruby syntaxes like "RESTful Routes" (an architectural structure in software), I am better able to see how these pieces fit together. At first, the concept of a "get request" somehow taking a user to a form and "post request" followed by a redirect so the user is seeing something in the browser that makes sense, all sounded daunting. Below, I am showing how the way this works actually has a logical flow that is used over and over in our daily lives on the internet.
Using the above as an example, we have two requests. These two requests are dictating the way in which an entry is edited by a user (provided the associated models and views are also setup correctly). These requests represent that "logical flow" I mentioned earlier. Here, the get request first validates that a user is logged in, then defines what a country is to the program-- as an instance variable-- so that I can access that entity in the view for the request. The request then assures the specific country being accessed can be accessed by the logged-in user and is concluded with the directions to the edit form.
This takes us to the patch request. The patch request is the route taken once the user clicks "submit," or the equivalent, after editing the entry. The request defines again how to identify the entry, which is by its unique "id," while also authenticating the user. Then, I am using ActiveRecord's "update" method to not only update the record based on the newly input information, but also save the information. Saving the information is not only important for the current user experience, but more so for the future user experience; by saving the input, I mean persisting the data to the database at the root of the program. This ensures the user will see the data presently, and also in the future when they revisit and build on their profile. Finally, the application will redirect the user to the updated page for that specific entry. Seems logical, right?
Luckily, others agree. The way these routes are written and the order in which they are written are all intentional and follow "RESTful" conventions I previously mentioned. This simply means that the routes follow a convention acknowledged by developers that also makes sense for the flow of the program as it navigates through the respective requests.
It is exciting to see an application of my own on in a browser. I chose the virtual passport concept based on my own love for travel and passion for new experiences, but also my own enjoyment in documenting them. In the future, I may revisit this application to add input fields for photos a user may add from their trip, or at some point I could add the ability to link users together that may have gone on a trip together so there is a more shareable experience.
Below I have linked the repository for this project:
https://github.com/katiekatiekatiee/Sinatra-Passport-Project
Top comments (0)