Jump to content

The ultimate community for Ruby on Rails developers.


Opinion needed on model(s) structure for content managing model

  • Please log in to reply
2 replies to this topic

#1 Sajonara



  • Members
  • 1 posts

Posted 26 August 2014 - 01:55 AM



I'd like to prepare an app managing content types at the admin side and showing them in the web at the user site, similar to a cms. Now I am not sure what's the most efficient and as well robust way to do so.


I have several ideas concerning the model(s) and it would be very nice if you could comment on them, because my knowledge on this things is scarce yet.


1) Create an articles model consisting of all possible fields the different article types (news, interviews, reviews etc.) could have, like headline, content, etc. I thought of booleans to mark the type of the article.


2) Create an articles model and several models for the different text types and set relations with belongs_to.


3) Create several models for the different article types and only share their content with a common self made controller and another model (in the future, maybe with a polymorphic association).


4) Follow a STI approach.


If I'm mistaken in any of these ideas, please correct me. I'm new to Rails. I only started learning and actively using it some one and a half months ago. In this time I read a lot, did some first steps at Codecademy and also have I been watching different screencasts like those Rails for Zombies.


Kind regards.

#2 Ohm



  • Moderators
  • 529 posts
  • LocationCopenhagen

Posted 26 August 2014 - 05:57 AM

I personally am not fond of the STI approach. There is a reason why the two types are not one. Why should they live in the database as one?


Then again, if they are similar in every way but the name, STI is the way to go, just be aware that using STI makes it harder to expand on. You lose flexibility. 

Blog: http://ohm.sh | Twitter: @madsohm | Work: Lokalebasen.dk

#3 saturnflyer



  • Members
  • 8 posts

Posted 15 April 2015 - 11:42 PM

I actually think that STI might be the way to go. If your model data will ever *not* be the same attributes among the different types, then storing them in the same table is a bad idea. If you merely need to change behavior then STI is great.

If the data is different for different types, then you should definitely not do STI.


As an alternative, you could just select an associated template/layout for each page. In other words, create the content for the page, and then select the way it will be displayed (review, interview, etc).

A model could know how to print it's attributes to a template and each template would display according to it's purpose.

I talked about some ideas related to that in this RubyConf presentation http://confreaks.tv/...gh-ruby-with-oo


It's not up to date with the latest Rails, but Radiant CMS handles pages basically as a URL plus page parts and it is displayed with a selected layout. Radiant also allows different page types.

Checkout my books: Clean Ruby and Ruby DSL Handbook

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users