# Semi-static Rails Page

**URL:** <https://www.ruby-forum.com/t/semi-static-rails-page/192817>\
**Category:** Rails\
**Created:** [August 6, 2010, 8:49am UTC](https://www.ruby-forum.com/t/semi-static-rails-page/192817 "2010-08-06T08:49:28Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![stephenallred](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@stephenallred](https://www.ruby-forum.com/u/stephenallred)\
**Post date:** [August 6, 2010, 8:49am UTC](https://www.ruby-forum.com/t/semi-static-rails-page/192817/1 "2010-08-06T08:49:28Z")

</div>

Hi,

I’m looking to have a static page with prose (like the Basecamp  
landing page) on my site and was wondering what was the most Rails way  
of doing it.

I’ve had a couple of ideas:

I could do a controller and a view without a backing model. This has  
the obvious advantage of not hitting the database for the prose. It  
also means the prose would be source controlled. However, it does mean  
that content prose would be stored in the view or controller, which  
feels very wrong. It’s also plausible that I would want to use the  
prose elsewhere on the site, which would lead to a copy and paste  
nightmare.

I could do a complete MVC triple, with the controller having simple  
update and show actions (I could even use timestamps to create a  
simple versioning system for the prose).

To me, the second seems preferable. Any better ideas and opinions are  
valued.

Also, how does one go about having a view that’s backed by multiple  
models and controllers in Rails (taking the Basecamp landing page as  
an example, how would it work if each bit of prose was a model  
controller pair)?

Many thanks,  
Steve

---

<div class="post-metadata">

**Author:** ![stephenallred](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@stephenallred](https://www.ruby-forum.com/u/stephenallred)\
**Post date:** [August 6, 2010, 3:50pm UTC](https://www.ruby-forum.com/t/semi-static-rails-page/192817/2 "2010-08-06T15:50:20Z")

</div>

stephenallred wrote:

> Also, how does one go about having a view that’s backed by multiple  
> models and controllers in Rails (taking the Basecamp landing page as  
> an example, how would it work if each bit of prose was a model  
> controller pair)?
> 
> Many thanks,  
> Steve

Don’t forget that a controller can marshal data from any old models it  
desires…

For an intranet app I have, the ‘landing’ page shows 4 separate partials  
driven off different models: internal news items, and key values from  
the most recently updated records from 4 different areas of the  
application.

So the landing page ‘index’ method body retrieves data something like  
this:

@recent\_news = News.find(blah blah blah)  
@recent\_projects = Project.find(blah blah blah)  
@recent\_mrds = Mrd.find(blah blah blah)  
@recent\_scenarios = Scenario.find(blah blah blah)

Then the index.html.haml view simply invokes the appropriate partial for  
each list.

---

<div class="post-metadata">

**Author:** ![stephenallred](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@stephenallred](https://www.ruby-forum.com/u/stephenallred)\
**Post date:** [August 6, 2010, 4:00pm UTC](https://www.ruby-forum.com/t/semi-static-rails-page/192817/3 "2010-08-06T16:00:37Z")

</div>

stephenallred wrote:

> Hi,
> 
> I’m looking to have a static page with prose (like the Basecamp  
> landing page) on my site and was wondering what was the most Rails way  
> of doing it.

First of all Basecamp’s landing (dashboard) page is not a static page.  
The “Latest Activity” section is dynamically generated content.

My guess is that what you see outside of that area is part of that  
page’s layout. Layout’s are generally found in app/views/layouts.

> **[Layouts and Rendering in Rails — Ruby on Rails Guides](https://guides.rubyonrails.org/layouts_and_rendering.html)**
>
> Layouts and Rendering in RailsThis guide covers the basic layout features of Action Controller and Action View.After reading this guide, you will know: How to use the various rendering methods built into Rails. How to create layouts with multiple...

> I’ve had a couple of ideas:
> 
> I could do a controller and a view without a backing model. This has  
> the obvious advantage of not hitting the database for the prose. It  
> also means the prose would be source controlled. However, it does mean  
> that content prose would be stored in the view or controller, which  
> feels very wrong. It’s also plausible that I would want to use the  
> prose elsewhere on the site, which would lead to a copy and paste  
> nightmare.

HTML content that you want to share is typically either part of the  
layout (see above) or it’s contained within a partial that gets rendered  
into views using render :partial.

> **[Layouts and Rendering in Rails — Ruby on Rails Guides](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)**
>
> Layouts and Rendering in RailsThis guide covers the basic layout features of Action Controller and Action View.After reading this guide, you will know: How to use the various rendering methods built into Rails. How to create layouts with multiple...

> I could do a complete MVC triple, with the controller having simple  
> update and show actions (I could even use timestamps to create a  
> simple versioning system for the prose).
> 
> To me, the second seems preferable. Any better ideas and opinions are  
> valued.

This seems silly to me. Unless you’re creating a Content Management  
System (CMS). If you are then you might just want to start with one of  
the Rails CMS systems.

> Also, how does one go about having a view that’s backed by multiple  
> models and controllers in Rails (taking the Basecamp landing page as  
> an example, how would it work if each bit of prose was a model  
> controller pair)?

Speaking in generalities Model-View-Controller design would typically  
have one controller that is capable of handling a list of actions. This  
controller then communicates to any number of model objects and updates  
any number of view objects. It seems to me that you have the MVC design  
pattern turned inside-out in your line of thinking.

More specifically in Rails, requests to the server are routed (as  
defined in routes.rb) to a particular action of a particular controller.  
The process of dealing with an action request starts in the controller.

The controller then deals with that request by interacting with the data  
model to collect any information required by the views that are to be  
rendered. The controller then updates its view (by rendering either the  
default view template, or the view template, XML, JSON, text, etc  
specified in render).

Some controller actions may not render any views, but instead redirect  
to another controller action which begins a new request response cycle.  
For example a “create” method is typically used to update the data model  
and then redirect to another action that is used to render the result of  
the change to the data model. One logical action to use for the redirect  
might be the “show” action of the same controller, but it doesn’t have  
to be.

---

<div class="post-metadata">

**Author:** ![stephenallred](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@stephenallred](https://www.ruby-forum.com/u/stephenallred)\
**Post date:** [August 8, 2010, 3:46pm UTC](https://www.ruby-forum.com/t/semi-static-rails-page/192817/4 "2010-08-08T15:46:02Z")

</div>

Thanks to both of you for your helpful responses, I’ll have a read up  
on partials.

Robert W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> First of all Basecamp’s landing (dashboard) page is not a static page.  
> The “Latest Activity” section is dynamically generated content.

I should have included more details (I wrote the post while waiting  
for a train at 7.20 :p). In the future the page may well have  
dynamically generated content. I suspect it will come from partials of  
other models, but I’ll have to finish reading up on them before I’m  
100%.

> Speaking in generalities Model-View-Controller design would typically  
> have one controller that is capable of handling a list of actions. This  
> controller then communicates to any number of model objects and updates  
> any number of view objects. It seems to me that you have the MVC design  
> pattern turned inside-out in your line of thinking.

Ah, that I did. I had thought it was a one to one mapping between the  
three. Many thanks for the clarification.

Again, thank you both for your responses and if I run into anymore  
questions along the way I’ll post them up.