I don't think a model/view/controller is too much bloat. Don't underestimate the value of consistency. Scrollbars, borders, etc. don't have to be there as long as there is a way for an app developer to manipulate them, which can be done with styles. Models and controllers are different though, I think. I just don't want people to be frustrated using FlexJS.
I'm under the impression we are advertising the MVC-ness of FlexJS. When we write an app the examples show models. Now maybe we just say that application's have models and controllers, but I'd start to extrapolate that in my head. Then when I wanted a custom component by extending something that already exists, I'd see that it had a model and might want to make use of it. —peter On 8/9/16, 11:08 AM, "Alex Harui" <aha...@adobe.com> wrote: >IMO, we don't want to bloat the JS just for consistency sake. The SWF >side will have lots of hidden parts for borders, scrollbars, etc. For >many components, most folks will only interact with the wrapping component >(Checkbox, Button, Label, etc). So most folks won't know that Image has a >model/view or not, and to add another property would probably subclass it. > >I considered an extension of Image that caches images, or an extension >that does scaling, photo effects, etc. Should we use extensible models >and views to support those cases? > >-Alex > >On 8/9/16, 7:30 AM, "Peter Ent" <p...@adobe.com> wrote: > >>I think you need to be consistent for models and views and follow the >>pattern. Every component should have a model, view, and controller unless >>having such a thing on all platforms makes no sense. >> >>Imagine I'm an application writer and I want to make a component with an >>image that displays differently as part of some data I get from a server >>(an example so that you can't use states). I might want to add a new >>property to the Image component's model and then extend Image so that it >>encapsulates the use of that property. >> >>If I don't have access in my application code to the model when it >>cross-compiles to JS, then I'm out of luck and I scratch my head >>wondering >>why I can code it but it then won't compile for JS and yet does compile >>for SWF. >> >>So I would go through the components and make sure everything had >>model/view/controller, at least. An image probably does not need a >>controller, but someone might want to have an image flicker when a mouse >>was rolled over it, or dim or something. And in this case, do we advocate >>that the developer change the source property on the image via the >>controller or do we advocate that the developer have the controller >>access >>the model and change it there? We need a consistent story. >> >>‹peter >> >>On 8/9/16, 2:30 AM, "Alex Harui" <aha...@adobe.com> wrote: >> >>>Maybe check when it got added to the JS side. There might be a reason. >>>Peter may remember when he starts up in a few hours. >>> >>>On the SWF side, for things like Button, separate models and views are >>>part of the extensibility pattern. Going back to the expanded form, a >>>TextButton would be something like: >>> >>><js:UIBase> >>> <js:beads> >>> <js:TextButtonModel text="Click me" /> >>> <js:TextButtonView /> >>> </js:beads> >>></js:UIBase> >>> >>>To make an icon and text button, you would do: >>> >>><js:UIBase> >>> <js:beads> >>> <js:TextAndIconButtonModel text="Click me" icon="foo.png"/> >>> <js:TextAndIconButtonView /> >>> </js:beads> >>></js:UIBase> >>> >>>But all of that is how the SWF side builds up to emulating the HTML >>>button >>>element. On the HTML side, we just use the element. >>> >>>If you can make the argument that Image is not extensible (won't ever >>>need >>>new properties) then you can take out the model and view on the SWF >>>side. >>>On the JS side, I think we can take it away since we can directly store >>>what is in the model in the element and the element does the view's work >>>of layout/presentation. But again, I might be missing something, so >>>let's >>>see if Peter remembers. >>> >>>-Alex >>> >> >
