Chimp is a simple component for doing role based permissions in Flex.  It uses metadata and a generic ArrayCollection of permission strings to display the proper components for a given set of user roles.  You can find more info about the project at: http://www.gorillalogic.com/chimp.

Flex 4 Update

Shortly after I posted Chimp in 2009, Adobe began releasing early versions of Flex 4.  Every since then, I am occasionally asked about Chimp’s Flex 4 compatibility.  Well, I finally stopped procrastinating and posted a Flex 4 sample on the google code site.  It’s a conversion of the existing Flex 3 sample.  Everything worked with no updates to the existing Chimp swc.

Please let me know if you are having in Flex 4 specific issues.

Our Dream

We admit v0.5 is not much to look at but imagine a future where a huge number of robust, well tested layouts (both 2D and 3D) exists and is readily available with both sample code and exceptional documentation. You could just slap together some vanilla Flex components, drop in an awesome custom layout (like Gilles’ CoverFlowLayout), and ka-BOOM, you have an awesome custom component that impresses co-workers, bosses, and clients equally. That’s the dream: to take one of the most portable, re-usable pieces of the Flex framework, make a massive library, and empower the next generation of custom components.

Ransom Note

I whipped together a quick sample application using FlowLayout that I’m calling Ransom Note. It pulls together a list of images of letters that look as if they were cut out of a magazine or newspaper and pasted together. It follows one of the most common custom layout patterns which is: List + ItemRenderer + custom layout. The actual implementation uses the lighter weight version: DataGroup + DataRenderer + custom layout, because I don’t need any of the list selection stuff.

Check out the finished product:

» RansomNote (view source enabled)

Files

• RansomNote (download)

Extend TabBar and TabBarButton

I just want to build your average web browser tab in Flex 4, no more, no less. Browser tabs have two cool features: each tab has a close button, and the tabs can be reordered by dragging. Actually, I just lied about the no less part, because I’m going to ignore dragging and focus my attention on the closeable tab part. Please see my previous post on drag-and-drop in Flex 4 if you are interested in the dragging part.

A TabBar is just a bag of tabs, where each individual tab is a button, or a TabBarButton to be more precise. To create a closeable tab, we need to add a new button that can be clicked to close the tab, duh. And this is in addition to the default behavior of clicking the tab to select it. Since we are disciples of The Flex 4 Way of building custom components, we know this means we must extend TabBarButton and add a new Button SkinPart to it:

package components {
    ...
 
    public class TerrificTabBarButton extends ButtonBarButton {
        [SkinPart(required="false")]
        public var closeButton:Button;
 
        private var _closeable:Boolean = true;
 
        public function TerrificTabBarButton() {
            super();
 
            //IMPORTANT: this enables the button's children (aka the close button) to receive mouse events
            this.mouseChildren = true;
        }
 
        [Bindable]
        public function get closeable():Boolean {
            return _closeable;
        }
        public function set closeable(val:Boolean):void {
            if (_closeable != val) {
                _closeable = val;
                closeButton.visible = val;
                labelDisplay.right = (val ? 30 : 14);
            }
        }
 
        private function closeHandler(e:MouseEvent):void {
            dispatchEvent(new TerrificTabBarEvent(TerrificTabBarEvent.CLOSE_TAB, itemIndex, true));
        }
 
        override protected function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == closeButton) {
                closeButton.addEventListener(MouseEvent.CLICK, closeHandler);
                closeButton.visible = closeable;
            } else if (instance == labelDisplay) {
                labelDisplay.right = (closeable ? 30 : 14);
            }
        }
 
        override protected function partRemoved(partName:String, instance:Object):void {
            super.partRemoved(partName, instance);
 
            if (instance == closeButton) {
                closeButton.removeEventListener(MouseEvent.CLICK, closeHandler);
            }
        }
    }
}

First, we have the closeButton SkinPart and it’s closeHandler() event handler. Wiring the handler function to the button is done in the partAdded() override, and un-wiring in the partRemoved() override. The handler just bubbles a closeTab custom event which will be handled by the parent TabBar. Next, we use the closeable property to manage the close button’s visibility. Finally, an additional button visibility check is necessary in partAdded() to set the initial visibility.

There are two other interesting pieces of code. One, we must set mouseChildren = true in the constructor to enable our button within a button to receive and respond to mouse events. Two, in a somewhat hackish fashion, I add or remove padding from the tab’s label when the close button is present or not.

