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 >> >
