Hacker News Reader

Comment by blahbap | Hacker News Reader

Let me give you an example. In your model, you have represented the salary of an employee as an integer. In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library). The tools you use to build the view are not relevant.

View on HN

> In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library)

as JSON encoded output, as XML....

no, those output types dont map back to the controller, they are not views.

Restful Apis often times can return JSON with key value pairs for subsequent actions in the form of name: URL. While you can't click on JSON, it's a "view" for the consumer application because it can follow back into the controller. The distinction is that a view doesn't necessarily need to be a human reading a screen, and can most certainly be another application.

Ohhhh, I see now. So some data formats that render to screen through external software are views, like html, json, generated javscript or xml if they go through jQueryUI or charting libraries, but if it goes through other external software like RSS readers, or non html, json, or javscript formats, before making it to the screen, it is no longer a view. Thanks for the clarification!

jQuery UI and the charting lib are not external software, they are part of your system (application). By your logic, every possible digital representation of the model is a view because you can always dig up some tool somewhere to visualize your model. "Look, this floppy disk is a view in my MVC application, just insert it into the Commodore 64 and enter 'LOAD I_LOVE_MVC,8' "

That's not inconsistent. A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant.

This whole discussion is about MVC. In order to argue about MVC we should have a common understanding of the principles of MVC. MVC was invented by Trygve Reenskaug. His definition of MVC is both consistent and readily accessible. Therefore I have repeatedly referred to him for a definition of the components of MVC. Surprisingly, many of the posters don't seem to regard the inventor of MVC as much of an authority on MVC, preferring instead to come up with their own definitions.

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.

Given the choice between admitting that one's comment wasn't well researched, and wasting thousands of eyeball hours with whatever-it-takes rationalizations about why one's comment actually was rather well thought out, most of us make the correct choice.

Unfortunately, the wrong choice comprises nearly half of comments made. You were obviously right the first time - let it lie :)

If you take Reenskaug's original MVC, and replace the human with an external system, what changes in the M-V-C part of the architecture? Nothing. Not a jot. It's identical, or can be. What's important here isn't the original intent of the architecture, it's what we can use it for. My butterknife isn't any less a butterknife because I'm cutting an apple with it, is it?

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.

Yes, I am. I'm just not talking about your definition of MVC, which is needlessly proscriptive.

Reply on news.ycombinator.com