Building an Enterprise Framework - Enterprise Development with Flex, Part 3

2009-05-20T18:43:48Z

Note: This is excerpted from Chapter 3 of the Rough Cuts version of Enterprise Development with Flex. This book is still in progress, and you can get access to it now.

Get the Enterprise Development with Flex Rough Cut

Rough Cuts is a service from Safari Books Online that gives you early access to content on cutting-edge technologies -- before it's published. It lets you literally read the book as it is being written.

Table of Contents, Part 3

Validation

Sample Application – DataFormValidator
Class ValidationRule Explained
Embedding Validation Rules into a DataGrid

Minimizing the Number of Custom Events

Summary

Validation

Like data forms and components in general, the Flex Validator could use some enhancement to make it more flexible for your application developers. In Flex validation seems to have been designed with an assumption that software developers will mainly use it with forms and each validator class will be dependent on and attached to only one field. Say, you have a form with two email fields. Flex framework forces you to create two instances of the EmailValidator object – one per field.

In the real life though, you may also need to come up with validating conditions based on relationships between multiple fields, as well as to highlight invalid values in more than one field. For example, you might want to set the date validator to a field and check if the entered date falls into the time interval specified in the start and end date fields. If the date is invalid, you may want to highlight all form fields.

In other words, you may need to do more than validate an object property. You may need the an ability to write validation rules in a function that can be associated not only with the UI control but also with the underlying data, i.e. with a data displayed in a row in a DataGrid.

Yet another issue of Flex Validator is its limitations regarding view states of automatically generated UI controls. Everything would be a lot easier if validators could live inside the UI controls, in which case they would be automatically added to view states along with the hosting controls.

Having convenient means of validation on the client is an important part of the enterprise Flex framework. Consider, for example, an RIA for opening new customer accounts in a bank or an insurance company. This business process often starts with filling multiple sections in a mile-long application form. In Flex, such an application may turn into a ViewStack of custom components with, say five forms totaling 50 fields. These custom components and validators are physically stored in separate files. Each section in a paper form can be represented as a content of one section in an Accordion or other navigator. Say you have total of 50 validators, but realistically, you'd like to engage only those validators that are relevant to the open section of the Accordion.

If an application developer decides to move a field from one custom component to another, he needs to make appropriate changes in the code to synchronize the old validators with a relocated field.

What some of the form fields are used with view states? How would you validate these moving targets? If you are adding three fields when the currentState="Details", you'd need manually write AddChild statements in the state section Details.

Say 40 out of these 50 validators are permanent, and the other 10 are used once in a while. But even these 40 you don't want to use simultaneously hence you need to create, say two arrays having 20 elements each, and keep adding/removing temporary validators to these arrays according to view state changes.

Even though it seems that Flex separates validators and field to validate, this is not a real separation but rather a tight coupling. What's the solution? For the customer accounts example, you want a ViewStack with five custom components, each of which has one DataForm whose elements have access to the entire set of 50 fields, but that validates only its own set of 10. In other words, all five forms will have access to the same 50-field dataProvider. If during account opening the user entered 65 in the field age on the first form, the fifth form may show fields with options to open a pension plan account, which won't be visible for young customers.

That's why each form needs to have access to all data, but when you need to validate only the fields that are visible on the screen at the moment, you should be able to do this on behalf of this particular DataForm. To accomplish all this, we created a new class called ValidationRule. Our goal is not to replace existing Flex validation routines, but rather offer you an alternative solution that can be used with forms and list-based controls. The next section demonstrates a sample application that uses the class ValidationRule. After that, you can take a look at the code under the hood.

Sample Application – DataFormValidator

The DataFormValidator.mxml application (Figure 3.5, “Running DataFormValidation application”) has two DataForm containers located inside the HBox. Pressing the button Save initiates the validation of both forms and displays the message if the entered data is valid or not.

Figure 3.5. Running DataFormValidation application

