I agree with this. The way we chose to do things in LedgerSMB (starting with the new code in 1.3) is to adopt a sort of untraditional MVC. The view has to rep

I agree with this. The way we chose to do things in LedgerSMB (starting with the new code in 1.3) is to adopt a sort of untraditional MVC. The view has to represent the model and vice versa (information present in the model thats not in the view is never used, information present in the view but not in the model is always discarded). However, the controller scripts are agnostic of this structure. They just glue these together and process operations. Therefore depending on the changes to the view, you may or may not have to change the model, but you should not have to change the controller unless you want to change what a button does. Similarly for reports, you can change these to your heart's content and no underlying changes are needed at all. We've run into a lot of resistance from folks more used to traditional MVC stuff because the controller only needs to know what it minimally needs to know (and usually this is virtually nothing). Since everything is hash refs passed around.... But in the end the approach works, and specifically because we try hard to keep things fairly abstracted and loosely coupled within the application.