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