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 >