Now that we have a nice close button on the individual tabs, we extend TabBar to make a pretty API for managing tabs and their new functionality. Here is an abbreviated TerrificTabBar component showing the relevant public methods:

package components {
    ...
 
    public class TerrificTabBar extends TabBar {
        public function TerrificTabBar() {
            super();
        }
 
        public function setCloseableTab(index:int, value:Boolean):void {
            if (index >= 0 && index < dataGroup.numElements) {
                var btn:TerrificTabBarButton = dataGroup.getElementAt(index) as TerrificTabBarButton;
                btn.closeable = value;
            }
        }
        public function getCloseableTab(index:int):Boolean {
            if (index >= 0 && index < dataGroup.numElements) {
                var btn:TerrificTabBarButton = dataGroup.getElementAt(index) as TerrificTabBarButton;
                return btn.closeable;
            }
            return false;
        }
 
        private function closeHandler(e:TerrificTabBarEvent):void {
            closeTab(e.index, this.selectedIndex);
        }
 
        public function closeTab(closedTab:int, selectedTab:int):void {
            ...
        }
 
        protected override function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == dataGroup) {
                dataGroup.addEventListener(TerrificTabBarEvent.CLOSE_TAB, closeHandler);
            }
        }
 
        protected override function partRemoved(partName:String, instance:Object):void {
            super.partRemoved(partName, instance);
 
            if (instance == dataGroup) {
                dataGroup.removeEventListener(TerrificTabBarEvent.CLOSE_TAB, closeHandler);
            }
        }
    }
}

There is a public getter and setter for toggling the close-ability of individual tabs, setCloseableTab() and getCloseableTab(). And also a public method for closing a tab, closeTab(), which can be used to force close an un-closeable tab. Additionally, closeTab() is used internally to close a tab when its close button is clicked. As is standard, the wiring and un-wiring of the closeHandler() handler function is done in the partAdded() and partRemoved() overrides.

Very vanilla, but there is one interesting part worth mentioning. I made the decision to attach the listener to the dataGroup property of TabBar, this is the default container of individual tabs (aka TerrificTabBarButtons). Yes, I could just as easily have attached the handler directly to TabBar in the constructor and used weak references. But after having built enough custom Flex 4 components, it feels funny to me to do any event wiring outside of partAdded() and partRemoved(). Thus, I made the decision to attached to dataGroup. Without doing a bunch of testing (which I haven’t done), I can’t say if this is better or worse from a memory or performance perspective, I just like the way this code looks better.

Conclusion

I put a pretty skin on everything using some of my favorite drawing tricks, but that’s the subject of a future post. Some brief highlights include:

• I used CSS to wire my components to my skins, so I minimize the use of skinClass attributes for better decoupling
• I used a big negative gap in TerrificTabBarSkin to make the tabs overlap
• I set a maxWidth and a minWidth on the individual tabs in TerrificTabBarButtonSkin, which in combination with maxDisplayedLines="1" on the Label, make the tabs truncate with ... when they get too big
• The curved tab shape is drawn with a Path, but I wrap it with a Group and set the Group‘s scale-9 grid (scaleGridLeft, scaleGridTop, etc.) so it expands and contracts correctly
• The close button’s x is drawn as a + around the coordinate origin, also known as (0,0), and then rotated 45 degrees

Here’s the finished product (view source enabled):

Use it and enjoy.

Files

• TerrificTabBar (download)

SuperTextInput is a prompting, clearable TextInput extension in Flex 4. It’s just an enhanced version of the default TextInput control, and as such, it follows a fairly standard pattern of custom component creation.

Enhanced Component Pattern

It’s almost too stupid to call this a pattern, but it’s so common in custom component creation that I’ll run with it. Also, I’ve found it to be worthwhile to distinguish between adding new functionality to a component already present in the framework (aka an enhanced component) versus creating a truly custom component.

The enhanced component pattern is just two simple steps:

1. Extend – extend some default component and add some new functionality
2. Skin – make it look good

In my version of reality, these steps carry equal weight, because almost all worthwhile functionality in Flex touches the UI in some fashion, so the design and UX (the look-and-feel, it’s usability, the integration into the rest of the app, etc.) are critical. Don’t forget or skimp on step #2 because it’s all the client, team, customer ever sees.

A Prompting TextInput