Here's the code of the DataFormValidation.mxml application that created these forms:



    
         

        
          
            
               
            
            
                     
             
             
                
             
             
                
             
             
             
                
             
          

          
               
                     
               
               
                     
                       
                          
                           
                          
                          
                          
                         
                     
               
               
                     
               
             
          
    
    

    
          import com.farata.datasource.dto.VacationRequestDTO;
               import mx.utils.UIDUtil;

               [Bindable] private var vacationRequestDTO:VacationRequestDTO ;
               private function afterToday( val: Object) : Boolean {
                     var b : Boolean = val.END_DATE > new Date();
                     return b;
               }
               private function afterStartDate( val: Object) : Boolean {
                     var b : Boolean = val.END_DATE > val.START_DATE;
                     return b;
               }

               private function onCreationComplete():void {
                     // create a new vacation request
                     vacationRequestDTO = new VacationRequestDTO;
                     vacationRequestDTO.REQUEST_ID = UIDUtil.
createUID();
vacationRequestDTO.STATUS = "Created";
                                       vacationRequestDTO.START_DATE =
                              new Date(new Date().time + 1000 * 3600 * 24);
                     vacationRequestDTO.EMPLOYEE_NAME = "Joe P";
                         vacationRequestDTO.EMPLOYEE_EMAIL =
 "jflexer@faratasystems.com";
                     vacationRequestDTO.VACATION_TYPE =
 "L"; //Unpaid leave - default
               }

               private function onSave():void       {
                     if (isDataValid()) {
                          mx.controls.Alert.show("Validation succedded");
                     } else {
                          mx.controls.Alert.show("Validation failed");
                     }
               }

               private function isDataValid():Boolean {
                     var failedLeft:Array = left.validateAll();
                     var failedRight:Array = right.validateAll();
                     return ((failedLeft.length == 0)&&(failedRight.length == 0));
               }
          ]]>

On creationComplete event this application creates an instance of the vacationRequestDTO that is used as a dataProvider for both left and right data forms.

This code uses a mix of standard Flex validators (StringValidator, EmailValidator) and subclasses of ValidatorRule. Note that both email fields use the same instance of the EmailValidator, which is not possible with regular Flex validation routines:

Notice that these validators are encapsulated inside the DataFormItem. If application programmers decide to add or remove some of the form item when the view state changes, they don't need to program anything special to ensure that validators work properly! The form item end date encapsulates two validation rules that are given as a closures afterStartDate and afterToday.

...

private function afterToday( val: Object) : Boolean {
    var b : Boolean = val.END_DATE > new Date();
    return b;
}

private function afterStartDate( val: Object) : Boolean {
    var b : Boolean = val.END_DATE > val.START_DATE;
    return b;
}

The code above does not include standard Flex validators inside the , but this is supported too. For example, you can add the line in the validators section of a DataFormItem right under the tag.

If you do it, you'll have three validators bound to the same form item End Date: one standard Flex validator and two functions with validation rules.

From the application programmer's perspective, using such validation rules is simple. It allows reusing validators, which can be nicely encapsulated inside the form items.

For brevity, the function onSave() just displays a message box stating that the validation failed:

mx.controls.Alert.show("Validation failed");

But if you run this application through a debugger and place a breakpoint inside the function isDataValid(), you'll see that all validation errors in the failedLeft and failedRight arrays (Figure 3.6, “Debugger's View of validation errors”).

Figure 3.6. Debugger's View of validation errors

The next question is, "How does all this work?"

Class ValidationRule Explained

Enhancing the original Flex validators, the new ValidationRule extends Flex Validator and is known to clear.swc's UI controls. With it, developers can attach any number of validation rules to any field of a form or a list-based component. This means you can attach validation rules not only on the field level, but also on the parent level, such as to a specific DataGrid column or to an entire row.

When we designed the class, our approach was to separate (for real) validation rules from the UI component they validate. We also made them reusable to spare application developers from copy/pasting the same rule repeatedly. With the ValidationRule class you can instantiate each rule once and reuse it across the entire application. Our goal was to move away from one-to-one relations between a validator and a single property of a form field, to many-to-many relations where each field can request multiple validators and vice versa.

