See comments in line, below. ‹peter On 8/16/16, 8:33 PM, "Alex Harui" <[email protected]> wrote:
> > >On 8/16/16, 2:20 PM, "Peter Ent" <[email protected]> wrote: > >> >>Hi, >> >>I wanted to post what I've done before I commit the code to get an idea >>if >>this is the right approach. >> >>Background: a circular dependency is when class A references class B >>which >>references class B. Pretty simple. >> >>In many of the FlexJS examples, there are circular dependencies between >>the application class and the application's controller. For example, >>DataBindingExampleApp references its controller, MyController, which has >>a >>reference back to the application. Likewise, the TodoListSampleApp >>references its controller which holds a reference to the app class. The >>objective in both examples is provide the controller with a reference to >>the model. >> >>In both of these cases, my solution is to remove the explicit reference >>to >>the application (eg, DataBindingExample) in the controller and replace it >>with the Application class and then extract what it needs into local >>variables. > >The above sounds like a good plan. > >>However, MobileTrader is bit trickier. MobileTrader has several mobile >>"views" and each has its own controller. The circular dependency in this >>case is between these secondary views and their respective controllers. >>The way I approached this was to make a new interface in the MobileTrader >>example src, called "IBeadControllerWithModel" which extends >>IBeadController and adds a getter/setter for a model. Now the view can >>simple reference its controller using this new interface and set the >>model >>so the controller can now modify it. > >I don't know this code very well, but I poked around a bit and it appears >the view knows about the controller only because it is assigning the model >to the controller. IMO, the controller should pick up the model from the >strand. If it is a timing issue where the model isn't set when the >controller is put on the strand, the controller should be able to look for >a modelChange event or maybe even initComplete. This does work and is easier, actually. The views can dispatch a modelChanged event whenever they are assigned the model (which is right away because they are set up via data binding). This happens before the controllers' strands are set. When a controller is put onto their views' strand, it will be able to grab the model from the view without needing the interface. So this is a better pattern. I will clean up the code and publish a new reply to this thread. > >Thoughts? >-Alex >