Since SuperTextInput has two new pieces of functionality (the prompt and the clear button), I’ll split them apart, and consider each part separately. First, the prompt is merely the text you see when the TextInput is empty. It often becomes a space saving label, because it can be used to tell the user what goes into the TextInput without costing the UI any screen real estate.

Thinking more about the prompt, we want the prompt text to be visible initially, but it should disappear when the user clicks (or tabs) to the control, and only returns when the control loses focus and is still empty. So this tells us that we need to communicate both the prompt text and it’s visibility to our skin. The prompt text can just be a simple Label SkinPart, but it’s visibility is complicated enough that it makes sense to add a new prompting SkinState.

Here’s a functioning PromptingTextInput custom component (which is simply the prompting code lifted from SuperTextInput.as):

package components {
    import flash.events.FocusEvent;
    import mx.events.FlexEvent;
    import spark.components.Label;
    import spark.components.TextInput;
    import spark.events.TextOperationEvent;
 
    [SkinState("prompting")]
    public class PromptingTextInput extends TextInput {
 
        [SkinPart(required="false")]
        public var promptDisplay:Label;
 
        private var _prompt:String = '';
        private var _focused:Boolean = false;
 
        public function PromptingTextInput() {
            super();
 
            //watch for programmatic changes to text property
            this.addEventListener(FlexEvent.VALUE_COMMIT, textChangedHandler, false, 0, true);
 
            //watch for user changes (aka typing) to text property
            this.addEventListener(TextOperationEvent.CHANGE, textChangedHandler, false, 0, true);
        }
 
        [Bindable]
        public function get prompt():String {
            return _prompt;
        }
        public function set prompt(value:String):void {
            if (_prompt != value) {
                _prompt = value;
                if (promptDisplay != null) {
                    promptDisplay.text = value;
                }
            }
        }
 
        private function textChangedHandler(e:Event):void {
            invalidateSkinState();
        }
 
        override protected function focusInHandler(event:FocusEvent):void {
            super.focusInHandler(event);
            _focused = true;
            invalidateSkinState();
        }
        override protected function focusOutHandler(event:FocusEvent):void {
            super.focusOutHandler(event);
            _focused = false;
            invalidateSkinState();
        }
 
        override protected function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == promptDisplay) {
                promptDisplay.text = prompt;
            }
        }
 
        override protected function getCurrentSkinState():String {
            if (prompt.length > 0 && text.length == 0 && !_focused) {
                return 'prompting';
            }
            return super.getCurrentSkinState();
        }
    }
}

In addition to the promptDisplay SkinPart and the new prompting SkinState, there is a lot of other stuff going on in the above code. First, as is typical with data-driven SkinParts, we back the promptDisplay with a good old prompt property. The net is the fairly common pattern of: check if the SkinPart is not null, then do something to it. So in the prompt setter, we assign the incoming value to the private _prompt variable, then check if promptDisplay is available and if yes, set it’s text property. The setter does the job of updating the prompt, but only once everything is happily running. In order to get the data to the skin initially, we must use the partAdded() override to pass the local prompt to the promptDisplay‘s text property. And that’s it for the prompt text.

The prompt visibility part requires lots of event watching, and also SkinState stuff because we made the choice to push visibility via the prompting SkinState. First, we wire up both the programmatic text change events and the user text change events to a handler, textChangedHandler(), that does nothing more than invalidate the state. TextInput change events are a little wacky, but the code works fine. Next, instead of wiring the focus events to another handler (as seen in this prompting TextInput component by Andy McIntosh), we simply override the protected handlers in the parent and add our focus-tracking logic directly. Finally, we override getCurrentSkinState() to do the work of figuring out whether or not the prompt should be displayed.

A skin for PromptingTextInput is now trivial because our component does the work of pushing the important information to the skin. If we ignore all the pretty stuff, the skin is very simple:

<?xml version="1.0" encoding="utf-8"?>
<s:SparkSkin ...>
    ...
    <s:states>
        <s:State name="normal"/>
        <s:State name="prompting"/>
        <s:State name="disabled"/>
    </s:states>
 
    <s:RichEditableText id="textDisplay" ... />
    <s:Label id="promptDisplay" includeIn="prompting" ... />
</s:SparkSkin>

We add the prompting State to the list of states and also add the promptDisplay Label component. By using the standard inline state syntax, includeIn="prompting" our Label is shown only in the prompting state.

A Clearable TextInput

