Comment by Xurinos | Hacker News Reader

Comment by Xurinos | Hacker News Reader

Parent Full thread

I suspect this is because most people do not actually understand what MVC is and how it applies to server-client relationships; in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source. Try not to wrap the entire complicated application into one big MVC umbrella because that will just confuse. There are actually multiple processes involved, and each has its own MVC.

The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC. The server's output is the View for the server and the Model for the browser. For a complex set of objects in a given Model, the final output of those objects is their View, and the consumer of that output uses it as a Model. In theory, any View can be a Model for the thing accepting the View, so in a complex system, you have a chain of MVCs.

And one can further imagine that applets written in JavaScript have their own MVC unit.

I work on complicated, large-data web apps sometimes daily. MVC has been a fine model for them and has kept my group's organization clean and modular.

> in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source.

People complaining about factual inaccuracies on Wikipedia annoy me. It's Wikipedia. The entire point and purpose of it is to fix what you know is wrong.

For once, I'd like to see, "I just touched up the Wikipedia article on this subject to explain it a bit more accurately."

Naturally, I meant nothing personal to you. Would a bug report suffice? ;)

This can be a really frustrating experience with articles where most people hold misconceptions about the concepts. I spent a few months off and on on the REST article and managed to clean it up a fair bit, but I was constantly working against militantly ignorant people. Last I checked it's somewhere between accurate and bullshit, one of the poorer resources for understanding either actual REST or more popular RPC style APIs.

>"I just touched up the Wikipedia article on this subject to explain it a bit more accurately."

"But then all my changes were reverted by an overprotective editor; I brought the issues up on the talk page, but my comments were brusquely dismissed."

Your changes would still be in the edit log, and someone more savvy in Wikipedia politics would have the opportunity to get your changes cemented. Said person might be another HN reader who is less knowledgeable about the subject matter.

If you don't make any changes, he has nothing to work with except some random whining.

(And yes, that's how it works in the real world, too.)

Are you volunteering to help push through wahnfrieden's REST changes, then?

His comment does not imply they did not go through.

Yes, that probably IS what would happen. I still wish I read more comments that said they had done this.

Did that actually happen to you when you made that change or are you just assuming it would?

(In my experience most Wikipedia edits are gratefully received, assuming you provide references for your claims. Kind of like HN, really)

>People complaining about factual inaccuracies on Wikipedia annoy me. It's Wikipedia. The entire point and purpose of it is to fix what you know is wrong.

This presupposes

1) I care about fixing it. 2) I have the knowledge to fix it (spotting and removing an inaccuracy is easy, knowing the correct and full set of facts to substitute it with not so much) 3) I can write well enough 4) The Wikipedia process is not convoluted and broken for casual contributors.

The article about MVC on Wikipedia wasn't just slightly off. For a long time, it was completely overrun by people who seemed to think MVC is an architecture for web apps. Real MVC, as the term had been used for decades before the web apps abused it and still is in interactive GUIs today, was all but relegated to a footnote.

"Touching up the Wikipedia article" has little value in cases like this. Usually the only remedy at that point is to delete the entire thing and start again, which somebody finally did not long ago.

"The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC."

While I'd still advocate DRY over this POV (unless of course DRY leads you here naturally), I will agree this is a generally valid viewpoint, because you've got the server-client model built in there instead of glossed over. And you are now the first person who has gotten me to be generally agreeable about MVC used in the web world.

Which raises the interesting question of building a framework that builds this idea into the core, with server-side MVC, client-side MVC, and some sort of defined crossover instead of the usual hacky stuff that emerges from single-MVC.

I'm currently building a single page app using this MVC-MVC approach.

I use Angularjs in the browser, now.js for the interface, and, at the moment, custom code on the server that follows the MVC pattern.

The server is lightweight: its role is to

    * manage authentication and authorizations,
    * ensure data integrity and
    * push data on update according to user permissions.

That's it.

http://angularjs.org/

http://nowjs.com/

I am doing a simialr thing. Except ASP.NET MVC 4 Web API on the server and Angular.js on the client. It feels very natural and simple to me. What I find odd is Angular.js works very similar to Silverlight, and my whole setup has similarities to Silverlight with RIA services. Yet SL+RIA never felt natural at all and was very difficult. I've not narrowed down where the difference lies.

Angular is very impressive. There are lots of small things that make it nice to use. Among them:

The lexical/nested scoping in the templates is just perfect. I've reviewed the documentation of all competing frameworks, and I couldn't figure how to do it in any of them. Since it was a primary requirement for my app, I went for Angular.

The service-based architecture, and the automatic service injection in controllers, based on parameter names are pretty nice too, as is the fact that you can pass arbitrary parameters to filters.

In a calendar widget that displays a month, I pad the `month` array with days of the surrounding months in order to get complete weeks. I wanted to have these days styled differently. `dayName` and `idem` are custom filters.

    <ul id="calendar">
        <li ng-repeat="day in month.days" 
            class="day {{day.day|dayName}} this-month-{{day.month|idem:month.month}}">
            <div class="date-number">{{day.date}}</div>
            Events go here.
        </li>
    </ul>

In CSS:

    .this-month-false{opacity: 0.7;}
    .sunday{clear:both}
    .day{float:left;width=...;height=...;}

Bam: calendar!

Isn't Backbone JS going in that direction. The server just providing an API with rendered JSON as the View which then feeds the Client as the Model?

This sounds interesting. What Xerox document are you referring to and what is the most relevant part?

I found a blog post that gives a rundown on the evolution of MVC (https://billkrat.wordpress.com/2010/12/23/hello-world/) and links something similar to the document I had originally read (http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf). I think I had originally found something that was more of a prototype of this document, but the wording appears to be the same and more succinct. The blog post also links to an earlier version of the MVC model that included a fourth part, a "Thing".

One thing I found interesting in the blog article was the notion of "smart controls", but I can rationalize that away as another MVC module; after all, the Windows OS itself is handling all the interesting behavior, and the GUI app is borrowing the behavior. Depending on the toolkit that interfaces with the "smart controls", we get access to events (mousedown, keypress, etc) that can serve as input to one of our application's controllers.

Reply on news.ycombinator.com