Understanding Styles

Introduction

The UIManager framework uses a different set of style rules than the UIComponent.

Why? The answer is simple, the base class UIManager is not a UIComponent. So it has no way of knowing about style changes or creating style proto chains.

This does allow for a new way of getting styles through a static manager. Also, since the manager is not tied into the display list, it has the ability to use a different style routine than a UIComponent.

There are three major branches that a UIManager will use to find it's styles as it is operation on the currentClient or currentClients. These braches are listed in order of importance from least to greatest.

1. The manager's TypeSelector
   • ResizeManagerFX {}
2. The client or parent styleName
   • myList.styleName = "resizeStyles"
3. The manager's styleName
   • resizeManagerStyleName or moveManagerStyleName
4. The client or popUp styleName located in the manager's styleName
   • clientStyleName or popUpStyleName

Style Precedence

Take the style sheet mock up below;

The mxml

<mx:List id="myList" 
	styleName="baseComponentStyles"/>

The css

.canvasStyles {
	/* Precedence #1 */
	resizeManagerStyleName:"canvasResizeStyles";	
}
 
.canvasResizeStyles {
	/* 
		Precedence #2 
		!!! IF nested styleNames are not present 
	*/	
	clientStyleName:"canvasClientResizeStyles";
	popUpStyleName:"canvasPopUpResizeStyles";
}
 
.canvasClientResizeStyles {
	/*
		Precedence #3
		Any style found here overrides all
	*/
}
 
.canvasPopUpResizeStyles {
	/*
		Precedence #3
		Any style found here overrides all
	*/
}
 
ResizeManagerFX {
	/* Precedence #4 */
}

Understanding style precedence

In the mock up example above, we have 4 branches in a style search of a manager.

1. The actual styleName of the client.
2. The manager styleName of the client styleName.
3. The client or popUp styleName of the manager styleName.
4. The manager's TypeSelector that holds all of it's default styles.

Precedence #1

In the #1 search, all styles found here will override any style set with a lower precedence.

Note :: This also includes using the setStyle() call on the client. This will effectively place that style in precedence #1. Also, if you set a style in the client's TypeSelector IE List{}, that style will fall into this category so be careful setting styles there that you would want to override later.

Precedence #2

In the #2 search, this means the style was not found in the #1 search. These styles set here are specific to the manager's styleName. For the move and resize managers, the styleNames are;

• moveManagerStyleName
• resizeManagerStyleName

This styleName is where you place the clientStyleName and popUpStyleName if you want to differentiate between client and popup look and feel.

Note :: If you set either of these two styleNames here, if a style is defined in either of them it will override a style set in this styleName.

Precedence #3

In the #3 search, the manager is looking for styles that are individual to the popUpOverlay and clientOverlay. If any style is found here in a search it will override all other styles set in the styleChain.

Precedence #4

In the #4 search, the manager will either use it's defaulted styles or a style you set here in an override.

Client - Parent cascade

When the manager is working with specific clients or a queue of clients, it will search the branch in order of 1, 2, 3. If a style is not found here, the manager resumes it's search using the parent of the client or currentParent within the manager and repeats the search 1,2,3. This means that you can set a style name on a canvas that will affect all of it's children without having to set the styleName of all the canvas's children.

If a style is not found after this parent search, the manager will then use #4 search of the TypeSelector.

This functionality is needed for some of the more complicated managers we have created that use queues of clients thus, the need for parent style checks. This cascading also saves the developer tedious styleName setting.

Style Caching

The UIManager framework caches all styles used in an operation at the very start of the operation call.

Conclusion

The UIManager framework offers a very rich set of style searching to make it easy for the developer to customize, load styles and use parent containers for client styles.