The second piece of SuperTextInput functionality is the clear button. The clear button appears when the TextInput has a value, and when clicked, it clears that value (which re-displays the prompt). Again, there are two pieces of information the need to be communicated to the skin to create the clear button functionality: the button itself and it’s visibility. In this case, since the visibility is so simple (on if TextInput has a value, otherwise off), we’ll just punt and manage it directly in the component. Therefore, the only a Button SkinPart for the clear button will be pushed to the skin.

Here’s a functioning ClearableTextInput custom component (which is simply the clear button code lifted from SuperTextInput.as):

package components {
    import flash.events.Event;
    import flash.events.MouseEvent;
    import mx.events.FlexEvent;
    import spark.components.Button;
    import spark.components.TextInput;
    import spark.events.TextOperationEvent;
 
    public class ClearableTextInput extends TextInput {
 
        [SkinPart(required="false")]
        public var clearButton:Button;
 
        public function ClearableTextInput() {
            super();
 
            //watch for programmatic changes to text property
            this.addEventListener(FlexEvent.VALUE_COMMIT, textChangedHandler, false, 0, true);
 
            //watch for user changes (aka typing) to text property
            this.addEventListener(TextOperationEvent.CHANGE, textChangedHandler, false, 0, true);
        }
 
        private function textChangedHandler(e:Event):void {
            if (clearButton) {
                clearButton.visible = (text.length > 0);
            }
        }
 
        private function clearClick(e:MouseEvent):void {
            text = '';
        }
 
        override protected function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == clearButton) {
                clearButton.addEventListener(MouseEvent.CLICK, clearClick);
                clearButton.visible = (text != null && text.length > 0);
            }
        }
 
        override protected function partRemoved(partName:String, instance:Object):void {
            super.partRemoved(partName, instance);
 
            if (instance == clearButton) {
                clearButton.removeEventListener(MouseEvent.CLICK, clearClick);
            }
        }
    }
}

After the PromptingTextInput, the ClearableTextInput is a little more straightforward. First, we have the clearButton SkinPart and it’s clearClick() event handler. Wiring the handler function to the button is done in the partAdded() override, and un-wiring in the partRemoved() override. Next, button visibility is managed by watching for both programmatic text change events and user text change events. The handler, textChangedHandler(), sets the button as visible when the control has text in it.

As I mentioned above, I decided against pushing the clearButton‘s visibility down to the skin via a SkinState, and instead chose to manage it inside the component by setting clearButton.visible directly. I tend to favor the SkinState method when more than one thing needs to change in the skin or if I need advanced visuals (like transitions). If I need to do just one thing and I don’t care about visuals, I’ll do it inside the component. The two examples here aren’t the best to illustrate the two options, but that’s my general thought process when building a custom component and custom skin.

A skin for ClearingTextInput is super trivial. Again, ignoring all the pretty stuff, the skin is:

<?xml version="1.0" encoding="utf-8"?>
<s:SparkSkin ...>
    ...
    <s:states>
        <s:State name="normal"/>
        <s:State name="disabled"/>
    </s:states>
 
    <s:RichEditableText id="textDisplay" ... />
    <s:Button id="clearButton" ... />
</s:SparkSkin>

Just add the clearButton Button and position it.

Fusion, Glorious Fusion

The fusion process of creating SuperTextInput from PromptingTextInput and ClearableTextInput is nothing more than copy and paste. SuperTextInput has lots of uses, but my favorite is to use it to capture text input to filter a list. It also works great as a search box, or in any smart form UI. Enjoy.

Here’s the finished product showing all three custom components skinned and ready for action (view source enabled):

Files

• SuperTextInput (download)

This post focuses on a scenario where objects are being dragged from one component to another (as opposed to simply rearranging objects within a single component). Further, these components may be quite different from each other (as opposed to being separate instances of the same component — although that scenario can benefit, too).

For example, one component may display a pool of objects that are “available” to be dragged somewhere. We can think of this as the “source” component (the “source” of the objects that can be dragged). In addition to this source component, we may have several “target” components. Perhaps the source/pool holds objects named “penny”, “nickel”, “dime”, and “quarter”. Then, we would have (at least) four “target” components displaying an image of each type of coin (and a place to drop a single, dragged object).

