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>
