The changes look like they should be over-all improvements. Like you say, we 
will have to see how they play out.

There might be a need to easily flip position between absolute and relative, 
but we’ll see.

I’m looking forward to seeing how the changes behave. :-)

Harbs

> On Mar 23, 2017, at 7:27 PM, Peter Ent <p...@adobe.com> wrote:
> 
> FlexJS Container and Layout Upgrade
> 
> My goal when starting this process was to have FlexJS produce leaner HTML 
> structures and to reduce the amount of JavaScript code getting 
> cross-compiled. My latest commit does the following:
> 
> - Produces simpler HTML structures for the container classes, Group, 
> Container, and Panel.
> - Simplifies a number of the layout classes for JS while fixing or tuning the 
> SWF code to mimic the browser.
> - Moves code that only affects the SWF side into SWF code blocks.
> 
> I touched only Core and HTML projects and fixed Effects so it would compile 
> since it had the fewest issues. MDL and Charts have larger concerns and I 
> hope to sort those out as quickly as I can.
> 
> Here are the classes and changes you will find:
> 
> Group: This new class (introduced in a previous commit) produces the simplest 
> container for HTML (it is just a DIV) and SWF. By default it provides no 
> layout in case you want to style in completely using CSS. Group (and its view 
> bead, GroupView), are the foundation of the container classes. Group runs a 
> layout bead (if there is one) and handles the sizing of elements on the SWF 
> side. The JS side is left alone for the browser to manage (this was the 
> biggest change).
> 
> Container: This class, which extends Group, exists to provide scrolling on 
> the SWF side. The JS side of Container is very light adds little to what 
> Group does. On the SWF side, Container is a nested structure in order to 
> providing content masking and scrolling (which is handled on the JS side by 
> using overflow:auto style, which is all the ScrollingViewport bead will do if 
> you add it to Container).
> 
> UIBase: The major change to UIBase is that it no longer sets the position 
> style. That means if you set the x and y properties of a component, it will, 
> on the JS side, only set the left and top style values. If you intend to 
> place elements at specific pixel coordinates, use a container (Group or 
> Container) with BasicLayout which will add position:absolute style to all of 
> the children.
> 
> NOTE: I made UIBase (and a couple other classes, too) not set position style 
> because I saw how easily that caused other problems, especially when there 
> was a mixing of "absolute" and "relative" position values. Now that this work 
> is done, it may not be a bad thing to have UIBase's x and y properties set 
> position:absolute has a convenience. It does however, have some 
> ramifications; if you have position:absolute that will override pretty much 
> all of the layout types. But maybe the developer just sees this and stops 
> setting x and y. Also, there is no way to unset position once set. These are 
> things we will have to see how they play out.
> 
> Layouts: The layouts no longer change the size of their container hosts nor 
> do they produce the "layoutComplete" event. The GroupView class handles both 
> of these now to make the process of layout and sizing/positioning consistent.
> 
> Lists: The DataGroup that lists use to hold the item renderers is no longer 
> in play. The DataGroup caused unnecessary nesting of elements (DIV inside of 
> DIV). To break that, components like List had to become their own item 
> renderer parents. Squaring this away is perhaps the biggest challenge since a 
> number of complex components use List as their base. The DataContainer is now 
> the basis for lists, with List being its first subclass since they have so 
> much in common. The DataContainerView bead is now the basis for all list 
> views.
> 
> Panel: The Panel is now an extension of Group and it contains three children: 
> a TitleBar, a ControlBar (for PanelWithControlBar), and a Container for the 
> content space. When you do: panel.addElement(object), the Panel code 
> redirects this to its Container child. Similarly, panel.numElements tells you 
> the number of elements in the Container child. Because Panel is now a Group 
> (so are TitleBar and ControlBar), it uses a layout to size and position those 
> three children. When you build your own components, you can use Group + 
> layout to achieve the look you want with minimal HTML structure.
> 
> Interfaces: There are couple of key changes to interfaces. First, there is a 
> new interface in the Core project: ILayoutView. This interface is implemented 
> by any component whose children can be manipulated by a layout. The 
> ILayoutHost interface's function, contentView, has been changed to return an 
> instance of ILayoutView. The functions listed in ILayoutView may be expanded 
> if we run into situations or layouts that need more information from their 
> layout parents; this change is probably the source of most compilation issues 
> you will see.
> 
> Using Layouts inside of Components: As stated above, Panel (and 
> PanelWithControlBar), now uses a layout for its own purposes. This is the 
> VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose CSS 
> creation makes the code much simpler and cleaner. Basically, the JS layout 
> code is a few lines with maybe a loop to set each child's display correctly. 
> The SWF side then has the task to mimic the layout. I have not completed the 
> transition on all of the layouts, but the common ones have tested correctly.
> 
> Regards,
> Peter Ent
> Adobe Systems/Apache Flex Project
> 

Reply via email to