Panic_Controller.rb

As my online part-time Software engineering course at Flatiron journey continues, I have now created a Sinatra web application. The focus of this project was an attempt at creating a basic medical practice doctor-patient management application.

I thought that after a few months of learning I wouldn’t feel like a novice, but this assignment taught me that I’ve barely scratched the surface.

Phase 2 of my course proved a grueling challenge with topics and techniques increasing in abstraction while introducing a more complex environment.

I’ll break down my project as follows…

Creation

Creating my first ever Sinatra web application was made easier by using the Corneal Gem. The creation of a former Flatiron student, this particular gem quickly builds the directory structure and file associations that serve as the foundation for any Sinatra project.

The directory structure is as follows…

Corneal Gem — Basic Directory Structure

The Corneal Gem is a powerful one that provides you with a good starting point. That said there were adjustments I needed to make in order to ensure the program carried with it the necessary features.

• Rack::MethodOverride was implemented through config.ru (‘use Rack::MethodOverride’) to enable the ability to run the PATCH and DELETE HTTP verbs.
• Seeds.rb file was created to ‘seed’ our app with test data to aid in development process.
• Migration files were created and migrated to create the various tables needed to manage data inputs into records, while allowing for basic and complex associations to be created.
• Sessions were enabled in order to provide a more secure application experience. This was done by “configuring” the sessions within application_controller.rb — the main controller from which all other apps inherit.

Now that we have refined the foundation provided by Corneal, we can begin to develop our models and views.

Code

Always map out your build before diving in!

The application was built using the Model-View-Controller (i.e. MVC) framework. It breaks down as follows…

Models — Doctor Class

• Models — Two models were created to enable the creation of doctor and patients instances. Using inherited features from ActiveRecord, we were also able to establish the doctor-to-patient relationship. Doctors have many patients and patients belong to doctors. Additionally, this is where validation statements were inserted to ensure only the right data was persisted to the database.

Views — Each controller has it’s own set of views (i.e. Application, Doctors, and Patients)

• Views — Three different groupings of views were created. One for each controller. The Doctors and Patients views specifically handle the user experience of the doctors and patients when registering, logging in, or viewing their profiles while the generic application controller views handle initial site navigation and launching.

Basic Application Controller setup enabling sessions and connecting views.

• Controllers — Three controllers were created to handle and control the user interactions with the application. The Application_Controller is responsible for launching the application and ensuring an authenticated registration and login flow. The Doctors_Controller is responsible for creating and persisting new instances of doctors while enabling views that allow doctors to manage their patients. Lastly, the Patients_Controller mimics the Doctors_Controller but limits the accessibility the patient has regarding editing and creating new records.

Check out DocPortal 2000 in action! Forgive the late night attire…sometimes that happens when you’re burning the midnight oil.

Check it out on Github!