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. http://guides.rubyonrails.org/layouts_and_rendering.html > 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. http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials > 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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
