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.
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.
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.