p_W wrote: > I didn't read it as an insult...according to the dictionary: > > 'perversions: a perverted form of something' > 'perverted: turned from what is right; misguided; distorted.' > > Then every MVC implementation that differs from the original is indeed > 'distorted' and therefore 'perverted'
"Perversion" is an extremely derogatory term. That connotation may not be expressed by your dictionary, but I assure you, "perverse" is a very nasty way of referring to something, and implies strong disapproval. The most common use of the word is probably in relation to sex crimes. It's just not a nice thing to say. That doesn't mean Ron hasn't got the right to say it, especially if it accurately expresses his opinion; however, it's not something that ordinarily comes up in civil discourse. > Do we really need to try and interpret everything as flamebait? Do we really need to turn every intellectual debate into a struggle for personal superiority? It's silly. If I told my coworkers their opinions were "perverse," I wouldn't have coworkers anymore. > On May 28, 11:29 am, Jeff Schwab <j...@schwabcenter.com> wrote: >> Rick DeNatale wrote: >>> On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab <j...@schwabcenter.com> wrote: >>>> Phlip wrote: >>>>> Railsters: >>>>> I heard a rumor that the incorrect answer, "Controller", was in >>>>> circulation out >>>>> there. >>>> That's how I was taught MVC, long before I'd heard of Ruby: Models do >>>> some basic checking, but business logic belongs in the controller. That >>>> was the point of the controller; it gave a central place to put business >>>> logic. >>> Well that's not the original intention of Trygve Reenskaug when he >>> conceived of MVC: >>> http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf >> Thanks, I'll read that as soon as I have a chance. >> >>> Trygve's original goal was separating UI logic from domain logic (what >>> we commonly cause Business logic). 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. >> >>> 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. >> >> 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. >> >>> 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. >> >>> Note also that Reenskaug talks about Editors which are objects which >>> are associated with a view and are temporarily interposed between a >>> controller and a view. I think if you squint just a little bit you >>> can see the seeds of what Rails developers now refer to as a >>> Presenter. >> I'll have to look up Presenter. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
