On 2/24/17, 11:42 AM, "Peter Ent" <p...@adobe.com> wrote:
>Hi, > >I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout >that adds code for the SWF side. In general, the SWF and JS sides look the >same. There are some differences which I'm working on, but these should be >usable. Sounds promising! > >In doing this I've uncovered some incomplete work and/or exposed some >issues. These are, in no particular order: > >UIBase vs. IUIBase. Since some of our components do not inherit from >UIBase, you cannot cast everything to this class. Now as we should really >use interfaces and not classes, casting to IUIBase generally works. >However, IUIBase is missing a lot of useful function prototypes which is >why there is a lot of casting to UIBase. I'd like to see IUIBase become >more complete. The layout code does a lot of extra, unnecessary casts on >the SWF side. IUIBase is intended to be the minimum interface for being a displayable object. Interfaces should be PAYG just like everything else. Some displayable objects will never be subjects of a re-usable layout algorithm. Some code will simply create two IUIBases and place them at known locations. Like in the up/down buttons in a NumericStepper. There should be other interfaces already like ILayoutXXX that are meant to be the contract between layouts and parents of children. Layout classes should be using those interfaces instead of UIBase. Feel free to composite interfaces into a single "uber" interface, but be careful about making the contract too difficult or heavy. > >JS vs SWF layouts. When you think about it, once you've set up your <div> >to have the property display style, adding/removing/changing elements gets >taken care by the browser. If I set up my <div> with display:flex and then >put in a number of elements and start changing them via JavaScript, they >just change. Of course that doesn't work on the SWF side because there >isn't anything to size and position elements except the layout algorithms. >But the events that trigger those algorithms to execute are in the >Container class which causes the layout - SWF or JS - to execute. >Basically, it seems unnecessary to re-execute JS layouts every time since >the browser does the work. I think this should be revisited. The JS side of layouts should only be listening for child added/removed if they need to touch the child in some way (set a display style or position:relative). Otherwise yes, JS layouts do not need to run on added/removed changes. > >Padding. This still isn't working right for the Container with layout. >Part of the problem is that padding on the SWF side isn't really padding. >What it does it offset the inner contentArea. This was done so that when >you have a Container with padding=10 and you place a child into it, the >child's (x,y) reads as (0,0) and not (10,10). When I did a test with a ><div> that had padding:10px, the first item in it reported left:10, >top:10. So I wonder if we shouldn't treat padding the same way? Padding should work the same between JS and SWF. I think once we switched to border-box we never verified how the coordinate system worked. But also keep in mind Panel and chrome-containers and how they will need to work. My 2 cents, -Alex
