Some Notes from Customizing the Flex Framework

Customization is broken down into 4 buckets:

   - UI
   - Data Management
   - Data Display
   - Control Behavior

Customizing UI
MXML tags map to an AS class
Every tag attribute turns into a property, style, event handler
Some class have no class mapping and are hard coded into compiler (Script, Metadata, Style)
Every MXML file corresponds to a new AS class where the name of the MXML file is thename of the AS class (code be kept by turning on keep-generated-actionscript=true)
MXML objects with ids correspond to member variables of that AS class

To create an MXML object that is not visible, extend from IMXMLObject
The only method it implements is initialized(doc, id) - can be no-op

Skinning and styling infrastructure built into the framework at the component level
You can effect infrastructure built into the framework at the component level
Styles are applied to individual components or across broad sets of components
You can only get so far with styling, at some point you need to turn to skinning
Skinning: modifying the appearance of a coponent by substituting in images, SWF files, or class files, with the drawing commands
Skins represent the look of a component in its different states

Effects classs live in mx.effects.*
Paired with triggers which iniitates a Flex effect on a target component
Defaullt effects lirary includes wipe, fade, Zoom, Glow, etc
Effects split into two categories: simple (pause, sound, etc - extend from mx.effects.Effect) ... and complex (resize, zoom, etc - extend mx.efffects.TweenEffect)

Writing an Effect
1. composite via parallel and sequence
2. subclass like a custom Wipe or custom Zoom
3. Extended Effect or TweenEffect to make brand new effect (requires creating a custom effect factor and a custom effect instance class)
4. Effect factory class manages the creation/destruction of the effect instance

Customizing Data Management
Customizations can be built directly into the data mgmt classes
Custom dataDescriptor
Custom collections

Hierachical data aware controls: Tree,Menu,MenuBar,AdvancedDataGrid
These support arbitrary data
Data Descriptors are used to walk the dataProvider and describe it the control
   is this node a branch or a leaf - isBranch()
   what attribute on a node describes child collection (sub collection) - getChildren()
Can use a custom data descriptor to do things like (extend DefaultDataDescriptor)

lazy loading (define getChildren that loads data when this is called)
hierarchical data does not fit the format supported by the default descriptor (i.e. children field does not exist)

Managing data sets:
Can use Array, XML, XMLList as dataProviders (internally wrapped up as a collection)
Can use Flex classes to create collections (ArrayCollection, XMLListCollection)

2 interfaces for creating custom collections:
   - IList - simple interface for indexed access to linear data
   - ICollectionView - more advanced interface to access data that is not guaranteed to be linear (e.g. use to support paging)
List based controls listen for collection change event so grid updates when list changes

Customizing Data Display
List Item Renderers can be specified as attribute or inline
With inline use the <mx:Component> tag, can use outerDocument to get scope of outer document

   <mxataGridColumn ...
      <mx:itemRenderer ...
         <mx:Component ...
            <mx:VBox ...
               ...

blogs.adobe.com/aharui - blog about tips using item renderers

Validators are triggered by an event valueCommit (by default) or manaully
Specify source - object being validated, property is property on source object being validate
Base class to extend for custom validators are mx.validators.Validator

Formatters allows formatting of data for display

Customizing Conrol Behavior
Extending controls is one way (discussed in other sessions), custom meta data is another

For the most part, meta-data is only used at compile time and is stripped out of the SWF (by the linker) at optimization time so SWF size is smaller
Some metadata is kept (Bindable, Managed, ChangeEvent, etc)
The developer can control this (compiler option mxmlc-keep-as3-metadata in Flex 2)

Problem was 3rd party developers don't know what meta-data to preserve, so Flex 3 SWC libraries now declare what metadata the linker should preserve when linking in code from that library. The app preserves the union of metadata from all the libraries that contributed code to the app.

A good place to use custom meta data is for tooling, automation testing, etc. For example, use "testing directives" so that test harnesses can be run against custom components developed.

Custom meta data from code can be introspected

When bugs found in the framework:
- File a bug (bugs.adobe.com)
- Vote on bugs - promotes bugs internally so that is more likely to be fixed for the next drop
- In the meantime (till bug is fixed):
   Option 1: Extend the offending control and insert your fix
   Option 2: Copy the class into a seperate package and use your fixed version
   Option 3: Edit the offending source code directly in the mx.* directory - problematic