25
Building an Event Landing Page Management System
I was inspired to build this when I was tasked with repeatedly hand-coding landing pages in simple html. This was inefficient in terms of time spent and meant I was the only person around able to maintain the pages or make any changes. I set out to create a proof-of-concept / MVP event page builder. It has nearly all the entities I need to build those hand-coded pages.
This is the backend for a simple proof-of-concept event page creator. It is designed to let you build events with:
Before I built out the migrations for the database, I sat down and planned the data structure. Below is a diagram of the different tables in the application's database and their relationships to one another.

Before I started building out the front end of the application, I knew I needed data to work with. Having real-looking data helps in the design process, and using Faker means you don't need to build out your database by hand.
Faker has a large number of different generators you can use to make your data more realistic or even if you just want to get a little more creative. I used and would recommend the:
Faker has a large number of different generators you can use to make your data more realistic or even if you just want to get a little more creative. I used and would recommend the:
All of these together helped me create reasonable placeholder data, which you can see in the demo video.
When I started building the interface for the app, I realized that deleting certain entities, like events or panels, could leave orphaned records. These were records that could not logically exist independently of their parent entities - especially the linking records between the panels and panelists and events and sponsors. I didn't want this, since orphaned records are just taking up space, at best, and could cause unexpected behavior at worst.
I solved this problem by setting the
dependent: :destroy
option on some of my models' associations.class Panel < ActiveRecord::Base
belongs_to :event
has_many :panel_panelists, dependent: :destroy
has_many :panelists, through: :panel_panelists
has_many :panel_sponsors, dependent: :destroy
has_many :sponsors, through: :panel_sponsors
end
Take the
Panel
class as an example. A panel belongs to an event, and has many panelists and sponsors through linking models. When a panel is deleted, the panelists and sponsors should remain, since they can be associated with many panels. The linking records, panel_panelists
and panel_sponsors
are unique to the panel being deleted. With dependent: :destroy
, those records are deleted along with the panel.Thanks for reading! For a walkthrough, take a look at the demo video.
25