Across clients and projects, I see a tendency for drag-and-drop functionality to be lumped into a single, large view class. In the example discussed above, all of the logic for the source and target components, as well as their drag-and-drop logic, would be coupled (quadrupled?) together. This creates a lot of complexity, making it difficult to follow the flow. The method that handles the drag_drop logic, for example, would have to have conditional logic to determine whether the object was dropped on a target (and which one) … or dropped back on the source component (where do I need to add this object?). The same complexity typically exists for every drag-handler method. And, it often ends up a lot more complex if you start casting to different objects or implementing one-off behaviors for each component type. The root-cause of this complexity is the fact that each drag-handler method is responsible for multiple objects (the one where the drag started and the one where the object was dropped).

We tend to think of the happy-path drag-drop procedure progressing like this:

1. drag start
2. drag enter
3. drag drop
4. drag complete

This is simple and irresistibly logical. And, it is fine if all of your drag actions are occurring on a single component. However, if you are creating custom drag-and-drop functionality for separate components using this style of thinking, then the complexity and confusion discussed above can start to creep in.

It would be cleaner if each drag-handler was specific to a given component. But, if the source and target component logic is truly separated into separate components, what does this mean for the drag events (which events are called on which objects?)?

Once you separate these components, it eventually becomes clear that the events are separated like this:

• On the component that the item is being dragged AWAY FROM:
  1. drag start
  2. drag complete
• On the component that the item is being dragged TO:
  1. drag enter / over / exit
  2. drag drop

And, since the components are now separated, your drag-and-drop logic can only be for that object. This can really simplify your drag-and-drop logic. First of all, you can get rid of the conditional logic. Second, you can now build decoupled, encapsulated components that are not cluttered by the logic of other components.

You can couple this technique of drag-and-drop component separation with the previous post’s technique of keeping the drag-and-drop logic separate from the component. This can go a long way toward achieving clean, clear, single-responsibility classes. Instead of having all of this logic in a single, confusing, monolithic view class, the logic would now be split into four (or more) small, targeted classes (source component, target component, drag logic for source component, drag logic for target component). It can be quite refreshing to maintain code that is focused on a single-responsibility, rather than cluttered by logic that you are not interested in at the moment.

Below is some sample code to get you started. It shows the basic drag handlers for a source component and a target component. It does not show the components themselves, or refer to interfaces, etc. that you might use. But, hopefully, it’ll give you the basic idea.

*** Drag Logic for Source Component ***

public class DragSourceBehavior {

private var component:MyDragSourceUIComponent;

public function DragSourceBehavior(_component:MyDragSourceUIComponent) {
	component = _component;
	component.addEventListener(DragEvent.DRAG_ENTER, onDragEnter, false, 0, true);
	component.addEventListener(DragEvent.DRAG_DROP, onDragDrop, false, 0, true);
}

private function onDragStart(event:MouseEvent):void {
	if (DragManager.isDragging)
		return;

	var dragSource:DragSource = new DragSource();

	DragManager.doDrag(event.currentTarget, dragSource, event);

	component.removeObject(event.currentTarget);
}

private function onDragComplete(event:DragEvent):void {
	var dragObject:UIComponent = event.currentTarget as UIComponent;
	dragObject.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_UP));

	if (droppedOnDifferentObject(event))
		removeDragEvents(event.currentTarget);
}

private function onDragEnter(event:DragEvent):void {
	DragManager.acceptDragDrop(event.currentTarget as IUIComponent);
}

public function onDragDrop(event:DragEvent):void {
	component.addObject(event.dragInitiator);
	addDragEvents(event.dragInitiator);
}

public function addDragEvents(dragObject:UIComponent):void {
	dragObject.addEventListener(MouseEvent.MOUSE_DOWN, onDragStart);
	dragObject.addEventListener(DragEvent.DRAG_COMPLETE, onDragComplete);
}

public function removeDragEvents(dragObject:UIComponent):void {
	dragObject.removeEventListener(MouseEvent.MOUSE_DOWN, onDragStart);
	dragObject.removeEventListener(DragEvent.DRAG_COMPLETE, onDragComplete);
}

private function droppedOnDifferentObject(event:DragEvent):Boolean {
	var droppedOnAnotherObject:Boolean = false;

	if (event.relatedObject != component)
		droppedOnAnotherObject = true;

	return droppedOnAnotherObject;
}

}

*** Drag Logic for Target Component ***