If you don't need to perform cross-field validation in the form, you can continue using the original Flex validator classes. If you need to validate, interdependent fields—say if the amount field has the value greater than $10K you need to block overnight delivery of the order field until additional approval is provided—use our more flexible extension, ValidationRule.

We still want to be able to reuse the validators (EmailValidator, StringValidator et al.) that come with Flex, but they should be wrapped in our class ValidationRule. On the other hand, with the class ValidationRule the application developers should also be able to write validation rules as regular functions, which requires less coding.

The source code of the class ValidationRule that supports all this functionality is listed in Example 3.17, “Class ValidationRule”.

Example 3.17. Class ValidationRule

package com.farata.validators{
    import mx.controls.Alert;
    import flash.utils.describeType;

    import mx.events.ValidationResultEvent;
    import mx.validators.ValidationResult;
    import mx.validators.Validator;

    public class ValidationRule   extends Validator{
        public var args:Array = [];
        public var wrappedRule:Function ;
        public var errorMessage : String = "[TODO] replace me";
        public var data:Object;

          public function ValidationRule() {
               super();
               required = false;
          }
        private function combineArgs(v:Object):Array {
               var _args:Array = [v];
                     if( args!=null && args.length>0 )
                          _args["push"].apply(_args, args);
                     return  _args;
        }

        public function set rule(f:Object) : void {
            if (!(f is Function)){
               Alert.show(""+f, "Incorrect Validation Rule" );
              return; // You may throw an exception here
           }

            wrappedRule = function(val:Object) :Boolean {
               return f(val);
            }
       }

        private function substitute(...rest):String {
            var len:uint = rest.length;
            var args:Array;
            var str:String = "" + errorMessage;
            if (len == 1 && rest[0] is Array){
                args = rest[0] as Array;
                len = args.length;
            }
            else{
                args = rest;
            }

            for (var i:int = 0; i < len; i++){
                str = str.replace(new RegExp("\\$\\["+i+"\\]", "g"), args[i]);
            }
               if ( args.length == 1 && args[0] is Object) {
               var o:Object = args[0];
                  for each (var s:*  in o){
                      str = str.replace(new RegExp("\\$\\["+s+"\\]",
 "g"), o[s]);
                  }

                  var classInfo:XML = describeType(o);
                // List the object's variables, their values, and their types.
             for each (var v:XML in classInfo..variable) {
                      str = str.replace(new RegExp("\\$\\["+v.@name+
"\\]", "g"),
                                                                    o[v.@name]);
                }

            // List accessors as properties.
                for each (var a:XML in classInfo..accessor) {
                // Do not get the property value if it is write only.
                 if (a.@access != 'writeonly') {
                           str = str.replace(new RegExp("\\$\\["+a.@name+"\\]",
                                                            "g"), o[a.@name]);
                 }
                }
               }
            return str;
        }

    override protected function doValidation(value:Object):Array{
             var results:Array = [];

            if (!wrappedRule(data))
                 results.push(new ValidationResult(true, null, "Error",
                          substitute(combineArgs(data))));

            return results;
        }
    override public function validate(value:Object = null,
                   suppressEvents:Boolean = false):ValidationResultEvent{
        if (value == null)
            value = getValueFromSource();

        // if required flag is true and there is no value
        // we need to generate a required field error
        if (isRealValue(value) || required){
            return super.validate(value, suppressEvents);
        }
        else {
            // Just return the valid value
            return new ValidationResultEvent(ValidationResultEvent.VALID);
        }
      }
    }
}

The superclass Validator has two methods that will be overridden in its descendents: doValidation(), which initiates and performs the validation routine, and the function validate(), which watches required arguments and gets the values from the target UI control.

Notice this code fragment from the DataFormValidation application:

mentions the name of the function afterStartDate that alternatively could have been declared inline as a closure. The function ensures that the date being validated is older than the END_DATE.

private function afterToday( val: Object) : Boolean {
    var b : Boolean = val.END_DATE > new Date();
    return b;
}

