0

I'm more-so looking for a best practice. I'm working in a team on a rather large project. I'm doing the server side coding and someone else is doing the designing. We decided to do an in-house style CMS so someone else can make some changes to content, without changing the styling.

We need to add some new pages in to make more functionality to the site, but I'm looking for a best practice for doing this. Originally I thought about using the db:seed command, but that's more-so for loading initial data, rather than a new page. Now, I'm starting to think about using a migration file, but I think it's kind of bad practice to edit a migration file back and forth for changes to a CMS page.

Any thoughts for a best practice for editing static pages through a DB record between team members?

Allen
  • 794
  • 1
  • 6
  • 19

1 Answers1

0

For something like this, I usually create some classes in /lib to handle creating the necessary data if it doesn't exist. You can make sure the process is idempotent by doing something like this:

page = Page.find_or_create_by_name("blahdeblah")

where "name" is some unique identifier for a page.

Example:

class CreateSamplePages
  def execute
    page = Page.find_or_create_by_name("blahdeblah", content: "This is an entirely awesome sample page.")
    ... (more stuff here)
  end
end

Then in the rails console (rails c in your project root), you can do CreateSamplePages.new.execute

Josh Rieken
  • 2,256
  • 1
  • 19
  • 23
  • Seems a bit annoying, if you ask me, but maybe it's better than making a migration, in fact. I made it into a migration with the previous static pages, cause we were migrating static pages to database-backed pages, so, to me, it fit the bill there. And so if I follow your route, then I should create many classes or just change it every time when I want to add a new class? – Allen Jan 15 '13 at 09:05