FlexJS Layout

The current Flex SDK used a 3-phase, optionally frame-delayed validation mechanism.  Two phases were top-down, one phase was bottom up.  The idea was to handle any change anywhere.  Also percentages were defined as a percentage of non-fixed area in a container.  Just about every object that didn’t have both explicit width got measured because measurements helped define the minimum sizes for things with percentage widths and heights.

This system worked well, but had some annoying issues:

• Folks were often surprised that things didn’t shrink as expected because of the minimum size calculation for things with percentage sizes
• You could get into “invalidation/validation loops” where the size of things would compute to be different on each layout pass
• Time was spent measuring things and often those measurements weren’t used
• Time was spent setting up event listeners for changes that never got used.
  
  

When looking into a layout system for FlexJS, the above were considered, as well as:

• There is no frame mechanism in the browser.  If you change a display property it shows up right away
• Percentages in the browser/CSS work differently.  They are a simple calculation on the parent’s size.

FlexJS Layout

1. The child is sized by the parent
2. The component is sized by its content
3. The component has explicitly set width AND height.

If the component has only an explicitly set width but not height and vice versa, then the component falls into scenario 1 or 2 based on whether the unspecified dimension has a percentage set on it or not.

Another, more subtle principle, is that width is slightly more important than height.  That’s the way browsers seem to work, so if a choice has to be made, the layout will try to determine the width before the height.

Unlike the current Flex SDK, percentages are a strict percentage of the parent’s size.  No attempt is made to figure out what things can be shrunk or stretched.  This saves having to loop through the children twice: once to figure out how much room there is, and a second to shrink or stretch things.

And unlike the current Flex SDK, a parent does not watch its children’s display properties for changes, so if the height and/or width of some child object changes, the parent and its parent's may not re-layout.  You may have to dispatch a “layoutNeeded” event or use an MXML tag to cause the dispatching of a “layoutNeeded” event.  If we start to see common scenarios where everyone is setting up these update events, we may build them in somehow.  For example, the Image and ImageButton components force a layout in their parents when the image content arrives since that is a common pattern.

This fits with the FlexJS  “just-in-time” instead of “just-in-case” philosophy.  In the dozens of containers and components in FlexJSStore, only 3 “layoutNeeded” events are required.

So when does a component get laid out?

It depends.  Components that don’t have any percentage or explicit dimensions, including width and height CSS styles, or both ”left" and “right" CSS styles, or both “top” and “bottom” CSS styles are considered to be in category 2 and sized when the set of children changes.  When setting up from MXML, all of the children are added then a single childrenAdded event is dispatched to kick off the layout.  When using AS APIs, the childrenAdded event is dispatched as children are added.  You can suppress the event if you are changing lots of children if you remember to dispatch the event yourself when done.

Children who have both an explicitly set width and height are also laid out when the children are added.

All other children theoretically have at least one dimension that is relative to the parent’s size.  At the beginning of the application, the default Application class sets the initial view to the size of the Flash Player or Browser window.  This generally causes a single top-down pass through all of the children that weren’t already sized to content or sized explicitly.

When done, if a dimension is sized to content, the layout sets the size of that dimension.

Layout Guidelines

ActionScript vs JavaScript

When creating your own layout, take advantage of the platform's abilities. Keep in mind that the ActionScript version of a layout mimics what you can do with HTML. The VerticalLayout, for example, just sets the HTML elements that back the FlexJS components to have a display style of 'block' so they appear on separate lines. 

The ActionScript version of a layout may be more complex since it has to do more work. The ActionScript version of VerticalLayout is more complex and provides a really good example of how to write a layout.

You may be able to create layouts which can be cross-compiled from ActionScript to JavaScript, but you may get better performance if you write native JavaScript layouts.

Composition

Layouts work within Containers. A Container has an area called the "contentView" where the items go that are being laid out. The contentView is managed by a Viewport which is responsible for the size and position of the contentView. If a Container is being scrolled, a ScrollableViewport is used instead of the plain Viewport.

Sizing

As mentioned above, Containers may be sized explicitly or by their content. This can happen in either or both dimensions (for example, a Container that specifies a width and not a height). When a Container is being sized by its content, the layout is used to determine the Container's size by calculating a bounding box that surrounds the children once the layout has been run. 

Some layouts need to know the amount of space they have to work with. The contentView can provide that through its width and height properties. When a Container is being sized by its content, the layout may not get valid width and/or height values from the contentView. In this case, the layout must assume the Container is infinitely wide or tall or the layout can make some assumptions and impose its own constraints.

Layouts such as VerticalLayout and HorizontalLayout do not depend on the Container having a size. These layouts simply follow an algorithm and position the children which makes them ideal candidates for Containers whose size must be determined by the content.

Padding and Margin

It is the responsibility of the layout to handle offsets introduced by padding and margin styles. Again, the JavaScript layout should probably default to letting HTML handle this.

If you look at the ActionScript version of VerticalLayout, you'll see how padding and margin values are obtained from the components and used to calculate the placement of the items in the layout. Your layout may need to do the same thing if it is to respect padding and margin when your application is run from Flash.

Custom Container Views

Using a Container as a base for a new component is often a good idea if you want to take advantage of layouts. In FlexJS, the majority of the work of a component is handled by its view bead. For Containers, this is the ContainerView bead. When creating components based on Container, you will most likely need to extend ContainerView. 

Use PanelView as a guide to building your own custom ContainerView.

If your component contains other elements which are not be affected by the layout, you may need to override some methods to adjust the placement of the contentView to allow room for your additional pieces. In FlexJS, these additional pieces are referred to as "chrome" and must implement the IChrome interface which merely declares them to be a chrome element. When chrome elements are added to a Container, they become children of the Container itself and not the content view.

These are the general steps for extending ContainerView and overriding some functions.

1. Create your custom view by extending org.apache.flex.html.beads.ContainerView.
2. Override the strand setter function if you need to keep a reference to the strand.
3. Override getChromeMetrics to return a org.apache.flex.geom.Rectangle that accounts for the additional chrome pieces you are adding.
4. Override layoutViewAfterContainerLayout to size and position your chrome pieces and then call the super function.

Custom Content

The Container class uses a simple component, ContainerContentArea, for the contentView, to hold the elements to be displayed and arranged by the layout. The FlexJS framework automatically adds any elements specified in MXML to the contentView. If your component needs to generate, or programmatically fill, the content of a container, you may want to consider creating a custom contentView.

The List and chart components are examples of doing this. The List extends Container, but it also provides a special contentView called DataGroup, which is designed to work with item renderers. The List then uses the VerticalLayout to present the item renderer instances.

The chart components use ChartDataGroup which is designed to work with the graphic elements of the chart; charts use their own layouts to make each chart type.

To replace a Container's content view:

1. Create the custom content view by extending org.apache.flex.html.supportClasses.ContainerContentArea. 
2. Add the functions you need to create the content.
3. In the CSS Style definition for your class, add IContentView with a ClassReference that names your custom content view.

Conclusion

FlexJS provides a number of ways to achieve a custom look in an application. You can use the common Container component with custom layouts or extend ContainerView and add more elements or use a combination of custom view, custom layout, and even a custom contentView. Use the FlexJS component library for examples.