public class MyDragTargetBehavior extends EventDispatcher {

private var component:MyDragTargetUIComponent;

public function MyDragTargetBehavior(_component:MyDragTargetUIComponent) {
	component = _component;
	component.addEventListener(DragEvent.DRAG_ENTER, onDragEnter, false, 0, true);
	component.addEventListener(DragEvent.DRAG_DROP, onDragDrop, false, 0, true);
}

private function onDragStart(event:MouseEvent):void {
	if (DragManager.isDragging)
		return;

	var dragSource:DragSource = new DragSource();

	DragManager.doDrag(event.currentTarget, dragSource, event);

	component.removeObject(event.currentTarget);
}

private function onDragComplete(event:DragEvent):void {
	var dragObject:UIComponent = event.currentTarget as UIComponent;

	if (droppedOnDifferentObject(event))
		removeDragEvents(dragObject);
}

private function onDragEnter(event:DragEvent):void {
	DragManager.acceptDragDrop(event.currentTarget as IUIComponent);
}

public function onDragDrop(event:DragEvent):void {
	component.addObject(event.dragInitiator);
	dispatchEvent(new CustomDragEvent(CustomDragEvent.OBJECT_DROPPED, event.dragInitiator, component));
}

private function droppedOnDifferentObject(event:DragEvent):Boolean {
	var droppedOnAnotherObject:Boolean = false;

	if (event.relatedObject != component)
		droppedOnAnotherObject = true;

	return droppedOnAnotherObject;
}

public function addDragEvents(dragObject:UIComponent):void {
	dragObject.addEventListener(MouseEvent.MOUSE_DOWN, onDragStart);
	dragObject.addEventListener(DragEvent.DRAG_COMPLETE, onDragComplete);
}

public function removeDragEvents(dragObject:UIComponent):void {
	dragObject.removeEventListener(MouseEvent.MOUSE_DOWN, onDragStart);
	dragObject.removeEventListener(DragEvent.DRAG_COMPLETE, onDragComplete);
}

}

The Flex 3 Way

To give a concrete example, I’ll build a blog layout (yes, another blog layout) with a header, footer, sidebar, and main content areas. But before we get started, let’s review the old Flex 3 way:

<mx:HBox id="header">
    <mx:Image source="@Embed('assets/logo.png')" />
</mx:HBox>
 
<mx:Canvas id="body" width="800">
    <mx:Text text="main content" width="600" />
 
    <mx:VBox id="sidebar" x="600" width="200">
        <mx:Text text="Sidebar" />
        <mx:Text text="sidebar content" width="100%" />
    </mx:VBox>
</mx:Canvas>
 
<mx:VBox id="footer">
    <mx:Text text="2010 saturnboy" styleName="footer" />
</mx:VBox>

The above code comes from a previous post, Designing in Flex 3, but has been modified to make sense here. You’ve got you basic blog design: a box for the header, footer, and body, where body is subsequently is divided into a main content area and a sidebar.

The 3-in-4 Way, aka The Wrong Way

The unfortunate next step in a Flex developer’s evolution is what I like to call the Flex 3-in-4 way. This is a the way of neanderthals, which is to say, it is an evolutionary dead end. If you ever have the bad luck to see 3-in-4 code, you can be sure you are dealing with a novice Flex 4 developer. In general, the 3-in-4 way consists of making the simple transcription: Canvas → Group, HBox → HGroup, VBox → VGroup. But the most damning tipoff of a 3-in-4 developer is the assertion that one is now a Flex 4 developer and the learning curve wasn’t all that bad. While I do think Flex 4 is more of an evolutionary release than a revolutionary release, it’s different enough. And it is particularly different on the design side of the framework, how it handles skins, layout, etc.

If we just transcribe the above example, we get some classic 3-in-4 code:

<s:HGroup id="header">
    <s:Label text="Multi Content Area Example" styleName="header" />
</s:HGroup>
 
<s:Group id="body" width="800">
    <s:Label text="main content" width="600" />
 
    <s:VGroup x="600" width="200" styleName="sidebarBox">
        <s:Label text="Sidebar" styleName="title" />
        <s:Label text="sidebar content" styleName="sidebar" />
    </s:VGroup>
</s:Group>
 
<s:VGroup id="footer">
    <s:Label text="2010 saturnboy" styleName="footer" />
</s:VGroup>

*Barf*, please not do this. This code has all the same issues as the Flex 3 code in the first example, and moreover it is a slap in the face of The Flex 4 Way and all of its improvements.

