Trivialities of Trivia — On the Construction of a Content Management System using Ruby
Most people who know me well would say that I retain knowledge on some of the most useless of topics. Who exactly needs to know that the funny bone is not really a bone at all, but a nerve? Perhaps you, dear reader, did not know that the hash symbol (“#”, occasionally referred to in Twitter-tainted minds as a hashtag) is actually called an octothorpe. If you are an avid poker fan, you might be disheartened to hear that the odds of achieving a royal flush are precisely one in 649,740.
But then, some bits of information that we learn every day are not things which we are proud to learn of that day, but wished we had learned many years earlier. 7% of Americans, for example, still believe that chocolate milk comes from brown cows. (If you are one of these people, you are gravely mistaken.)
I could go on — there are many things in this world that you and I shall never know — but this is the inspiration behind my second project with Flatiron School, the so-called Brain Bank.
The premise is fairly simple: the user is encouraged to jot down any thing, major or minor, every day so as to keep track of the little things that they learn every day. They can choose to share this with the world, or they can choose to withhold it, their (perhaps embarrassing) newly-learned knowledge stored away in their posts privately and inaccessible to the public. The choice is theirs!
Now for the technical stuff.
As the title implies, Ruby is the language under which most things are controlled: what is displayed on the Feed, establishing sessions so that the browser knows, and the underlying code knows, who is looking at what.
When viewing any website, we have four different levels to consider: the Views, which are what appear before the user in HTML format; the Controllers, which go back and forth between the requests made from views and the instructions towards the Models; the Models which communicate with a database and instruct the database to modify itself or retrieve data to send back to the controller; and the Database containing all raw information pertaining to the site, such as its users, their posts, passwords, and so on. The Model-View-Controller (MVC) design pattern is necessary in all websites which handle data to any degree, establishing a chain of command right from the top, where the user sits and interacts, right down to the nitty gritty data.
The views are stored in a file with a filetype .erb which, after some necessary conditional changes with Ruby, ultimately displays the HTML which is passed to the browser that the user can see. The Controllers are entirely powered by Ruby, on the other hand, but draw heavily from the Sinatra web application library such that GET and POST requests are handled simply and effectively. The Models speak the language of the database, and must therefore inherit their characteristics from Active Record. Fortunately, this allows our Models to speak the language of the database without ever really having to delve into the SQL required to interact with it.
As I mentioned earlier, a user is able to make public and private posts. These private posts in particular should not show up in any other user’s feed, and they certainly should not appear when a user views another user’s profile to see what they have posted. Obviously, if a user selects for a post to be private, we do want that user to see their own post. So how do we do this?
Let’s begin at the beginning. Each user has a hidden id, a name and username, an email, and a password which is hashed through bcrypt, preventing even the database from knowing what the user’s password is. Most importantly, a user has many posts, and these posts hold data such as the date they were authored, whether or not the post is public or not (a Boolean parameter) and, of course, the content of the post itself. The aforementioned Boolean parameter, named is_public, is set to “t” if the checkbox for making a post public is checked, and “f” vice versa. When a user logs in successfully, their user id is stored into the session, and so certain rights and privileges may be granted to that user, such as viewing their own private posts.
So, back to the problem.
When a user looks at another user’s posts, they want to see every post that they have authored except private posts. If a user is looking at their own profile, they want to see every post they have authored, even private posts.
There are two things at play here: our is_public parameter, and our user’s id, also known in this case as the session id. How do we know that a user is viewing their own account?
When we request to see a profile, an instance variable in Ruby named @user finds the user associated with the username to which the user has navigated, whether it is their own profile or another’s profile. In this .erb file itself, there is a bit of logic to determine whether to display public or private posts when considering whose profile that user is viewing.
Consider our is_public and session id parameters in the following cases:
- If the post is public and the post’s author is viewing the page, then show the post.
- If the post is public and not the post’s author is viewing the page, then show the post.
- If the post is private and the post’s author is viewing the page, then show the post.
- If the post is private and not the post’s author is viewing page, then do not show the post.
So, there is only one case where we do not want to show the post. This sort of pseudo truth table helped me to isolate this lone case, and thus the Ruby code reads:
if !post[:is_public] && !(@user.posts.first.user_id == session[:id]) then else [information pertaining to post] end
In other words, if the post is not public AND the profile’s user’s id is not the same as the session id, then absolutely nothing. Else, display everything there is to see. Problem solved!
