modals.js

// I think Ben's solution looks good although I probably wouldn't have used promises because 
// I sometimes think the interface to them is confusing and you are locked into their interpretation not your own, 
// If I did use them I would try and bury them behind my own interface. There are always going to be million 
// different ways to do the same thing in angular so I try and model the problem in terms of OO design as opposed to 
// language specific or angular specific, and of course making something easy to test is always my highest priorities. 
// Coupling tests to promises is hard and they are difficult to read. So I would use promises in the background not in 
// the foreground design.

// I have identified that we have 3 entities in this solution.

// 1) PossibleViewModel
// 2) SelectedViewModel
// 3) Control Object (Angular wants us to call this a controller)

// I would be tempted to do the following...

angular.controller = function($scope, SelectedVideModel){

  $scope.possibleViewModels = [...];

  $scope.activeViewModels = [];

  $scope.showModal = function(type){
    $scope.activeViewModels.push(findandCreatePossible($scope.possibleViewModels,type));
  }

  $scope.closeModal = function(modelVm){
    findandClose($scope.activeViewModels, modalRef);
  }

  $scope.updateModalInfo = function(modelVm, userEnteredInfo){
    find($scope.activeViewModels,modelRef).details = userEnteredInfo;
  }

}

//This should be easier to test since everything is encapsulated inside objects that say what they do rather than in 
//frameworks (like promises) which create a lot of coupling because of the interface to them.