Habit Log is a basic (Create Read Update Delete apps) CRUD application.
I came to this pretty exited since it would be the first time I would be putting both areas, the design and coding, of what a database is together. From previous experience I got a piece of paper and started to draw out the database design. Shortly after I thought, that is all? Three tables?
The rest of the time I spent it coding these tables out. I took the advice of an instructor and started by creating the basic file structure and then onto my models.
Once I got my models working, I wanted to use one of the gems that was covered, Tux, to make sure my relationships were working. This is the step that helped me clear out some of the confusion that I had about Active Record, Ruby and SQL. It had all started to become “one language”. The model diagram has a foreign key constraint and I went to robots.thoughtbot.com for a reference in how to declare them in the code.
For example the methods find, find_by, update were some that I started to think they were Ruby methods. Then we also have Order and Sort, you can get the same result by using either of those two but one is an Active Record method and the other one in a SQL command. This became clearer when I started to create commands using Tux and seeing the output on the terminal which displays the SQL commands.
As I moved along in the application I kept dropping, clearing out my tables and restarting the database. So I just kept the text open on another file so I could just copy and paste it.
rm db/*.sqlite; bundle exec rake db:migrate ; bundle exec rake db:migrate SINATRA_ENV=test ;
As this process moved along I also discovered that the manipulation of the migration file occurs more often than I originally though.
From here on out, it was important for me to keep the controllers with the items that only interacted with the corresponding views and models. It became a bit like a checklist. I have a Get in this controller, do I also have the corresponding Post, Patch or Delete ones on here.
Brief note: The erb’s determine the file path and the path after the action are our URLs.
One of the forms has a boolean value to allow the user to check if they had completed the task or not. When the box is checked it sets it to True, but if left empty it sets it to nil. This was giving me the standard undeclared method error so with some reading I found out that you can set default values on the checkboxes aswell. In order to fix this bug I set the default value to false to avoid the error. This is documented in the API Dock website.
On that same form I have a date field in which I want it to display in a certain format when the user views their habits. By default the date is displayed in year, month and day. I wanted it to display as Day of the Week, Month, and Day of Month. This is done by adding html tag options on the user model, under the date attribute.
The part that took me a bit to figure out and get it to work was the Flash Message to validate the information being submitted through the forms. There was a reference on one of the labs for Flatiron about it, but in order for me to get it to work and figure out why it was not working I went to look through the Ruby guides. HERE
The lab mentioned the use of :message, but for this I chose to use :notice. I also created a separate method and placed it in the Application Controller for easy access.
Now flash_error is the method that I have to type in when I want to tell the user that there has been an authentication error in one of the form fields. The way that the code was described in my research it will produce the specific error that occured in the code.
This way the user will know what they need to make sure is filled in.
flash[:notice] = model.errors.full_messages.join(“, “)
Lesson learned from all of this. The By now, I have definitely learned that I need to start reading the official docs of Ruby. I did a lot of reading on the Active Record Part for this Sinatra app.
It is not a secure website.