OJ’s rants What would OJ do?

hehe.. it sure is mate. But at the same time it makes it good coz we're always learning!

OK, I see what you mean. Bloody confusing this software development lark innit? ;-)

I guess when I read about the model I viewed (pun intended) the view as a lot dumber than it has to be.

Take Google Maps for example. There’s controller logic on the client to pull in the right images from the server (the model) depending on where the user scrolls or zooms the map (the view).

Using the view to initiate a request for data doesn't mean that the view is a controller or that the controller sits in the client/view. The view is the window into the model. The view is used to invoke commands on the controller, and the control manages the flow and the events. The example you give is not the same as having a controller on the client.

For a more push rather than pull pattern, take the WordPress comment management feature, where you can delete/approve/edit comments en mass page updates instantly whilst sending events to the the model which does the real work on the data on the server.

That's all server side control being invoked using Ajax. Again, the controller is sitting on the server, and is invoked by the client using XMLHttpRequests. Those requests are handled by the server, and markup is returned by that request and udpated in the browser. Again, the controller is not sitting in the browser.

If the browser is treated as a dumb view in this pattern with no controller logic, then all it can do is view static pages sent by the server. This is a long proven pattern, but it does reduce usability in a lot of cases.

Controller logic is not the same as UI logic. You're talking about UI logic. Controller logc will still sit on the server. Whether or not the browser client is rich with validation and funky UI updates using Ajax is completely irrelevant - the controller for the application still sits on the server, where it belongs.

I did say in my comment that the model should validate everything it's given, though I really meant it must.

I still think parts of the controller can live on the client. Take Google Maps for example. There's controller logic on the client to pull in the right images from the server (the model) depending on where the user scrolls or zooms the map (the view).

For a more push rather than pull pattern, take the WordPress comment management feature, where you can delete/approve/edit comments en mass page updates instantly whilst sending events to the the model which does the real work on the data on the server.

If the browser is treated as a dumb view in this pattern with no controller logic, then all it can do is view static pages sent by the server. This is a long proven pattern, but it does reduce usability in a lot of cases.

I almost completely disagree :) Just because a web application renders HTML which is sent to a browser, that doesn't mean there's a natural "view" in the MVC sense. That's the same as saying that a fat client is naturally distinct from the data underneath purely because it's a user interface. I really don't agree with that.

Don't forget the the browser could in fact have the entire model and controller shoved into it as well, as it's got more than enough functionality to deal with those things. But, that doesn't mean you should, and it'd be extremely bad if you did so.

The controller isn't defined by where the validation is kept, neither is the view. The model itself should always validate the information that is being given to it. There could be so many views and controllers all reference the same model, and the result is an increase in the possibility that invalid information is going to be handed down - it's not safe to assume that the controller or view will give the model the correct information.

So, I don't believe the question is "where does the controller live". In a web application, the controller lives on the server. End of story. It's job is to manage the flow of the application based on events, and this means server side. If it didn't, you have to load the entire MVC into the browser, which is not only a nightmare for development, but would increase your page weight substantially. I can't see how that would be favourable. Also, having the controller on the client side would mean that if you decided you wanted a different view (let's say, a thin Windows client which uses web services to interact with the same application) then you'd have to write an entirely new controller just for that case - which sucks. The whole point is to separate the implementations of the view so that the view can be replaced without having to code up an entirely new controller for each new view.

Validation, speed of handling and other things like that are implementation details that the coder can worry about while using the MVC, but he/she shouldn't adjust the meaning of the MVC just to squeeze a bit of performance out of their app. I'd go as far as to say that if you adjusted the way your MVC is working to get better performance by loading extra stuff into a browser, then you're no longer using an MVC and you're making it harder to maintain your code.

Web apps generally have a natural distinction between view and model anyway (unless you're executing SQL queries directly by AJAX in which case you should be shot, and probably will be when some hacker drops all the tables in your database).

The question is, where does the controller live. Client or server?

On the client it can validate user input (but doesn't have to as the model should be validating everything anyway) and update the view directly, meaning quick response for the user.

On the server it can serve up entire new pages of data from the model.

I think a hybrid is the best solution from the user's point of view depending on the exact needs, but that makes things trickier, especially if you want to maintain this and move functionality from one to the other.