JannaB wrote:
How does you handle this in the Rails MVC design? I already have a
controller and a view for users (where you CRUD on the user). How do
you handle different required functionality/view like this? Thanks,
Janna
The first thing I would suggest is to take a step back from Rails and
try to focus on Model-View-Controller itself. What you are describing is
one of the fundamental design principals that MCV was created to solve.
The model should exist entirely independently from any views or
controllers. This is often referred to as decoupling. Any system based
on MVC should be able to share the same model with any number of views
and controllers.
Views and controllers are typically more tied together than are models
to view and controllers. What you want to separate from views and
controllers are the responsibilities. Plus there is usually not a
one-to-one correspondence between views and controllers. Imagine a
Graphical User Interface that contains buttons, text boxes, combo boxes,
checkboxes, image views, etc. Each of these are typically instances of
view classes. There is a "button" class, a "text box" class, etc.
These view are then composed into a hierarchy, and the hierarchy is
typically managed by a single controller. The responsibility of the
controller is to react to, and process, user input (e.g. clicking a
button or entering text in a text box). Then the controller takes that
input and communicates with the model (if necessary) and uses the data
to update the views, hence providing feedback to the user.
Now back in the world of Rails, much of this still holds true. Views
provide the interface to the user in the form of web forms with text
boxes, submit buttons, etc. The difference is rather than an event loop
that processes user interaction in "real time," web applications
typically have a request-response cycle and process user input in
"batches." The controller would typically receive all the user input
from a web form in one chunk (the URI and parameters). Then interact
with the model and produce a "page" as output to present back to the
user.
An additional aspect to Rails MVC is that controllers, along with the
routes file, serve to map URIs to resources. Keep in mind that resources
are not equivalent to controller+model.
While it makes sense to have one controller and a set of views to manage
a "User" resource. You are not at all limited to one controller per
model. Maybe in your case you might have a "Friend" resource that has
it's own controller and set of views that shows information about a
user's friend. The friends_controller might then have a "show" action
that displays information about the friend's whereabouts. I don't know
if all that makes sense, but it should serve to illustrate the idea of
resources as something separate, and in some ways more abstract, than
controllers and models.