Effective View Development

In a previous post, we reviewed how Commands are uniquely complex objects because of the number and diversity of collaborators.

Like Commands, Views can grow to be very complex.  We have explored this in the context of delegating to Specialist Classes.  They can be complex and difficult to maintain because it is easy for them to become monolithic.  It is easy for us to not follow good methodologies and make them into unwieldy Autonomous Views.  It is easy for us to ignore unit testing of them because of the intricacies of dealing with their asynchronous nature.

The declarative nature of MXML is a powerful means of describing Views.  Interweaving scripting with the MXML syntax can easily be another area of complexity and confusion.  A common question is- what is running when?  How can I follow the flow of control in this application?

In light of all of these reasons, View objects tend to be the most unmanageable of the entire application.  We need to change that.  We need to re-double our efforts in keeping our Views clean and working well.  We are going to walk through a number of rules of thumb in how to accomplish this goal.

Avoid Monolithic Autonomous Views

Paul Williams has written a great series of articles on View patterns.  In it he does an excellent job warning of the dangers of Autonomous Views.  In particular in how they are difficult to Unit Test.  Paul’s investment in blogging on this topic is a testament to the importance of getting this right.

Big, monolithic Autonomous views are the natural result of a design that hasn’t had much refactoring or thought put into it.  Basically, you just start with a Flex component and keep organically growing it by tacking code here and code there.  Following this approach, we find ourselves trying to maintain a beast of a Flex application.

The good news is, that it is relatively straight-forward to refactor Autonomous views into collaborations of smaller specialist objects:  Extract component refactorings.

Keep Views under 300 lines by Extract Component refactorings

Assuming that there is an MVC framework in place, we shouldn’t be concerned about extract Model and Controller responsibilities out.  Even with Model and Controller objects being extracted, there will still be plenty of complexity in the Views themselves.

As a general rule of thumb, keeping our Views to under 300 lines helps guide us into other important refactorings.  All Views can be broken down to this level.  There are two main extraction refactorings to mention:

Extract to Component

If the View contains any containers or controls, create a custom component out of these elements and extract logic into there.  This should be a very regular practice in View development.  As soon as we start seeing logic forming around a particular element, event listeners and initializes for example, we should be quick to move that logic into the space of its own component.

Below is an example of a simple example application before and after an Extract Component refactoring.  Although the example application is small enough that it doesn’t beg for a refactoring now.  It isn’t difficult to see how this application grown over time can become unwieldy.  All of the event listeners are included in the same script block, and there isn’t a very clear abstracting for this yet-to-be overly complex Autonomous View.

AutonomousView.mxml

<?xml version="1.0" encoding="utf-8"?>
<!--

    This is a simple example application to demonstrate an Extract Component refactoring.  This 
    represents the early days of a yet-to-be unwieldy and monolithic Autonomous View.

    @author amanning

-->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
    
    <!--
        ********************************************************************************************
        SCRIPT
        ********************************************************************************************
    -->
    <mx:Script>
    <![CDATA[

        import mx.events.ListEvent;
        import mx.controls.Alert;
        import mx.collections.ArrayCollection;
        
        /** Widgets to edit - stubbed for now */
        [Bindable]
        private var _widgetsToEdit:ArrayCollection = new ArrayCollection([
            {name:"a"},
            {name:"b"},
            {name:"c"},
            {name:"d"},
            {name:"e"},]);
        
        /** "datagrid change" event listener for this view */
        private function onDataGridChange(event:ListEvent):void {
            
            Alert.show("the datagrid selection has changed");
        
        }
        
        /** "Edit Click" event listener for this view */
        private function onEditClick(event:Event):void {
            
            Alert.show("the edit button has been clicked");
        
        }
                        
        /** "Delete Click" event listener for this view */
        private function onDeleteClick(event:Event):void {
            
            Alert.show("the delete button has been clicked");
        
        }

    ]]>
    </mx:Script>
        
    <mx:Panel title="Extract Component Refactoring - Autonomous View">

        <mx:HDividedBox>
            
            <mx:DataGrid id="dataGrid"
                width="100%" height="100%" 
                change="onDataGridChange(event)" 
                dataProvider="{_widgetsToEdit}"/>
            
            <mx:TextArea 
                height="100%" width="100%" 
                text="{dataGrid.selectedItem.name}"/>
            
        </mx:HDividedBox>
    
        <mx:ControlBar>
            <mx:Button label="Edit" 
                click="onEditClick(event)"/>
            <mx:Button label="Delete" 
                click="onDeleteClick(event)"/>
        </mx:ControlBar>

    </mx:Panel>
    