The Flex 4 Way

Yes, there is a Flex 4 Way and it looks like this.

First, we rewrite the main app using a custom container. Ignoring the specifics of the custom container for a moment, here is the re-written main app (minus some clutter):

<containers:headerContent>
    <s:Label text="Multi Content Area Example" styleName="header" />
</containers:headerContent>
 
<containers:sidebarContent>
    <s:RichText left="0" right="0" styleName="sidebar">
        <s:content>
            <s:p fontSize="20">Sidebar</s:p>
            <s:p>sidebar content</s:p>
        </s:content>
    </s:RichText>
</containers:sidebarContent>
 
<containers:footerContent>
    <s:Label text="2010 saturnboy" styleName="footer" />
</containers:footerContent>
 
<s:RichText left="0" right="0">
    <s:content>
        <s:p fontSize="30">Content</s:p>
        <s:p>main content</s:p>
    </s:content>
</s:RichText>

As you can see, the main app is now a nice set of semantic buckets, one for each of the content areas. Header stuff goes in the headerContent bucket, footer stuff goes in the footerContent bucket, etc.

Building a Multi Content Area Container

Second, we need to create a custom container with the nice set of semantic buckets used in the above code. This is achieved by following a straightforward formula:

1. Extend SkinnableContainer – Extend SkinnableContainer or some child class. In our sample app, our custom container extends Application (which extends SkinnableContainer).
2. Add Buckets – add some content buckets (in the form of xxxContent) as Arrays. These become the MXML tags used to bucket components together. Each content bucket has a public getter, but most importantly a public setter that accepts an incoming Array of IVisualElements and uses the magical mxmlContent property to assign it to the associated SkinPart.
3. Add SkinParts – add some matching SkinParts (in the form of xxxGroup) as spark Groups. There are used in the custom skin to display the content. Also, I usually set required="false" to make everything optional.
4. Add partAdded() & partRemoved() – override the new Flex 4 skinning lifecycle methods to wire the incoming content to the outgoing SkinPart.

The custom component code is actually easier to follow then the description. Here is a custom container with only one additional content bucket, sidebarContent, and its matching SkinPart, sidebarGroup:

package containers {
    import spark.components.Group;
    import spark.components.Application;
 
    public class MainApp extends Application {
        [SkinPart(required="false")]
        public var sidebarGroup:Group;
 
        private var _sidebarContent:Array = [];
 
        public function MainApp() {
            super();
        }
 
        [ArrayElementType("mx.core.IVisualElement")]
        public function get sidebarContent():Array {
            return _sidebarContent;
        }
        public function set sidebarContent(value:Array):void {
            _sidebarContent = value;
            if (sidebarGroup) {
                sidebarGroup.mxmlContent = value;
            }
        }
 
        override protected function partAdded(partName:String, instance:Object):void {
            super.partAdded(partName, instance);
 
            if (instance == sidebarGroup) {
                sidebarGroup.mxmlContent = _sidebarContent;
            }
        }
 
        override protected function partRemoved(partName:String, instance:Object):void {
            super.partRemoved(partName, instance);
 
            if (instance == sidebarGroup) {
                sidebarGroup.mxmlContent = null;
            }
        }
    }
}

Following the four steps: we extend Application, have a sidebarContent bucket and its associated sidebarGroup SkinPart, and override partAdded() and partRemoved() to wire everything together.

Skinning a Multi Content Area Container

Skinning in Flex 4 is awesome, and like everyone says, it’s easily one of the best new features in the framework. While I find the skinning process fairly straightforward, I would never call it trivial, mostly due to the depth and flexibility of the skinning system.

We need a custom skin for our custom multi content area component. This is probably the 10% case for skinning, but it’s also the coolest. In my experience, an average Flex 4 app has many Button skins (like 10 or even 20), a few default component skins (skins for List, DropDownList, TextInput, etc.), and maybe only two or three skins for custom components.

The skin itself is nothing special. To display our custom component’s SkinParts, we simply include a Group with the matching id attribute. For example, our skin will include a <s:Group id="sidebarGroup" /> to display the sidebarGroup SkinPart. Just rinse, wash, repeat, to add all of our custom content areas in the container to the skin.

Here is a trivial skin:

