On Thu, May 28, 2009 at 11:29 AM, Jeff Schwab <[email protected]> wrote: > > Rick DeNatale wrote:
>> The Model holds the domain >> information and methods for processing it. >> >> The View is concerned only with presenting the view to the user, a >> model might have multiple views presenting different subsets and/or >> projections of the model. >> >> The Controller deals with communicating with the user, it processes >> user input, and decides which views should be rendered and where. > > That's different from any form of MVC I've ever heard of, including > Rails. Ordinarily, the views define the UI, and the Controller exists > strictly behind the scenes, as implementation details. By UI I mean both output and input. And the Controller and View are both involved. >> So the Rails notion of MVC seems very similar to this 1979 version. >> Controllers process user input and decide which view to render, Views >> do the rendering, and Models do the heavy application lifting. > > That's not how Rails works. You're mostly right about the Models, but > the controllers are, as Phlip suggested, just "patch boards," not for > user input. Sometimes a savvy user can send HTTP requests to a Rails > application without going through any view, but that's not the intent. No, I really understand how Rails, HTTP browsers work, and I maintain that controllers handle input and decide how to change what the user sees in response. This is partially in response to a later response you made to Brian. if we step back and see how the user interacts with a web application through a browser, the first step is to make the initial request by getting the browser to send an http request to the app. This happens when he does something like typing a url into the address bar, or following a link. The http request, typically a get here is the input I'm talking about. That input in the form of a request is routed to a controller, which typically interacts with one or more models, then renders something. That something is typically an html page from a rendered view, but could also be json, javascript, or a partial dom replacement for an ajax call, often view are involved in the rendering of this response. The only thing that views have to do with input is to provide affordances by which the user may cause additional input requests to happen, whether they be links, buttons which generate ajax requests, etc. but the input is processed by the controller in the web application. > One piece of "heavy lifting" still done by the controllers is access > control; Models know how to answer questions, and don't intrinsically > care who's asking. It's up to the Controllers to determine who gets to > see what. Only in the simplest of access control. Usually there's model involvement here as well, although it's often not obvious because the controller interaction with the security model objects is done in before filters. >> Subsequent variations of MVC, particularly those which piled >> application logic into the controller are perversions of the original >> idea. > > "Perversions." You know, there are ways of making a point that don't > involve blanket insults of everyone who disagrees with you. As others have pointed out, you are over reacting to the word. The intention here was in the same sense as "a perversion of justice". No insult was intended. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
