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'
Do we really need to try and interpret everything as flamebait?
On May 28, 11:29 am, Jeff Schwab <[email protected]> wrote:
> Rick DeNatale wrote:
> > On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
