Ruby on Rails

A dedicated Rails Controller with custom actions for your public static pages

Have all your public static pages in one place?
A dedicated Rails Controller with custom actions for your public static pages
In: Ruby on Rails

In the last article about public static pages, we've seen the brute force approach of creating very static public pages in Rails: Just put them into the app/assets/public folder, together with your error pages, and link to them from the routes.

But what if you want to add a little tiny chunk of dynamicity to your page, and for example show
off a small sample of resources to users who haven't signed up to your page yet? Or you just want all the nice Rails helpers to be available on your "static" page.

Also, most probably you aren't a designer or you just don't have much time for creating a fresh new design for your static page. You just want to reuse your app's layout.

The challenge with public pages is that they are a kind of business and domain logic. And if you have worked with Rails before just a little, you'll know that Rails doesn't care about your feelings and business logic. It's for you to decide how to model and where to put it.

So naturally, there are tons of approaches and different places how to structure your business logic.

There are 2 major approaches:

  1. Create a public/static pages controller
  2. Make your public page a resource

In this article, we'll look at the most common one: Creating a public page controller.

Let's assume you have created an app that allows users to learn memory techniques. In this scenario, you might benefit from having a controller like that:

# public_pages_controller.rb
class PublicPagesController
  def home
    # Your fancy /home page might not be doing anything, or it might actually
    # let users subscribe for a newsletter or updates about your upcoming
    # product:  

  def about
    # Your /about page might be super boring and static describing you and
    # your team...

  def memory_palace_technique
    # Here you explain to your users what a memory palace is and how they can
    # create some in your app with an example:

  def memory_major_system_technique
    # Another feature of your app might be to list a different memory technique.
    # In this case you showcase a sample of a different resource:
    Peg.where(type: "original", language: params["language"]).first

With that you can just link to your pages from the routes like this:

# routes.rb
Rails.application.routes.draw do
  # Admin routes.
  # ...
  # Logged in user routes.
  # ...
  # Public routes.  
  root 'pages#home'
  get '/about', to: 'public_pages#about'
  get '/contact', to: 'public_pages#memory_palace_technique'
  get '/help', to: 'public_pages#memory_major_system_technique'
  # ... More static pages like ToC and privacy pages ...

That's it. Just add your .html.erb views in the respective folder with the right name and you are done.

This looks like having all the static pages in one place, but it can create a bit of a design challenge once you start doing these dynamic things and start displaying samples based on some user input (which is not super static anymore, but it's public, and your "static" pages might evolve into something more alive and interactive).

In this case, trying to think of your public static pages as resources can improve your overall design and lead to better solutions. You will see this in action in the next article, where I will show you which design challenges I ran into and the advice I took that made the whole setup much nicer.

More from RichStone Input Output
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to RichStone Input Output.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.