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" <[email protected]> wrote: > >On 8/18/16, 7:21 AM, "Peter Ent" <[email protected]> wrote: > >>More thoughtsŠ >>‹peter >> >>On 8/17/16, 7:10 PM, "Alex Harui" <[email protected]> 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> >
