History repeats itself. I'm also "old" and when I saw the first presentation on Angular many years ago, the google engineer started by instantiating the controller from the view. So blatantly wrong, yet noone reacted. I saw the same sh*t go down with JSP, and though to myself that I couldn't be bothered with going through the same thing twice. So I left the presentation and never looked back. That decision served me well, very happy that I'm off that bandwagon. Still love new tech though, so I'm not backwards in that sense.
> the google engineer started by instantiating the controller from the view
Sort of playing devil's advocate here, but what did you not like about that approach? I'm guessing he should have used dependency injection? Am I missing something else?
The controller is supposed to control the view, thats why it's called controller. The controller sends data to the view for presentation and reacts to events from the view and updates the model accordingly. This way the view becomes quite passive, it only knows how to present data and where to send events. You separate the display from the driving of the display.
Speaking generally (ie: not about Angular), your main app should instantiate the controller, view and model and (constructor) inject model and view into your controller.
I think you misunderstand me. I just wanted to see how it worked... intercooler is simple enought to dig into. Angular is 4 layers+ of abstraction deep now. I'd only dig into angular's code for work. I can dig into intercooler for fun. Then very likely just write it myself.
But smaller code like this that is well factored is great for learning and picking up new tricks and style.