In this code val points at the dataProvider of the form, which, in the sample application, is an instance of the vacationRequestDTO. An important point is that both the DataForm and the ValidationRule see the same dataProvider.

The value of the errorMessage attribute includes something that looks like a macro language: ($[END_DATE]). The function substitute() finds and replaces via regular expression the specified name (i.e. END_DATE) in all properties in the dataProvider with their values.

If dataProvider is a dynamic object, the function ValidationRule.substitute() enumerates all its properties via or for each loop. For regular classes, Flex offers a reflection mechanism using the function describeType() – give it a class name and it'll return a definition of this class in a form of XML. Then, the function substitute() gets all class variables and accessors (getters and setters) and applies the regular expression to the errorMessage text.

For example, if you deal with a dynamic object o that has a property END_DATE, the following line will replace ($[END_DATE]) in the error text with the value of this property – o[s]:

str = str.replace(new RegExp("\\$\\["+s+"\\]", "g"), o[s]);

The method substitute() is called from doValidate(), and if the user entered invalid dates (i.e. the start date is 12/10/2008 and the end date 12/06/2008), the validator will find the properties called END_DATE and START_DATE and turn this error text:

"End Date ($[END_DATE]) must be later than Start Date $[START_DATE]"

into this one:

"End Date (12/06/2008) must be later than Start Date 12/10/2008"

In Chapter 2, Selected Design Patterns you learned how to write class factories that can wrap functions and return them as objects. This technique is applied in the ValidationRule class too, which supports functions as validators. If the application code uses the setter rule the function with business-specific validation rules is expected.

The class ValidationRule has this setter:

public function set rule(f:Object) : void {
          if (!(f is Function)){
             Alert.show(""+f, "Incorrect Validation Rule" );
            return;
         }

          wrappedRule = function(val:Object) :Boolean {
          return f(val);
          }
}

In the application DataFormValidation you can easily find this setter has been used (we've already discussed the function afterStartDate above):

We hope you like the simplicity that ValidationRule offers to application developers that have to validate forms. The next section examines a more sample application that demonstrates the use of this class in a DataGrid control.

Embedding Validation Rules into a DataGrid

As opposed to component libraries, classes in a framework depend on each other. In this context is means that the ValidationRule class requires an enhanced DataGrid component.

Note

Please note that sample application shown below does uses DataGrid and DataGridItem from a different namespace. These classes are included in the clear.swc library and come with the source code accompanying the book, but due to space constraints, we won't include the source code of these objects here.

This example is yet another version of the Café Townsend from Chapter 1, Comparing Selected Flex Frameworks. For simplicity, the employee data are hard-coded and to run this application you don't need to do any server-side setup.

This application is an example of a master-detail window with validators embedded inside a data grid. Figure 3.6, “Debugger's View of validation errors” shows the phone number having the wrong number of digits in the first row of our DataGrid component. Embedded validation rule properly reports an error message that reads "Wrong length, need 10 digit number".

Figure 3.7. Validating the phone DataGridColumn

You can also assign validation rules to the form items that show details of the selected row. In Figure 3.8, “Validating the salary DataGridColumn” you can see a validation error message stating that "Salary(9.95) is out of reasonable range". All fields that have invalid values have red borders. While examining the source code, please note, the dropdown box Department that was populated using a resource file.

Figure 3.8. Validating the salary DataGridColumn

This version of the Café Townsend application uses the following custom object Employee_getEmployees_gridFormTest:

Example 3.18. Code of Café Townsend with validations



trace(event)"
                                                     fault="trace(event)" />

    
          itemRenderer="{new
      UIClassFactory(com.farata.controls.dataGridClasses.DataGridItemRenderer)}"
          horizontalScrollPolicy="auto" width="100%" dataProvider="{collection}"
               editable="true" height="100%" rowHeight="25">
             
               
               
               
               
               
               
               
                     
                          
                     
               
               
                     
                          
                                length, need 10 digit number"/>
                          
                     
               

               

               
                     
                          
                     
               

               
                     
                          
                            
                            rule="{function(data:Object):Boolean
                                  { return (data &&data.SALARY > 10000
                                  && data.SALARY < 500000);}}"
                               errorMessage="Salary ($[SALARY]) is out of reasonable
                                                                          range"/>
                          
                     
               

               

               
                     
                          
                                rule="{afterStartDate}"
                                errorMessage="End Date ($[TERMINATION_DATE]) must be
                                            later than Start Date $[START_DATE]">
                          
                     
               

               

               

               

                

                
            
    

    
          
               
                     
                     
                     
                     
                     
                     
                     
               

               
                     
                     
                     
                     
                         
                           return (data &&data.SALARY > 10000 &&
                                   data.SALARY < 500000);}}"
                              errorMessage="Salary ($[SALARY]) is out
                                                           of reasonable range"/>
                          
                     
                     
                     
                     
               
               
                     
                     
                          
                                
                          
                     
                     
                          
                                
                          
                     
                     
                          
                                
                          
                     
                     
                          
                                
                             
                     
                  
                   
               
          
   



 
 
 
 
 
 
 


    import com.farata.controls.dataGridClasses.DataGridItemRenderer;
    import com.farata.core.UIClassFactory;
    import com.farata.collections.DataCollection;
    import mx.collections.ArrayCollection;
    import mx.controls.dataGridClasses.DataGridColumn;
    import mx.events.CollectionEvent;
    import com.farata.datasource.dto.EmployeeDTO;
    import com.farata.resources.*;
    import mx.validators.*;

    private var linkage:EmployeeDTO = null;

    private function fill_onClick():void {
          collection.source = Test.data;
          dg.selectedIndex=0;
    }

    private function addItemAt(position:int):void   {
          var item:EmployeeDTO = new EmployeeDTO();
          collection.addItemAt(item, position);
          dg.selectedIndex = position;
    }

    import com.farata.resources.*;
    import com.farata.controls.*;
    private function afterStartDate( val: Object) : Boolean {
          return !val.TERMINATION_DATE || val.TERMINATION_DATE > val.START_DATE;
    }
    ]]>

