You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by PKumar <pr...@gmail.com> on 2016/08/15 10:59:19 UTC
FlexJS: Circular Dependency
Hi,
I am trying to cross compile FlexJS example "TodoListSampleApp" but getting
the circular dependency error. Please check the attached screen shot. How
can i remove this error?
<http://apache-flex-users.2333346.n4.nabble.com/file/n13287/error.jpg>
-----
Regards,
Prashant
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
It looks like there is a bit of a discrepancy between the two controllers.
I think both should implement IBeadController and IDocument. The
IBeadController because they are controllers and IDocument so that you can
get a handle to the application and grab things from that, like the model,
which is what I'm going to be doing.
The applicationComplete event should be the final event sent once all of
the components have been created, their beads created and adding to their
component strands, and all of the components are on the display list.
There may still be a few iterations of sizing and placement to go, but
most of the time that's all done too.
The viewChanged event is dispatched by a component when its IBeadView bead
has been added to the strand. This event will precede applicationComplete.
‹peter
On 8/17/16, 2:44 PM, "PKumar" <pr...@gmail.com> wrote:
>Thanks for response, but I was looking the controller implementation and i
>got following implementation
>
>*public class AlertsViewController extends EventDispatcher implements
>IBeadController
>{
>
>}*
>
>and
>*public class TodoListController implements IDocument
>{
>
>}*
>
>So why these two implementation and what is the purpose behind it? Please
>explain.
>
>Also, what is the difference between "applicationComplete" event &
>"viewChanged" event?
>
>
>
>
>
>-----
>Regards,
>Prashant
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-
>tp13287p13333.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by PKumar <pr...@gmail.com>.
Thanks for response, but I was looking the controller implementation and i
got following implementation
*public class AlertsViewController extends EventDispatcher implements
IBeadController
{
}*
and
*public class TodoListController implements IDocument
{
}*
So why these two implementation and what is the purpose behind it? Please
explain.
Also, what is the difference between "applicationComplete" event &
"viewChanged" event?
-----
Regards,
Prashant
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287p13333.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
See comments in line, below.
‹peter
On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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
>
Re: FlexJS: Circular Dependency
Posted by PKumar <pr...@gmail.com>.
Than for valuable comments, but do we need to do any framework related code
changes to implement the discussed approach?
-----
Regards,
Prashant
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287p13339.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
I've committed changes to the TodoListExample and DataBindingExample
samples. I will work on MobileTrader solution for a bit to see what can be
worked out.
‹peter
On 8/18/16, 10:45 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>On 8/18/16, 7:21 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>More thoughtsŠ
>>‹peter
>>
>>On 8/17/16, 7:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>OK, I think I get it now. The key thing is that the "View" isn't really
>>>a
>>>view like a ButtonView or CheckBoxView is to Button or Checkbox.
>>>Instead,
>>>a View is a top-level component.
>>>
>>>Application is a top-level component. It has a "model", "controller",
>>>and
>>>"initialView" property. You were able to eliminate circularities by
>>>having the 3 rules below because the controller is referencing the
>>>"initialView" and "model" and not the Application (as it should).
>>>
>>>The equivalent for StackedViewManager may require terms borrowed from
>>>the
>>>Flex SDK: "navigator" and "navigatorContent". If StackedViewManager is
>>>actually a StackNavigator and there was a NavigatorContent tag with view
>>>and controller, that would be more similar to the Application pattern:
>>
>>Right now in the Mobile project framework, the equivalent of
>>NavigatorContent is the StackedViewManager's StackedViewManagerView bead.
>>The view bead is responsible for the layout and creation of the stack, so
>>it manages the content. If the intent is to have NavigatorContent have
>>its
>>own view and controller, then in the pay-as-you-go system, we'd need
>>StackedNavigatorContent or maybe just SavedNavigatorContentView (or
>>NavigatorContentStackedView and NavigatorContentTabbedView) so it would
>>know how to do that layout. In other words, push the responsibility of
>>the
>>Stack and Tab view managers down to a subordinate class. I'm not sure
>>this
>>would make a difference as the StackedViewManager already does this and
>>has its own view; it does not have a controller because the pushing and
>>popping of the views are taken care of via function calls. The
>>TabbedViewManager does have a controller tho.
>
>In Flex, a NavigatorContent is a container component that is a child of a
>Navigator, so IMO, the StackedViewManagerView would not be a
>NavigatorContent. IT would continue to be the view, just like Containers
>have a ContainerView. A layout would manage placement of children in the
>view. You are correct that StackedViewManager doesn't need a controller
>since there is no interactions to switch views. TabbedViewManager would
>have a controller.
>
>The goal of introducing a NavigatorContent is to make the "topology" more
>similar. Application contains a model, view, and controller that are all
>peers. Same for low-level Label, TextInput, etc. The circularity in
>MobileTrader is coming from making a controller a "child" of the view by
>putting it on the view's strand. So this idea tries to make the
>WatchList's view and controller as peers.
>
>IMO, the way controllers and views pick up their models is potentially a
>separate topic as we might want to tweak it in Application and the
>low-level components as well for consistency.
>
>Anyway, since we are trying to get a release out, it might be reasonable
>to check in the changes to the other examples, not check in the changes to
>Mobile Trader and play with this stuff in a separate branch.
>
>Thoughts?
>-Alex
>
>
>>>
>>><StackedNavigator>
>>> <NavigatorContent title="Watch List" dataModel="{applicationModel}">
>>> <view>
>>> <View>
>>> UI Widgets
>>> </View>
>>> </view>
>>> <controller>
>>> <WatchListController />
>>> </controller>
>>> </NavigatorContent>
>>></StackedNavigator>
>
Re: FlexJS: Circular Dependency
Posted by Alex Harui <ah...@adobe.com>.
On 8/18/16, 7:21 AM, "Peter Ent" <pe...@adobe.com> wrote:
>More thoughts…
>—peter
>
>On 8/17/16, 7:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>OK, I think I get it now. The key thing is that the "View" isn't really
>>a
>>view like a ButtonView or CheckBoxView is to Button or Checkbox.
>>Instead,
>>a View is a top-level component.
>>
>>Application is a top-level component. It has a "model", "controller",
>>and
>>"initialView" property. You were able to eliminate circularities by
>>having the 3 rules below because the controller is referencing the
>>"initialView" and "model" and not the Application (as it should).
>>
>>The equivalent for StackedViewManager may require terms borrowed from the
>>Flex SDK: "navigator" and "navigatorContent". If StackedViewManager is
>>actually a StackNavigator and there was a NavigatorContent tag with view
>>and controller, that would be more similar to the Application pattern:
>
>Right now in the Mobile project framework, the equivalent of
>NavigatorContent is the StackedViewManager's StackedViewManagerView bead.
>The view bead is responsible for the layout and creation of the stack, so
>it manages the content. If the intent is to have NavigatorContent have its
>own view and controller, then in the pay-as-you-go system, we'd need
>StackedNavigatorContent or maybe just SavedNavigatorContentView (or
>NavigatorContentStackedView and NavigatorContentTabbedView) so it would
>know how to do that layout. In other words, push the responsibility of the
>Stack and Tab view managers down to a subordinate class. I'm not sure this
>would make a difference as the StackedViewManager already does this and
>has its own view; it does not have a controller because the pushing and
>popping of the views are taken care of via function calls. The
>TabbedViewManager does have a controller tho.
In Flex, a NavigatorContent is a container component that is a child of a
Navigator, so IMO, the StackedViewManagerView would not be a
NavigatorContent. IT would continue to be the view, just like Containers
have a ContainerView. A layout would manage placement of children in the
view. You are correct that StackedViewManager doesn't need a controller
since there is no interactions to switch views. TabbedViewManager would
have a controller.
The goal of introducing a NavigatorContent is to make the "topology" more
similar. Application contains a model, view, and controller that are all
peers. Same for low-level Label, TextInput, etc. The circularity in
MobileTrader is coming from making a controller a "child" of the view by
putting it on the view's strand. So this idea tries to make the
WatchList's view and controller as peers.
IMO, the way controllers and views pick up their models is potentially a
separate topic as we might want to tweak it in Application and the
low-level components as well for consistency.
Anyway, since we are trying to get a release out, it might be reasonable
to check in the changes to the other examples, not check in the changes to
Mobile Trader and play with this stuff in a separate branch.
Thoughts?
-Alex
>>
>><StackedNavigator>
>> <NavigatorContent title="Watch List" dataModel="{applicationModel}">
>> <view>
>> <View>
>> UI Widgets
>> </View>
>> </view>
>> <controller>
>> <WatchListController />
>> </controller>
>> </NavigatorContent>
>></StackedNavigator>
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
More thoughts…
—peter
On 8/17/16, 7:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>OK, I think I get it now. The key thing is that the "View" isn't really a
>view like a ButtonView or CheckBoxView is to Button or Checkbox. Instead,
>a View is a top-level component.
>
>Application is a top-level component. It has a "model", "controller", and
>"initialView" property. You were able to eliminate circularities by
>having the 3 rules below because the controller is referencing the
>"initialView" and "model" and not the Application (as it should).
>
>The equivalent for StackedViewManager may require terms borrowed from the
>Flex SDK: "navigator" and "navigatorContent". If StackedViewManager is
>actually a StackNavigator and there was a NavigatorContent tag with view
>and controller, that would be more similar to the Application pattern:
Right now in the Mobile project framework, the equivalent of
NavigatorContent is the StackedViewManager's StackedViewManagerView bead.
The view bead is responsible for the layout and creation of the stack, so
it manages the content. If the intent is to have NavigatorContent have its
own view and controller, then in the pay-as-you-go system, we'd need
StackedNavigatorContent or maybe just SavedNavigatorContentView (or
NavigatorContentStackedView and NavigatorContentTabbedView) so it would
know how to do that layout. In other words, push the responsibility of the
Stack and Tab view managers down to a subordinate class. I'm not sure this
would make a difference as the StackedViewManager already does this and
has its own view; it does not have a controller because the pushing and
popping of the views are taken care of via function calls. The
TabbedViewManager does have a controller tho.
This is a tricky problem.
>
><StackedNavigator>
> <NavigatorContent title="Watch List" dataModel="{applicationModel}">
> <view>
> <View>
> UI Widgets
> </View>
> </view>
> <controller>
> <WatchListController />
> </controller>
> </NavigatorContent>
></StackedNavigator>
>
>And I think that would also eliminate circularities because the controller
>would be referencing the View and not the NavigatorContent.
>
>Thoughts?
>-Alex
>
>On 8/17/16, 2:29 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>
>>
>>On 8/17/16, 5:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>Peter,
>>>
>>>I like the idea of declaring the controller as a bead in the view.
>>>
>>>But shouldn't the controller be able to know about (have references to)
>>>the View as long as the View doesn't know about the controller (which it
>>>shouldn't, IMO).
>>As soon as I added the controller has a bead, the circular dependency was
>>formed. I had started with the previous changes where I had removed the
>>circular dependency - the controller was just referenced in the CSS.
>>>
>>>The view should dispatch events (for example, converting a "click" on a
>>>checkbox to "LicenseAcceptanceCheckboxSelectionChange" but it should be
>>>ok
>>>for the controller to have a reference to the view to access data from
>>>the widgets, validate them, and then apply them to the model. Passing
>>>data via events means copying data and references and the controller
>>>code
>>>might need other values from other widgets in the view. It also means
>>>fewer custom event classes.
>>
>>I thought using custom events was a nice way to separate the concerns.
>>What do other people think - do you use a lot of custom events in your
>>application code or do you get some simple event and then go grab the
>>data
>>out of the controls?
>>
>>>
>>>IMO:
>>>Models should not reference views or controllers
>>>Views should reference models but not controllers
>>>Controllers should reference models and views.
>>
>>I don't see how you can remove the dependency when the View MXML explicit
>>references the Controller MXML in the <js:beads> list. Perhaps we have
>>something wrong in the fundamentals then.
>>
>>>
>>>I think there aren't circularities in that set.
>>>
>>>Thoughts?
>>>-Alex
>>>
>>>On 8/17/16, 1:46 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>>
>>>>This is what I'm concluding in MobileTrader:
>>>>
>>>>MobileTrader has "sub-views" for WatchList and Alerts. Each of these
>>>>sub-views has its own controller (WatchListController,
>>>>AlertViewController) which are responsible for taking events from the
>>>>view
>>>>and updating the model.
>>>>
>>>>The first task is to get the controller to know about the model. We are
>>>>talking about the model holding the data, not the FlexJS "model" which
>>>>most components have that hold values for the component's properties.
>>>>So
>>>>I'm calling this the "dataModel". The circular dependencies are arising
>>>>because the controllers are directly references their views and
>>>>grabbing
>>>>data out of the view.
>>>>
>>>>I removed the attachment of the controller to the sub-view from the
>>>>CSS.
>>>>In the view (eg, WatchListView), I explicitly name the controller bead
>>>>and
>>>>use data binding to pass in the model the controller needs to use.
>>>>
>>>><js:beads>
>>>> <js:ViewDataBinding>
>>>> <controller:WatchListController dataModel="{dataModel}" />
>>>></js:beads>
>>>>
>>>>(Note: The WatchListView's dataModel is set using data binding from the
>>>>outer MyInitialView).
>>>>
>>>>Then I removed all references to WatchListView from
>>>>WatchListController.
>>>>This caused several errors because WatchListController was referencing
>>>>the
>>>>view to get to the data on the screen which needed. For example, it
>>>>needed
>>>>the symbol to watch:
>>>>
>>>>view.symbolName.text
>>>>
>>>>Since WatchListController now knows nothing about the view, I created
>>>>custom events for the WatchListView to dispatch that contained the data
>>>>the controller needs. So when the Set button is picked, the button's
>>>>event
>>>>handler in WatchListView now does:
>>>>
>>>>var event: new AddSymbolEvent(symbolName.text);
>>>>dispatchEvent(event);
>>>>
>>>>The WatchListController is looking for this event and can use the
>>>>symbol
>>>>value from the event without referring to the view at all.
>>>>
>>>>I applied this technique to the AlertsView and AlertsViewController.
>>>>All
>>>>in all, the code got cleaner and more readable. The view takes care of
>>>>updating the view UI components and the controller takes care of
>>>>updating
>>>>the model.
>>>>
>>>>The pattern now works something like this:
>>>>
>>>>1. Give the sub-view controller bead bindable get/set methods for the
>>>>dataModel it needs. Don't forget to add the ViewDataBinding bead to the
>>>>sub-view class.
>>>>2. Create custom events to pass data from the sub-view controls over to
>>>>the controller.
>>>>3. Have the controller set up event listeners for these custom events
>>>>in
>>>>its strand-setter; the "strand" is really the sub-view.
>>>>4. When the view receives some user interaction, have it create a
>>>>custom
>>>>event with the data and dispatch it.
>>>>5. The controller will receive the custom event and modify the model.
>>>>6. The view can update the UI controls (eg, textField.text = "") after
>>>>sending the event.
>>>>
>>>>For simpler projects, like the TodoListSample or DataBindingExample,
>>>>the
>>>>controller can implement IDocument and, when the "document" (aka,
>>>>Application) is set, it can get the reference to the application data
>>>>model and set up listeners for it.
>>>>
>>>>I will be checking these changes in shortly today or tomorrow (USA,
>>>>EDT)
>>>>morning.
>>>>
>>>>‹peter
>>>>
>>>>On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>>>>>
>>>>>Thoughts?
>>>>>-Alex
>>>>>
>>>>
>>>
>>
>
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
Seems really weird to be put a dataModel property on an object whose sole
purpose is be a grouping mechanism. I understand wanting to preserve the
model/view/controller paradigm, but wouldn't it more efficient to give the
data model to the things that actually need the data model in as direct a
fashion as possible? The data is readily available in this class that has
this structure and passing it to the widgets individually via data binding
would make things a lot easier than having to have these components
discover the data in their life cycles.
I have to really look over how I created the whole mobile component
classes and make sure they conform to this pattern because I think it will
be some re-writing. Maybe not too much, but I have to go and wrap my head
around it.
—peter
On 8/17/16, 7:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>OK, I think I get it now. The key thing is that the "View" isn't really a
>view like a ButtonView or CheckBoxView is to Button or Checkbox. Instead,
>a View is a top-level component.
>
>Application is a top-level component. It has a "model", "controller", and
>"initialView" property. You were able to eliminate circularities by
>having the 3 rules below because the controller is referencing the
>"initialView" and "model" and not the Application (as it should).
>
>The equivalent for StackedViewManager may require terms borrowed from the
>Flex SDK: "navigator" and "navigatorContent". If StackedViewManager is
>actually a StackNavigator and there was a NavigatorContent tag with view
>and controller, that would be more similar to the Application pattern:
>
><StackedNavigator>
> <NavigatorContent title="Watch List" dataModel="{applicationModel}">
> <view>
> <View>
> UI Widgets
> </View>
> </view>
> <controller>
> <WatchListController />
> </controller>
> </NavigatorContent>
></StackedNavigator>
>
>And I think that would also eliminate circularities because the controller
>would be referencing the View and not the NavigatorContent.
>
>Thoughts?
>-Alex
>
>On 8/17/16, 2:29 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>
>>
>>On 8/17/16, 5:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>Peter,
>>>
>>>I like the idea of declaring the controller as a bead in the view.
>>>
>>>But shouldn't the controller be able to know about (have references to)
>>>the View as long as the View doesn't know about the controller (which it
>>>shouldn't, IMO).
>>As soon as I added the controller has a bead, the circular dependency was
>>formed. I had started with the previous changes where I had removed the
>>circular dependency - the controller was just referenced in the CSS.
>>>
>>>The view should dispatch events (for example, converting a "click" on a
>>>checkbox to "LicenseAcceptanceCheckboxSelectionChange" but it should be
>>>ok
>>>for the controller to have a reference to the view to access data from
>>>the widgets, validate them, and then apply them to the model. Passing
>>>data via events means copying data and references and the controller
>>>code
>>>might need other values from other widgets in the view. It also means
>>>fewer custom event classes.
>>
>>I thought using custom events was a nice way to separate the concerns.
>>What do other people think - do you use a lot of custom events in your
>>application code or do you get some simple event and then go grab the
>>data
>>out of the controls?
>>
>>>
>>>IMO:
>>>Models should not reference views or controllers
>>>Views should reference models but not controllers
>>>Controllers should reference models and views.
>>
>>I don't see how you can remove the dependency when the View MXML explicit
>>references the Controller MXML in the <js:beads> list. Perhaps we have
>>something wrong in the fundamentals then.
>>
>>>
>>>I think there aren't circularities in that set.
>>>
>>>Thoughts?
>>>-Alex
>>>
>>>On 8/17/16, 1:46 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>>
>>>>This is what I'm concluding in MobileTrader:
>>>>
>>>>MobileTrader has "sub-views" for WatchList and Alerts. Each of these
>>>>sub-views has its own controller (WatchListController,
>>>>AlertViewController) which are responsible for taking events from the
>>>>view
>>>>and updating the model.
>>>>
>>>>The first task is to get the controller to know about the model. We are
>>>>talking about the model holding the data, not the FlexJS "model" which
>>>>most components have that hold values for the component's properties.
>>>>So
>>>>I'm calling this the "dataModel". The circular dependencies are arising
>>>>because the controllers are directly references their views and
>>>>grabbing
>>>>data out of the view.
>>>>
>>>>I removed the attachment of the controller to the sub-view from the
>>>>CSS.
>>>>In the view (eg, WatchListView), I explicitly name the controller bead
>>>>and
>>>>use data binding to pass in the model the controller needs to use.
>>>>
>>>><js:beads>
>>>> <js:ViewDataBinding>
>>>> <controller:WatchListController dataModel="{dataModel}" />
>>>></js:beads>
>>>>
>>>>(Note: The WatchListView's dataModel is set using data binding from the
>>>>outer MyInitialView).
>>>>
>>>>Then I removed all references to WatchListView from
>>>>WatchListController.
>>>>This caused several errors because WatchListController was referencing
>>>>the
>>>>view to get to the data on the screen which needed. For example, it
>>>>needed
>>>>the symbol to watch:
>>>>
>>>>view.symbolName.text
>>>>
>>>>Since WatchListController now knows nothing about the view, I created
>>>>custom events for the WatchListView to dispatch that contained the data
>>>>the controller needs. So when the Set button is picked, the button's
>>>>event
>>>>handler in WatchListView now does:
>>>>
>>>>var event: new AddSymbolEvent(symbolName.text);
>>>>dispatchEvent(event);
>>>>
>>>>The WatchListController is looking for this event and can use the
>>>>symbol
>>>>value from the event without referring to the view at all.
>>>>
>>>>I applied this technique to the AlertsView and AlertsViewController.
>>>>All
>>>>in all, the code got cleaner and more readable. The view takes care of
>>>>updating the view UI components and the controller takes care of
>>>>updating
>>>>the model.
>>>>
>>>>The pattern now works something like this:
>>>>
>>>>1. Give the sub-view controller bead bindable get/set methods for the
>>>>dataModel it needs. Don't forget to add the ViewDataBinding bead to the
>>>>sub-view class.
>>>>2. Create custom events to pass data from the sub-view controls over to
>>>>the controller.
>>>>3. Have the controller set up event listeners for these custom events
>>>>in
>>>>its strand-setter; the "strand" is really the sub-view.
>>>>4. When the view receives some user interaction, have it create a
>>>>custom
>>>>event with the data and dispatch it.
>>>>5. The controller will receive the custom event and modify the model.
>>>>6. The view can update the UI controls (eg, textField.text = "") after
>>>>sending the event.
>>>>
>>>>For simpler projects, like the TodoListSample or DataBindingExample,
>>>>the
>>>>controller can implement IDocument and, when the "document" (aka,
>>>>Application) is set, it can get the reference to the application data
>>>>model and set up listeners for it.
>>>>
>>>>I will be checking these changes in shortly today or tomorrow (USA,
>>>>EDT)
>>>>morning.
>>>>
>>>>‹peter
>>>>
>>>>On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>>>>>
>>>>>Thoughts?
>>>>>-Alex
>>>>>
>>>>
>>>
>>
>
Re: FlexJS: Circular Dependency
Posted by Alex Harui <ah...@adobe.com>.
OK, I think I get it now. The key thing is that the "View" isn't really a
view like a ButtonView or CheckBoxView is to Button or Checkbox. Instead,
a View is a top-level component.
Application is a top-level component. It has a "model", "controller", and
"initialView" property. You were able to eliminate circularities by
having the 3 rules below because the controller is referencing the
"initialView" and "model" and not the Application (as it should).
The equivalent for StackedViewManager may require terms borrowed from the
Flex SDK: "navigator" and "navigatorContent". If StackedViewManager is
actually a StackNavigator and there was a NavigatorContent tag with view
and controller, that would be more similar to the Application pattern:
<StackedNavigator>
<NavigatorContent title="Watch List" dataModel="{applicationModel}">
<view>
<View>
UI Widgets
</View>
</view>
<controller>
<WatchListController />
</controller>
</NavigatorContent>
</StackedNavigator>
And I think that would also eliminate circularities because the controller
would be referencing the View and not the NavigatorContent.
Thoughts?
-Alex
On 8/17/16, 2:29 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>
>On 8/17/16, 5:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>Peter,
>>
>>I like the idea of declaring the controller as a bead in the view.
>>
>>But shouldn't the controller be able to know about (have references to)
>>the View as long as the View doesn't know about the controller (which it
>>shouldn't, IMO).
>As soon as I added the controller has a bead, the circular dependency was
>formed. I had started with the previous changes where I had removed the
>circular dependency - the controller was just referenced in the CSS.
>>
>>The view should dispatch events (for example, converting a "click" on a
>>checkbox to "LicenseAcceptanceCheckboxSelectionChange" but it should be
>>ok
>>for the controller to have a reference to the view to access data from
>>the widgets, validate them, and then apply them to the model. Passing
>>data via events means copying data and references and the controller code
>>might need other values from other widgets in the view. It also means
>>fewer custom event classes.
>
>I thought using custom events was a nice way to separate the concerns.
>What do other people think - do you use a lot of custom events in your
>application code or do you get some simple event and then go grab the data
>out of the controls?
>
>>
>>IMO:
>>Models should not reference views or controllers
>>Views should reference models but not controllers
>>Controllers should reference models and views.
>
>I don't see how you can remove the dependency when the View MXML explicit
>references the Controller MXML in the <js:beads> list. Perhaps we have
>something wrong in the fundamentals then.
>
>>
>>I think there aren't circularities in that set.
>>
>>Thoughts?
>>-Alex
>>
>>On 8/17/16, 1:46 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>>This is what I'm concluding in MobileTrader:
>>>
>>>MobileTrader has "sub-views" for WatchList and Alerts. Each of these
>>>sub-views has its own controller (WatchListController,
>>>AlertViewController) which are responsible for taking events from the
>>>view
>>>and updating the model.
>>>
>>>The first task is to get the controller to know about the model. We are
>>>talking about the model holding the data, not the FlexJS "model" which
>>>most components have that hold values for the component's properties. So
>>>I'm calling this the "dataModel". The circular dependencies are arising
>>>because the controllers are directly references their views and grabbing
>>>data out of the view.
>>>
>>>I removed the attachment of the controller to the sub-view from the CSS.
>>>In the view (eg, WatchListView), I explicitly name the controller bead
>>>and
>>>use data binding to pass in the model the controller needs to use.
>>>
>>><js:beads>
>>> <js:ViewDataBinding>
>>> <controller:WatchListController dataModel="{dataModel}" />
>>></js:beads>
>>>
>>>(Note: The WatchListView's dataModel is set using data binding from the
>>>outer MyInitialView).
>>>
>>>Then I removed all references to WatchListView from WatchListController.
>>>This caused several errors because WatchListController was referencing
>>>the
>>>view to get to the data on the screen which needed. For example, it
>>>needed
>>>the symbol to watch:
>>>
>>>view.symbolName.text
>>>
>>>Since WatchListController now knows nothing about the view, I created
>>>custom events for the WatchListView to dispatch that contained the data
>>>the controller needs. So when the Set button is picked, the button's
>>>event
>>>handler in WatchListView now does:
>>>
>>>var event: new AddSymbolEvent(symbolName.text);
>>>dispatchEvent(event);
>>>
>>>The WatchListController is looking for this event and can use the symbol
>>>value from the event without referring to the view at all.
>>>
>>>I applied this technique to the AlertsView and AlertsViewController. All
>>>in all, the code got cleaner and more readable. The view takes care of
>>>updating the view UI components and the controller takes care of
>>>updating
>>>the model.
>>>
>>>The pattern now works something like this:
>>>
>>>1. Give the sub-view controller bead bindable get/set methods for the
>>>dataModel it needs. Don't forget to add the ViewDataBinding bead to the
>>>sub-view class.
>>>2. Create custom events to pass data from the sub-view controls over to
>>>the controller.
>>>3. Have the controller set up event listeners for these custom events in
>>>its strand-setter; the "strand" is really the sub-view.
>>>4. When the view receives some user interaction, have it create a custom
>>>event with the data and dispatch it.
>>>5. The controller will receive the custom event and modify the model.
>>>6. The view can update the UI controls (eg, textField.text = "") after
>>>sending the event.
>>>
>>>For simpler projects, like the TodoListSample or DataBindingExample, the
>>>controller can implement IDocument and, when the "document" (aka,
>>>Application) is set, it can get the reference to the application data
>>>model and set up listeners for it.
>>>
>>>I will be checking these changes in shortly today or tomorrow (USA, EDT)
>>>morning.
>>>
>>>‹peter
>>>
>>>On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>>>>
>>>>Thoughts?
>>>>-Alex
>>>>
>>>
>>
>
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
On 8/17/16, 5:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
>Peter,
>
>I like the idea of declaring the controller as a bead in the view.
>
>But shouldn't the controller be able to know about (have references to)
>the View as long as the View doesn't know about the controller (which it
>shouldn't, IMO).
As soon as I added the controller has a bead, the circular dependency was
formed. I had started with the previous changes where I had removed the
circular dependency - the controller was just referenced in the CSS.
>
>The view should dispatch events (for example, converting a "click" on a
>checkbox to "LicenseAcceptanceCheckboxSelectionChange" but it should be ok
>for the controller to have a reference to the view to access data from
>the widgets, validate them, and then apply them to the model. Passing
>data via events means copying data and references and the controller code
>might need other values from other widgets in the view. It also means
>fewer custom event classes.
I thought using custom events was a nice way to separate the concerns.
What do other people think - do you use a lot of custom events in your
application code or do you get some simple event and then go grab the data
out of the controls?
>
>IMO:
>Models should not reference views or controllers
>Views should reference models but not controllers
>Controllers should reference models and views.
I don't see how you can remove the dependency when the View MXML explicit
references the Controller MXML in the <js:beads> list. Perhaps we have
something wrong in the fundamentals then.
>
>I think there aren't circularities in that set.
>
>Thoughts?
>-Alex
>
>On 8/17/16, 1:46 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>This is what I'm concluding in MobileTrader:
>>
>>MobileTrader has "sub-views" for WatchList and Alerts. Each of these
>>sub-views has its own controller (WatchListController,
>>AlertViewController) which are responsible for taking events from the
>>view
>>and updating the model.
>>
>>The first task is to get the controller to know about the model. We are
>>talking about the model holding the data, not the FlexJS "model" which
>>most components have that hold values for the component's properties. So
>>I'm calling this the "dataModel". The circular dependencies are arising
>>because the controllers are directly references their views and grabbing
>>data out of the view.
>>
>>I removed the attachment of the controller to the sub-view from the CSS.
>>In the view (eg, WatchListView), I explicitly name the controller bead
>>and
>>use data binding to pass in the model the controller needs to use.
>>
>><js:beads>
>> <js:ViewDataBinding>
>> <controller:WatchListController dataModel="{dataModel}" />
>></js:beads>
>>
>>(Note: The WatchListView's dataModel is set using data binding from the
>>outer MyInitialView).
>>
>>Then I removed all references to WatchListView from WatchListController.
>>This caused several errors because WatchListController was referencing
>>the
>>view to get to the data on the screen which needed. For example, it
>>needed
>>the symbol to watch:
>>
>>view.symbolName.text
>>
>>Since WatchListController now knows nothing about the view, I created
>>custom events for the WatchListView to dispatch that contained the data
>>the controller needs. So when the Set button is picked, the button's
>>event
>>handler in WatchListView now does:
>>
>>var event: new AddSymbolEvent(symbolName.text);
>>dispatchEvent(event);
>>
>>The WatchListController is looking for this event and can use the symbol
>>value from the event without referring to the view at all.
>>
>>I applied this technique to the AlertsView and AlertsViewController. All
>>in all, the code got cleaner and more readable. The view takes care of
>>updating the view UI components and the controller takes care of updating
>>the model.
>>
>>The pattern now works something like this:
>>
>>1. Give the sub-view controller bead bindable get/set methods for the
>>dataModel it needs. Don't forget to add the ViewDataBinding bead to the
>>sub-view class.
>>2. Create custom events to pass data from the sub-view controls over to
>>the controller.
>>3. Have the controller set up event listeners for these custom events in
>>its strand-setter; the "strand" is really the sub-view.
>>4. When the view receives some user interaction, have it create a custom
>>event with the data and dispatch it.
>>5. The controller will receive the custom event and modify the model.
>>6. The view can update the UI controls (eg, textField.text = "") after
>>sending the event.
>>
>>For simpler projects, like the TodoListSample or DataBindingExample, the
>>controller can implement IDocument and, when the "document" (aka,
>>Application) is set, it can get the reference to the application data
>>model and set up listeners for it.
>>
>>I will be checking these changes in shortly today or tomorrow (USA, EDT)
>>morning.
>>
>>‹peter
>>
>>On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>>>
>>>Thoughts?
>>>-Alex
>>>
>>
>
Re: FlexJS: Circular Dependency
Posted by Alex Harui <ah...@adobe.com>.
Peter,
I like the idea of declaring the controller as a bead in the view.
But shouldn't the controller be able to know about (have references to)
the View as long as the View doesn't know about the controller (which it
shouldn't, IMO).
The view should dispatch events (for example, converting a "click" on a
checkbox to "LicenseAcceptanceCheckboxSelectionChange" but it should be ok
for the controller to have a reference to the view to access data from
the widgets, validate them, and then apply them to the model. Passing
data via events means copying data and references and the controller code
might need other values from other widgets in the view. It also means
fewer custom event classes.
IMO:
Models should not reference views or controllers
Views should reference models but not controllers
Controllers should reference models and views.
I think there aren't circularities in that set.
Thoughts?
-Alex
On 8/17/16, 1:46 PM, "Peter Ent" <pe...@adobe.com> wrote:
>This is what I'm concluding in MobileTrader:
>
>MobileTrader has "sub-views" for WatchList and Alerts. Each of these
>sub-views has its own controller (WatchListController,
>AlertViewController) which are responsible for taking events from the view
>and updating the model.
>
>The first task is to get the controller to know about the model. We are
>talking about the model holding the data, not the FlexJS "model" which
>most components have that hold values for the component's properties. So
>I'm calling this the "dataModel". The circular dependencies are arising
>because the controllers are directly references their views and grabbing
>data out of the view.
>
>I removed the attachment of the controller to the sub-view from the CSS.
>In the view (eg, WatchListView), I explicitly name the controller bead and
>use data binding to pass in the model the controller needs to use.
>
><js:beads>
> <js:ViewDataBinding>
> <controller:WatchListController dataModel="{dataModel}" />
></js:beads>
>
>(Note: The WatchListView's dataModel is set using data binding from the
>outer MyInitialView).
>
>Then I removed all references to WatchListView from WatchListController.
>This caused several errors because WatchListController was referencing the
>view to get to the data on the screen which needed. For example, it needed
>the symbol to watch:
>
>view.symbolName.text
>
>Since WatchListController now knows nothing about the view, I created
>custom events for the WatchListView to dispatch that contained the data
>the controller needs. So when the Set button is picked, the button's event
>handler in WatchListView now does:
>
>var event: new AddSymbolEvent(symbolName.text);
>dispatchEvent(event);
>
>The WatchListController is looking for this event and can use the symbol
>value from the event without referring to the view at all.
>
>I applied this technique to the AlertsView and AlertsViewController. All
>in all, the code got cleaner and more readable. The view takes care of
>updating the view UI components and the controller takes care of updating
>the model.
>
>The pattern now works something like this:
>
>1. Give the sub-view controller bead bindable get/set methods for the
>dataModel it needs. Don't forget to add the ViewDataBinding bead to the
>sub-view class.
>2. Create custom events to pass data from the sub-view controls over to
>the controller.
>3. Have the controller set up event listeners for these custom events in
>its strand-setter; the "strand" is really the sub-view.
>4. When the view receives some user interaction, have it create a custom
>event with the data and dispatch it.
>5. The controller will receive the custom event and modify the model.
>6. The view can update the UI controls (eg, textField.text = "") after
>sending the event.
>
>For simpler projects, like the TodoListSample or DataBindingExample, the
>controller can implement IDocument and, when the "document" (aka,
>Application) is set, it can get the reference to the application data
>model and set up listeners for it.
>
>I will be checking these changes in shortly today or tomorrow (USA, EDT)
>morning.
>
>‹peter
>
>On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>>
>>Thoughts?
>>-Alex
>>
>
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
This is what I'm concluding in MobileTrader:
MobileTrader has "sub-views" for WatchList and Alerts. Each of these
sub-views has its own controller (WatchListController,
AlertViewController) which are responsible for taking events from the view
and updating the model.
The first task is to get the controller to know about the model. We are
talking about the model holding the data, not the FlexJS "model" which
most components have that hold values for the component's properties. So
I'm calling this the "dataModel". The circular dependencies are arising
because the controllers are directly references their views and grabbing
data out of the view.
I removed the attachment of the controller to the sub-view from the CSS.
In the view (eg, WatchListView), I explicitly name the controller bead and
use data binding to pass in the model the controller needs to use.
<js:beads>
<js:ViewDataBinding>
<controller:WatchListController dataModel="{dataModel}" />
</js:beads>
(Note: The WatchListView's dataModel is set using data binding from the
outer MyInitialView).
Then I removed all references to WatchListView from WatchListController.
This caused several errors because WatchListController was referencing the
view to get to the data on the screen which needed. For example, it needed
the symbol to watch:
view.symbolName.text
Since WatchListController now knows nothing about the view, I created
custom events for the WatchListView to dispatch that contained the data
the controller needs. So when the Set button is picked, the button's event
handler in WatchListView now does:
var event: new AddSymbolEvent(symbolName.text);
dispatchEvent(event);
The WatchListController is looking for this event and can use the symbol
value from the event without referring to the view at all.
I applied this technique to the AlertsView and AlertsViewController. All
in all, the code got cleaner and more readable. The view takes care of
updating the view UI components and the controller takes care of updating
the model.
The pattern now works something like this:
1. Give the sub-view controller bead bindable get/set methods for the
dataModel it needs. Don't forget to add the ViewDataBinding bead to the
sub-view class.
2. Create custom events to pass data from the sub-view controls over to
the controller.
3. Have the controller set up event listeners for these custom events in
its strand-setter; the "strand" is really the sub-view.
4. When the view receives some user interaction, have it create a custom
event with the data and dispatch it.
5. The controller will receive the custom event and modify the model.
6. The view can update the UI controls (eg, textField.text = "") after
sending the event.
For simpler projects, like the TodoListSample or DataBindingExample, the
controller can implement IDocument and, when the "document" (aka,
Application) is set, it can get the reference to the application data
model and set up listeners for it.
I will be checking these changes in shortly today or tomorrow (USA, EDT)
morning.
‹peter
On 8/16/16, 8:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
>
>Thoughts?
>-Alex
>
Re: FlexJS: Circular Dependency
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/16, 2:20 PM, "Peter Ent" <pe...@adobe.com> 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.
Thoughts?
-Alex
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
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. In these examples, the application object was being used just
to get to the model (and view in one case). For example in
DataBindingExample's MyController class:
public function MyController(app:Application=null) {
if (app) {
this.app = app as DataBindingExample;
app.addEventListener("viewChanged", viewChangeHandler);
}
}
then further down:
MyModel(app.model).requestedField = field;
The simple solution is:
private var model:MyModel;
public function MyController(app:Application=null) {
if (app) {
app.addEventListener("viewChanged", viewChangeHandler);
model = app.model as MyModel;
}
}
and further down:
model.requestedField = field;
This pattern removed the circular dependency in DataBindingExample and
TodoListSample.
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.
Let me know what you think of this approach and I'll update the code and
commit it thereafter.
Thanks,
‹peter
On 8/16/16, 10:58 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Hi,
>
>I'm taking a look at circular dependencies and developing a pattern we can
>follow. I will be changing some (or all) of the examples to use this
>pattern. I'll repost here when I have something working.
>
>Regards,
>Peter Ent
>Adobe Systems/Apache Flex Project
>
>On 8/16/16, 3:06 AM, "PKumar" <pr...@gmail.com> wrote:
>
>>can you share some examples?
>>
>>
>>
>>-----
>>Regards,
>>Prashant
>>--
>>View this message in context:
>>http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency
>>-
>>tp13287p13313.html
>>Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: FlexJS: Circular Dependency
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I'm taking a look at circular dependencies and developing a pattern we can
follow. I will be changing some (or all) of the examples to use this
pattern. I'll repost here when I have something working.
Regards,
Peter Ent
Adobe Systems/Apache Flex Project
On 8/16/16, 3:06 AM, "PKumar" <pr...@gmail.com> wrote:
>can you share some examples?
>
>
>
>-----
>Regards,
>Prashant
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-
>tp13287p13313.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by PKumar <pr...@gmail.com>.
can you share some examples?
-----
Regards,
Prashant
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287p13313.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by xenia1234 <mw...@healthpi.com.au>.
I used interface instead of the actual class. This works for me.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287p13309.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: FlexJS: Circular Dependency
Posted by Harbs <ha...@gmail.com>.
Add this argument:
-remove-circulars
On Aug 15, 2016, at 1:59 PM, PKumar <pr...@gmail.com> wrote:
> Hi,
>
> I am trying to cross compile FlexJS example "TodoListSampleApp" but getting
> the circular dependency error. Please check the attached screen shot. How
> can i remove this error?
>
> <http://apache-flex-users.2333346.n4.nabble.com/file/n13287/error.jpg>
>
>
>
>
>
>
> -----
> Regards,
> Prashant
> --
> View this message in context: http://apache-flex-users.2333346.n4.nabble.com/FlexJS-Circular-Dependency-tp13287.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.