For full constrained layouts like we had in regular Flex, we’re probably going to need to use absolute positioning and JS to set the top/left values. But I’d love to see how far we can get with just CSS...
> On Mar 23, 2017, at 8:13 PM, Peter Ent <p...@adobe.com> wrote: > > I want to make a layout that uses left, top, right, bottom for > positioning. The JS side is easy of course, you do nothing! > > On 3/23/17, 2:11 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> 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 >>> >> >