<s:Skin ... >
    <fx:Metadata>
        [HostComponent("containers.MainApp")]
    </fx:Metadata> 
 
    <s:states>
        <s:State name="normal" />
        <s:State name="disabled" />
    </s:states>
 
    <s:VGroup left="40" right="40" top="40" bottom="40" gap="20">
        <s:Group id="headerGroup" width="100%" />
        <s:Group id="contentGroup" width="100%" />
        <s:Group id="sidebarGroup" width="100%" />
        <s:Group id="footerGroup" width="100%" />
    </s:VGroup>
</s:Skin>

In this trivial skin, we just shove all the content groups (including SkinnableContainer‘s default Group, contentGroup) into a VGroup. Also note, we correctly set HostComponent to our custom container. If you are thinking, "Hey, this skin looks similar to the Flex 3 and 3-in-4 example code, just minus the content" that’s exactly the point.

Lastly, we wire out skin to our custom component via CSS:

containers|MainApp {
    skinClass:ClassReference('skins.TrivialAppSkin');
}

Using skinClass to wire a skin to a component is so 2009. The sample app has its CSS inline, but in any real app I’ll always put this in an external file.

Conclusion

After this, there’s really not much more to say. You can certainly create a more complicated arrangement of the multiple content areas by making a more complicated skin. I’ve done exactly this in the final sample, which includes three different skins and a skin switcher (click 1, 2, or 3 to switch skins).

» view MultiConentArea sample (view source enabled)

Files

• MultiContentArea (download)

Quick!  Answer the following question without thinking about it:

How would you rate your programming skills?  (Below Average, Average, or Above Average)

Based on psychological studies across many different groups, about 90% of all programmers will answer “Above Average”.

Of course, that can’t possible be true.  In a group of 100 people, 50 are above average, 50 are below average.  This effect is known as Illusory Superiority.  It’s been documented in many domains and even if you’re aware of it, you’ll probably still answer the question above as “Above Average”.

For even more fun, try asking that question to every programmer you know.  Don’t ask them in a group, ask them one-on-one to get more ‘honest’ answers.  You’ll get similar results, even from people who you know can’t program their way out of a wet paper bag (this is the Dunning-Kruger effect, but it’s related).  It’s an epidemic in our profession.

Now, let’s suppose for a second that you’re right–you are actually above average.  You are da man.  A rock star.  God like capacities amongst mere mortals.  Keyboards bow in reverence to you as you approach.  Trumpets sound on high when you commit on GitHub.

If you’re above average, then chances are you’re an expert at what you do.  Calling yourself an expert sounds quite compelling–you get respect, deference, and prestige by being one.

Being an expert means you know it all about your subject. Unfortunately, it also means you’re going to get lazy.  It means you’re going to eventually rest on your laurels and sit around thinking you’re better than everyone else instead of actually working to get there.  Your expertise will become a liability because you stop trying to learn.  Maybe not today, but soon enough.

Instead, why not consider the more likely possibility?  You’re average, or heaven forbid, below average. Aside from the personal stigma you might suffer here, think for a second about the real benefits of doing this:

• By assuming you’re not at the top of the pack, you now have incentive to get there
• By assuming you’re not the smartest person in the group, you now have the opportunity to learn something
• By assuming you’re not the best at what you do, you’re going to work harder to improve yourself

Perhaps you’ve heard of beginner’s mind?  Summed up by a zen master in classic koan-brevity:

In the beginner’s mind there are many possibilities, in the expert’s mind there are few.

The trap of calling yourself ‘expert’ at software development means that you pigeonhole yourself into some language (Java, Ruby, PHP), some industry (medical devices, social networking, games), or some specialty (embedded programming, enterprise software).  Once you establish that expertise, fear of failure arises when you consider going outside that comfort sphere.  With your golden hammer of experience, everything appears to you a nail.  You stop thinking about screwdrivers and all other possible relevant tools because they’re no longer inside your ‘expertise’.

This is why starting out in software you wonder why “experienced programmers” can’t get X, when you just learned X in a matter of days.  X could be anything:  closures, object-oriented programming, Ruby on Rails framework, Haskell programming.  It doesn’t matter in the end, the expert’s mind is cluttered with old knowledge.  The beginner’s mind is open, free of hindrances.

It’s harder to learn when you’re an expert.  And this is why being the ‘expert programmer’ is dangerous.

So what’s the number one thing you can do to be the best programmer out there?  Start by considering yourself below average. Step out of your comfort zone.  Be the averagest.

A master never stops learning, and neither should you.

No related posts.