What is the best way to approach a CMS?

I posted on a question with erb in SQL entries because I've been
building a CMS for my own website. I've built them before, but in
ColdFusion, and I'm not sure how best to approach it in Rails.

Right now, I have a simple database schema:

  create_table "comments", :force => true do |t|
    t.column "post_id", :integer
    t.column "created_at", :datetime
    t.column "comment", :text
  end

  create_table "events", :force => true do |t|
    t.column "title", :string
    t.column "desc", :text
  end

  create_table "pages", :force => true do |t|
    t.column "title", :string
    t.column "body", :text
  end

  create_table "posts", :force => true do |t|
    t.column "title", :string
    t.column "created_at", :datetime
    t.column "body", :text
  end

  create_table "users", :force => true do |t|
    t.column "name", :string
    t.column "hashed_password", :string
    t.column "salt", :string
  end

The trouble is with pages. Right now, I just have the page load its
title and its body, which contains HTML. My problem is I need to have
pages with different layouts--in particular layouts that use AJAX to
dynamically load content.

I'm starting to think that maybe I'm structuring this incorrectly.
I'm just not sure how else to approach structuring the content other
than SQL entries. Any suggestions as to how a) I can create different
layouts and b) get some layout functionality in my SQL entries?

For example, I'm looking into liquid. That looks promising. But its
starting to look unrealistic to load both the content and the layout
from a SQL entry.

Thoughts?

Ron

Ron wrote:

Right now, I have a simple database schema:

  create_table "comments", :force => true do |t|
    t.column "post_id", :integer
    t.column "created_at", :datetime
    t.column "comment", :text
  end

  create_table "events", :force => true do |t|
    t.column "title", :string
    t.column "desc", :text
  end

  create_table "pages", :force => true do |t|
    t.column "title", :string
    t.column "body", :text
  end

  create_table "posts", :force => true do |t|
    t.column "title", :string
    t.column "created_at", :datetime
    t.column "body", :text
  end

  create_table "users", :force => true do |t|
    t.column "name", :string
    t.column "hashed_password", :string
    t.column "salt", :string
  end

Ron

model Comment: check
model Event: check
model Post: check
model User: check
model Page: wtf???

Your architecture looks very sensible but i don't have the foggiest as
to why you would need the Page model.. Isn't the main reason you are
using rails is to create your pages dynamically? Does page refer to
something else? What is page needed for?

Hoping to provide further assistance or at least solve the "page"
mystery.. :slight_smile:

ilan

Well, Ilan post is for the blog page. The blog page is a separate
controller. The pages controller handles the pages, which are
basically database entries with a title and a body. I added the page
controller because I thought I wanted to have a dedicated controller
for the presentation part of the website. I created an admin
controller for editing the pages so I could put it behind a login.
The pages are generated dynamically, as the content is from the page's
SQL entry.

Does that make more sense?

Ron

So maybe the best way to approach it is to use posts as a general
catch all for text content. Then I could create a few different
templates and associate the page with one. It would then fill in the
appropriate content.

What do you think?

Ron

Ron wrote:

Well, Ilan post is for the blog page. The blog page is a separate
controller. The pages controller handles the pages, which are
basically database entries with a title and a body. I added the page
controller because I thought I wanted to have a dedicated controller
for the presentation part of the website. I created an admin
controller for editing the pages so I could put it behind a login.
The pages are generated dynamically, as the content is from the page's
SQL entry.

Does that make more sense?

Ron

On Mar 8, 12:57 pm, Ilan Berci <rails-mailing-l...@andreas-s.net>

Ohhh.. wait a sec, now I get it, you created the "Page" model as you
think you needed a Page controller. I think you are absolutely correct
that you should delegate out the functionality for the pages to a Page
controller but that doesn't mean you need to have a page model.. I
think that perhaps you are over engineering it a little.. Rails is very
adaptable to sudden design enhancements and modifications so I would
start very simple.. Probably something like this

1) User model
2) User controller
3) User views
4) User test cases
5) Post model
6) Post controller
7) Post views
8) Post unit test cases
9) Post functional test cases
10) Post/User integration testing
11) Comment model
12) Comment controller
13) Comment unit test cases
14) Comment functional test cases
15) Modify Post views to have comments attached
16) Integration for tests for point 15
etc..

There is no need to have a heavy up front design, you can just go ahead
like Dave Thomas suggests in his Agile book and build up your site
little by little. The test cases are really key as they will greatly
speed up your development and make your next steps in the design
painfully obvious.

My apologies if you already know all this stuff but it sounds like you
are coming from a more formal coding convention such as a rup, modified
rup, etc.. and rails is much better suited to agile development
practices..

hth

ilan