When you review the code in Example 3.18, “Code of Café Townsend with validations”, you'll find different flavors of validation rules inside the data grid columns in this implementation of the Café. For example, the following rule is defined as an anonymous function for the data grid column SALARY:

rule="{function(data:Object):Boolean { return (data &&data.SALARY > 10000 && data.SALARY < 500000);}}" errorMessage="Salary ($[SALARY]) is out of reasonable range"/>

If the data grid is populated and the salary in a particular cell does not fall into the range between 10000 and 500000, this function returns false and this data value is considered invalid. Such cell(s) will immediately get the red border and the error message will report the problem in the red error tip right by this cell.

Some of the validation rules were repeated both in the DataGrid and DataForm, but this doesn't have to be the case. The same instances of the ValidationRule class can be reused as in the DataFormValidation application.

The data for this sample application are hardcoded in Test.as, which starts as follows:

public class Test{ public function Test(){ } static public function get data() : Array { var e : EmployeeDTO = new EmployeeDTO; e.EMP_FNAME = "Yakov"; e.EMP_LNAME = "Fain"; e.BENE_DAY_CARE = "Y"; e.BENE_HEALTH_INS = "Y"; e.BENE_LIFE_INS = "N"; ...

If you'd like to have deeper understanding of how works with embedded validators, please examine the source code of the classes com.farata.controls.dataGridClasses.DataGridItem and com.farata.controls.DataGrid that are included with the source code of accompanying this chapter.

We had to jump through a number of hoops to allow Flex validators to communicate with the DataGrid as the class Validator expects to work only with sublcasses of the UIComponent that are focusable controls with borders. It's understandable – who needs to validate, say a Label?

But we wanted to be able to display a red border around the cell that has an invalid value and a standard error tip when the user hovers the mouse pointer over the DataGrid cell. Hence we had to make appropriate changes and replace the original DataGrid.itemRederer with our own that implements IValidatorListener interface. An itemRenderer on the DataGrid level affects all its columns.

itemRenderer="{new UIClassFactory( com.farata.controls.dataGridClasses.DataGridItemRenderer)}"

We've included this replacement of the DataGridItemRenderer in the demo application just for illustration purposes to show that you can substitute the base classes from Flex framework with your own. But as a developer of a business framework, you should hide such code in the base components, which in this case would have been a constructor of your enhanced DataGrid.

Besides validation rules, it worth noting how master-detail relations are implemented with just one line:

A selected row in a DataGrid (master) is a dataProvider for a DataForm (detail). With original Flex DataGrid and Form components it would take a lot more coding to properly re-bind the object representing a selected row that is changing whenever the user selects a different one.

Once again, a well designed framework should allow application developers to write less code. The code of this version of Café Townsend is an example of what can be done in only about 160 lines of code. It implements master-detail relations, performs lots of custom validations, uses business style sheets. Adding a couple of dozen lines of code can turn this application into a CRUD built on the powerful DataCollection class that will be discussed in Chapter 6.

Minimizing the Number of Custom Events

Up till now, you've concentrated on building rich components for a business framework. We Flex architects should also recommend some coding techniques that serve the same goal as these components: enabling application developers to write less code. In this section you'll see how to minimize the number of custom event classes in any application.

Flex is all about event-driven development. Create loosely coupled custom components and let them send events to each other as in the Mediator pattern example from Chapter 2, Selected Design Patterns. You can create new events for every occasion. If an event does not need to carry any additional data, just give it a name, specify its type as flash.events.Event, and define the meta-tag to help Flex Builder list this event in its type-ahead prompts and dispatch it when appropriate. If your new event needs to carry some data, create an ActionScript class extending flash.events.Event, define a variable in this subclass to store application data, and override the method clone().

Currently, for a mid-size Flex application that includes about 30 views, where each view has two components that can send/receive just one custom event, for example, you face the need to write 60 custom event classes that look pretty much the same. We'll show you how to get away with just one custom event class for the entire application.

To illustrate the concept, we've created a simple application that defines one event class that can serve multiple purposes. This application consists of two modules (GreenModule, shown in Figure 3.9, “The GreenModule is loaded”, and RedModule) that are loaded in the same area of the main application on the click of one of the load buttons. It also has one universal event class called ExEvent.

Figure 3.9. The GreenModule is loaded

Clicking any Send button creates an instance of this event that's ready to carry an application-specific pay load: a DTO, a couple of String variables, or any other object.

Figure 3.9, “The GreenModule is loaded”'s example uses an ActionScript class called GirlfriendDTO. No Cairngorm-style mapping is required between the event being sent and the modules. For example, if you send Green event to the RedModule, nothing happens since the latter is not listening to Green event.

This application and its source code are deployed at http://tinyurl.com/5n5qkg.

Flex Builder's project has a folder called modules that contains two modules: RedModule and GreenModule. The red one is listening for the arrival of the girlfriend's first and last name packaged in our single event class as the two separate strings listed in Example 3.19, “RedModule.mxml”.

Example 3.19. RedModule.mxml

The green module expects the girlfriend's name in a form of GirlfriendDTO.

Example 3.20. GreenModule

The GirlfriendDTO is pretty straightforward too, as Example 3.21, “GirlFriendDTO” shows.

Example 3.21. GirlFriendDTO

package dto /** * This is a sample data transfer object (a.k.a. value object) */ { public class GirlfriendDTO { public var fName:String; // First name public var lName:String; // Last name } }

The next step is to create a single but universal event class. It will be based on the DynamicEvent class, which allows you to add any properties to the event object on the fly. For the example, GirlfriendDTO is the object. Here's how dynamic event can carry the GirlfriendDTO:

var myDTO:GirlfriendDTO=new GirlfriendDTO(); myDTO.fName="Mary"; myDTO.lName="Poppins"; var greenEvent:ExEvent=new ExEvent("GreenGirlfriend"); greenEvent.girlfriend=myDTO; someObject.dispatchEvent(greenEvent);

Sending any arbitrary variables with this event will be straightforward:

var redEvent:ExEvent=new ExEvent("RedGirlfriend"); redEvent.fName="Mary"; redEvent.lName="Poppins"; someObject.dispatchEvent(redEvent); The ExEvent is a subclass of DynamicEvent, which has a little enhancement eliminating manual programming of the property Event.preventDefault: package{ import mx.events.DynamicEvent; public dynamic class ExEvent extends DynamicEvent{ private var m_preventDefault:Boolean; public function ExEvent(type:String, bubbles:Boolean = false, cancelable:Boolean = false) { super(type, bubbles, cancelable); m_preventDefault = false; } public override function preventDefault():void { super.preventDefault(); m_preventDefault = true; } public override function isDefaultPrevented():Boolean { return m_preventDefault; } } } The function preventDefault() is overridden because the class DynamicEvent does not automatically process preventDefault in cloned events The code of the test application below loads modules, and then the user can send any event to whatever module is loaded at the moment. Of course, if the currently loaded module does not have a listener for the event you're sending, tough luck. But the good news is that it won't break the application either, as shown in Example 3.22, “An application that tests generic event ExEvent”. Example 3.22. An application that tests generic event ExEvent The function sendGreen() sends an instance of ExEvent carrying the DTO inside, while the sendRed() just adds two properties fName and lName to the instance of ExEvent. Instead of using a DTO, you could've used a weakly typed data transfer object: var myDTO:Object={fname:"Mary",lname:"Poppins"}; But this may result in a tiny bit slower performance and the code would be less readable. On the positive side, there would be no need to explicitly define and share the class structure of the DTO between the application (the mediator) and the module. You can use this technique for creating quick and dirty prototypes. To summarize, using a single dynamic event spares you from tedious coding of dozens of similar event classes. On the negative side, because this solution does not use the metatag Event declaring the names of the events, Flex Builder won't be able to help you with the name of the event in its type-ahead help. In vast majority of RIAs you can afford to lose a couple of milliseconds caused by using dynamic event. Using a single dynamic event is one more step toward minimizing the code to be written for your project.
Summary In this chapter you learned by example how to start enhancing the Flex framework with customized components and classes, such as CheckBox, ComboBox, DataGrid, DataForm, DataFormItem, ValidationRule. You also saw how to use these components in your applications. The source code for this chapter comes as two Flex Builder projects – Business Framework that includes sample applications discussed in this chapter and Business Framework Library that includes a number of enhanced Flex components (some of them were shown here in simplified form) that can be used in your projects too. The clear.swc component library is offered for free under MIT license as a part of the open source framework Clear Toolkit– just keep the comments in the source code giving credits to Farata Systems as the original creator of this code. You can find out the up to date information about all components included into Clear Toolkit by visiting popular open source repository Sourceforge, or to be more specific, the following URL: https://sourceforge.net/projects/cleartoolkit. Make sure that you've tested theses components thoroughly before using them in production systems. In this chapter we reviewed and explained why and how we extended several Flex components. We started with simpler CheckBox and ComboBox components just because it was easier to illustrate the process of extending of components. But then we did some heavy lifting and extend such important for every enterprise developer Flex components as Form and Vailidator. You've seen working example application that would integrate validators into a DataForm and DataGrid componens. Besides extending components, we've shown you some best practices (using resources and writing single-even applications) that greatly minimize the amount of code that application developers have to write. You'll see more of extended components in Chapters 6, 9, and 11. But now let's discuss convenient third party tools that can be handy for any Flex team working on an enterprise project.

Comments for Building an Enterprise Framework - Enterprise Development with Flex, Part 3 (http://www.insideria.com/2009/05/building-an-enterprise-framewo-1.html)

Building an Enterprise Framework - Enterprise Development with Flex, Part 3

Validation

Sample Application – DataFormValidator

Class ValidationRule Explained

Embedding Validation Rules into a DataGrid

Note

Minimizing the Number of Custom Events

Summary

Comment from George on 2009-08-14

Comment from David Arakea on 2009-08-14