</mx:Application>

The extract to component refactoring will extract the DataGrid and the Control bar into custom components and bring along with them their local models and event listeners.

ExtractComponentView.mxml

<?xml version="1.0" encoding="utf-8"?>
<!--

    This is a simple example application to demonstrate an Extract Component refactoring.  This 
    represents the early days of a yet-to-be unwieldy and monolithic Autonomous View.

    @author amanning

-->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*">
    
    <mx:Panel title="Extract Component Refactoring - Autonomous View">

        <mx:HDividedBox>
            
            <local:WidgetDataGrid id="dataGrid"/>
                        
            <mx:TextArea 
                height="100%" width="100%" 
                text="{dataGrid.selectedItem.name}"/>
            
        </mx:HDividedBox>
            
        <local:WidgetControlBar/>

    </mx:Panel>
    
</mx:Application>

WidgetDataGrid.mxml

<?xml version="1.0" encoding="utf-8"?>
<!--

    A DataGrid for browsing widgets.

    @author amanning

-->
<mx:DataGrid xmlns:mx="http://www.adobe.com/2006/mxml"
    width="100%" height="100%"
    dataProvider="{_widgetsToEdit}"
    change="onDataGridChange(event)">
    
    <!--
        ********************************************************************************************
        SCRIPT
        ********************************************************************************************
    -->
    <mx:Script>
    <![CDATA[
        import mx.controls.Alert;
        import mx.collections.ArrayCollection;
        import mx.events.ListEvent;
        
        /** Widgets to edit - stubbed for now */
        [Bindable]
        private var _widgetsToEdit:ArrayCollection = new ArrayCollection([
            {name:"a"},
            {name:"b"},
            {name:"c"},
            {name:"d"},
            {name:"e"}]);

        /** "datagrid change" event listener for this view */
        private function onDataGridChange(event:ListEvent):void {

            Alert.show("the datagrid selection has changed");
        
        }
    
    ]]>
    </mx:Script>

</mx:DataGrid>

WidgetControlBar.mxml

<?xml version="1.0" encoding="utf-8"?>
<mx:ControlBar xmlns="*" xmlns:mx="http://www.adobe.com/2006/mxml">

    <!--
        ********************************************************************************************
        SCRIPT
        ********************************************************************************************
    -->
    <mx:Script>
    <![CDATA[

        import mx.events.ListEvent;
        import mx.controls.Alert;
        import mx.collections.ArrayCollection;
        
        /** "Edit Click" event listener for this view */
        private function onEditClick(event:Event):void {
            
            Alert.show("the edit button has been clicked");
        
        }
                        
        /** "Delete Click" event listener for this view */
        private function onDeleteClick(event:Event):void {
            
            Alert.show("the delete button has been clicked");
        
        }

    ]]>
    </mx:Script>
   
       <mx:Button label="Edit" 
                click="onEditClick(event)"/>

        <mx:Button label="Delete" 
                click="onDeleteClick(event)"/>

</mx:ControlBar>

Delegate by extracting to a “View Specialist”

Create specialized objects that are easily unit testable.  A good example of this is the Shared Date Formatter object which abstracts some complexity that could easily have been spread throughout many views.

Avoid Code Behind and View Helpers

Flex equivalents to ASP Code Behind may seem like an obvious step since it provides a very direct medium for moving scripting code out of MXML files and into ActionScript files.  It does provide a way to separate out the two types of languages, but its usefulness ends there.

Once again, Paul Williams has done a fantastic job in describing the relative merits of Code Behind and View Helpers.

There are a slew of issues with these approaches, but two main ones come to mind:

  • With Code Behind, it is difficult to keep View element properties in sync between the View class and the Base class.  For example, if there is a button that the Base class needs access to, a protected property for that button must be declared.  If the View changes, there is no compiler warning that the Base is out of sync with the view- rather at run time this element will just be null.  The general approach is difficult to maintain and error prone.
  • View Helpers are tightly coupled with the View, but don’t offer much in the way of re-use.  It is difficult to share View Helpers across Views- unless we try and create a large inheritance hierarchy, which often complicates matters more than it actually helps.

If the problem we are trying to solve is to reduce very large Script blocks, then the two Extract Component refactorings mentioned above are cleaner, more maintainable and easier to Unit Test.

Use Templates

Thanks to Peter Ent for discussing this approach- the concept is quite simple, but the emergent design built upon its common usage is extremely powerful.  Templates let us create an MXML View component with configurable containers and controls as children.  This allows us to abstract away the common styling and layout and only expose the changeable regions.

