my rails apps pass this test with flying colors. Nearly all of my end points have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and 1 for rss/atom.
Quote from the inventor of MVC, Trygve Reenskaug:
"The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer."
Source: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
And you are not a human user, you are an engineer.
I am most certainly a human user.
Maybe there is some significant difference, but you haven't outlined one other than "it's not what person X says MVC means".
We call those, "views".
[1] Although were talking about Model 2 here, so thats irrelevant. Come to think of it, this whole discussion is pointless: we're arguing about whether views in a Model 2 architecture are proper MVC views...
If you're claiming that regular HTML views are compliant with MVC because they have HTML links, one can argue that some RSS readers convert the reference links from the RSS feed to actual HTML links that you can use to navigate to the individual RSS item. How is that different than a regular HTML view with links?
I see no purpose for this distinction. A view is an output representation of the model data.
Given the challenge, "How much of my code survives if I drastically change the view?", I think json and rss make perfect sense. They are drastically different output representations of the data.
That said, non-HTML output bypasses the view entirely in Rails (it makes sense to), so it can equally be the case that the distinction is correct.
https://github.com/rails/jbuilder/
It looks a lot like a view file :)
as JSON encoded output, as XML....
You have just provided a new definition of a view:
"A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant"
If this definition suits your application, good for you. But you are no longer talking about MVC.
Unfortunately, the wrong choice comprises nearly half of comments made. You were obviously right the first time - let it lie :)
The problem here is that Reenskaug explicitly abrogated the authority you're appealing to. He recognised that MVC as originally posed was problematic and incomplete, and invited others to refine it via a pattern language, making MVC a metadefinition. At this point in history, you simply can't point at "MVC" and say that the original definition is canonical.
If you're still going to appeal to the original definition, the View still isn't a visual representation. That's the Editor. Everyone seems to forget about that bit. If you exclude the Editor, we're no longer in Reenskaug-MVC, so even if they weren't in the first place, machine representations would be ok. If you include it, your objection to JSON and RSS representations per se falls apart, because they can be perfectly valid technical details of the Editor layer under control of the View.
If this definition suits your application, good for you. But you are no longer talking about MVC.
The Formatter inspects the Request to determine what format it should be (html, json, xml, etc.), and returns the correct View to the Controller, which then passes the Model to that View.