flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: FlexJS: Circular Dependency
Date Wed, 17 Aug 2016 14:39:43 GMT
See comments in line, below.

On 8/16/16, 8:33 PM, "Alex Harui" <aharui@adobe.com> wrote:

>On 8/16/16, 2:20 PM, "Peter Ent" <pent@adobe.com> wrote:
>>I wanted to post what I've done before I commit the code to get an idea
>>this is the right approach.
>>Background: a circular dependency is when class A references class B
>>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
>>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
>>the application (eg, DataBindingExample) in the controller and replace it
>>with the Application class and then extract what it needs into local
>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
>>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.


View raw message