Let’s use the Extract Component refactoring above, and refactor it into a Template.  We will change our new, more manageable, Autonomous View into a Template View.  We perform an Extract Template refactoring of the Panel, and create a more generic ListBrowserTemplate.

ExtractTemplateView.mxml

<?xml version="1.0" encoding="utf-8"?>
<!--

    This is a simple example application to demonstrate an Template refactoring.  We have abstracted
    the layout into a Template view.  This application only populates two configurable regions, the
    rest of the work is handled by the template.  The configurable regions are populated with 
    extracted components.

    @author amanning

-->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*">
    
    <local:ListBrowserTemplate>
        
        <local:browseRegion>

            <local:WidgetDataGrid id="dataGrid"/>
                
        </local:browseRegion>
        
        <local:detailRegion>

            <mx:TextArea 
                    height="100%" width="100%" 
                    text="{dataGrid.selectedItem.name}"/>

        </local:detailRegion>
                
    </local:ListBrowserTemplate>

</mx:Application>

ListBrowserTemplate

<?xml version="1.0" encoding="utf-8"?>
<!--

    A Panel Template for managing items in a list and viewing details of items selected.
    
    @author amanning

-->
<mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:local="*" 
        width="100%" height="100%"
        creationComplete="onCreationComplete()">

    <!--
        ********************************************************************************************
        SCRIPT
        ********************************************************************************************
    -->
    <mx:Script>
    <![CDATA[
        import mx.core.UIComponent;
        import mx.core.Container;
        //------------------------------------------------------------------------------------------
        // Properties
        //------------------------------------------------------------------------------------------
        /** One or more child elements for the browsable region- dynamically added to the view */
        private var _browseRegionComponents:Array = new Array();

        /** One or more child elements for the details region- dynamically added to the view */
        private var _detailRegionComponents:Array = new Array();

        //------------------------------------------------------------------------------------------
        // Methods
        //------------------------------------------------------------------------------------------
        /** The "creation complete" event listener for this view- populate regions*/
        private function onCreationComplete():void {
        
            addComponentsToTemplate(browseRegionCanvas,_browseRegionComponents);
            addComponentsToTemplate(detailRegionCanvas,_detailRegionComponents);

        }  

        /** 
         * Setter for the the write-only <code>_browseRegionComponents</code> property - set the 
         * list of children components to a local property so that during creation complete they can 
         * be added to the view.
         * 
         * @param componentList   the list of one or more children to add to this view, these
         *                        children represent the configurable region of this template
         */
        public function set browseRegion(componentList:Array):void {

            _browseRegionComponents = componentList;

        }

        /** 
         * Setter for the the write-only <code>_detailRegionComponents</code> property - set the 
         * list of children components to a local property so that during creation complete they can 
         * be added to the view.
         * 
         * @param componentList   the list of one or more children to add to this view, these
         *                        children represent the configurable region of this template
         */
        public function set detailRegion(componentList:Array):void {

            _detailRegionComponents = componentList;

        }

        /**
         * Given a list of UIObjects (the configurable region of this view) manually add them to 
         * this view.
         * 
         * Note:  This should be called during the creation complete phase of this components 
         * lifecycle
         * 
         * @param container     the container to dynamically add the children to
         * @param components    the components to add to the container
         */
        public function addComponentsToTemplate(container:Container, components:Array):void {

            container.removeAllChildren();
            for each(var subcomponent:UIComponent in components) {

                container.addChild(subcomponent);

            }

        }

    ]]>
    </mx:Script>
        

        
    <!--
        ********************************************************************************************
        VIEW
        ********************************************************************************************
    -->
    <mx:DividedBox width="100%" height="100%" direction="horizontal">
        <mx:Canvas id="browseRegionCanvas" width="100%" height="100%"/>
        <mx:Canvas id="detailRegionCanvas" width="100%" height="100%"/>
    </mx:DividedBox>
    
    <local:WidgetControlBar/>

</mx:Panel>

These are simple examples, so the benefit may not be directly apparent. As the complexity grows, we will see that these refactorings give us modular and manageable Views. We now have room to breathe- Monolithic Autonomous Views, problematic View Helpers, and buggy Code Behind Base classes are a thing of the past.

2 thoughts on “Effective View Development

  1. Allen,

    Just found your blog and I must say it is great. We are pretty new to Flex, and many of yours have helped us get on the right path.

    Oh, and I like your blog theme ;)

    Thanks, and keep ‘em coming!

  2. Glenn,

    That’s great news. I think there is real potential for us to create some fantastic software from this technology.

    Best,
    al

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>