On 9/16/16, 1:54 PM, "OK" <p...@olafkrueger.net> wrote:
>Honestly I'm a bit confused about the discussion:
>>My understanding is that you can set the initialView property of the app
>runtime to use a different view.
>Do you mean the ability to replace the initialView including all its sub
>views at runtime?
>Similar as in Flex where we able to add and remove view components?
>I thought it would be the same in FlexJS?
Currently, the Application class expects to hand the View its model at
startup. It isn't planning on handing a new view the model or listening
for changes to which View is assigned as initialView.
The View's children can be replaced as you would in any regular Flex app.
More sophisticated Application classes could be built
(MultiViewApplication) that allow replacing the initialView at runtime. I
have no idea if folks will need that or not, since it is pretty easy to
change the children in the View. But if they need it, someone will build
it. A "new rule" for FlexJS is that there isn't supposed to be just one
Application class or one Button. There can be different flavors for
different purposes. If you build in the possibility of every purpose into
a single Application, you don't get pay-as-you-go (PAYG), you get fat apps.
>>It might be better to just remove every from "and they can".
>What do you mean with this?
That you could trim that sentence to read:
"Your user interface is placed into views."
>>The Application is designed for simple one-view apps.
>>More sophisticated application structures are certainly welcome in FlexJS
>Does this mean FlexJS is designed for simple apps????
>I thought the initial view is just a container for any number of sub
FlexJS is designed for simple and complex apps. In order to make sure we
are PAYG, we are starting with simple apps and building upward. As I
mention above, no need to have a ton of code to handle complexity if you
don't need it. All of our examples so far don't need to change the
initialView, just what is inside it.
>>It turns out you can just bake the View into the main
>>MXML file. If folks think that is more approachable, we can start
>>reworking our examples so they are one-file applications.
>Do you mean that's a good idea to paste all mxml of an app into one file
>instead of building encapsulated, reusable view components?
From a reusability perspective, no it isn't a good idea to inline stuff,
but from a "getting started" it might be. Flex demos were all about
"build an app in 10 minutes" and were one-file apps. Not sure if that
helped adoption or not. For sure, it enabled folks to write some really
bad code they were sorry for later. So when I first put together FlexJS
demos I tried to make the MVC and multi-file, but it does seem like more
work than slapping a proof-of-concept together in one file. Sounds like
you favor the multiple-file pattern which is totally fine with me. What
do others think?
>Maybe we've a different understanding of the view "term" in this context
>here, but I'm still confused.
>Please enlighten me..
Right now "view" is a single container for the UI widgets where it is
specially treated by Application by sharing the app's model. In
MobileTrader, the view contains a TabbedNavigator and StackNavigator. I'm
not sure if that's right or if there should be a different Application
class that somehow bakes in a TabbedNavigator, doesn't have an initialView
property because the Navigator takes views (or some other component) as
children. We don't have to decide, we can always just build the other