Posts Tagged ‘Framework’


I am currently looking into a Flex application framework for my upcoming Flex Enterprise project. In Flex application development Cairngorm and PureMVC framework is a de facto standards. For my project we are looking into a possibility to introduced Swiz framework for application architecture.

Swiz official website stated this as “The brutally simple micro-architecture for Enterprise ActionScript development”. This tagline is very catchy and promise to cater key requirement of any application i.e. simple framework for enterprise level application. While judging this statement I have migrated some of the small apps into Swiz framework and reduced 30-40% of codebase, it is interesting.

Here I am giving you simple steps to give a start Swiz based application:
Create a context file for configuring Swiz framework. In this configuration we are providing the Beans and configure the Swiz framework.

  1. Create a Bean factory as repository for Bean classes.
  2. Injecting the bean where it needed using [Inject] tag. After injecting the bean you are able access the bean object.
  3. Register handle for flash event using [Eventhandler(event=”EventClass.EVENT_NAME”)] for event handling.
Swiz Context Configuration

swiz_part1

Swiz Bean factory

swiz_part2

Injecting Bean and register event handler

swiz_part3

Dispatching event

swiz_part4

Now after this simple step we can give a start to Swiz based application development. This is really a very simple as stated in Swiz website. One key point here is all metadata tag related function and properties should marked as public. Swiz framework developer’s team are also ready with Swiz AOP version (Aspect Oriented Programming). Swiz AOP gives you the powerful ability to easily configure new functionality into existing code, instead of muddying up your fundamental business logic. It is an extremely powerful methodology that Swiz makes very easy to work with.


ActionScript 3 is an Object Oriented Programming language, and here access modifiers are used for handling declaration visibility. The common access modifiers in Object Oriented Programming are Public, Private and Protected, apart from this in AS3 new access modifier namespace is introduced. This is used when we want more control over who can access class items. A namespace is a context in which names are unique. There are three steps to gaining and sharing special access to items with namespaces. First, declare a new namespace. Second, determine what items belong in that namespace. For those items, use the namespace’s name as a visibility modifier instead of public, private, protected, or internal. Third, in code that needs special access to the namespaced item, open the namespace that we have created.

Flex framework is a very good example of using namespace. In Flex framework for handling internal data they used mx_internal namespace. There are so many variables are marked as mx_internal, these variables are available for developer whenever they use mx_internal namespace. As per Adobe mx_internal is a namespace used by the Flex framework to partition out functions and properties that may change in future releases of the Flex SDK. So before using mx_internal think closely on how to avoid using this, because mx_internal mark property which you are accessing will change in next release of framework. Although this is a very good feature by framework to exposing there internal function to developer, but this is advisable to use this as a reference only not for solving any requirement. In this post I am going to describe this risk area of using mx_internal.

I have simple usecase where I am using “mx:NumericStepper” component. As per requirement we need to provide a checkbox for controlling enable and disable of text input controls of “NumericStepper” component.

Editable Disable

There are no direct property are exposed for end user devleoper for taking a reference of text input controls of “NumericStepper”. In this case we use mx_internal for taking reference of text input. See the code below for reference.

Taking a reference of inputField using mx_internal This implementation will work fine if we not upgrading the flex framework for this application. As per Adobe’s clear statement this is an internal property and may be change in future release for framework version. So we can’t say this implementation will workable always. If you see the below code we are able to access the inputField properties using mx_internal, as this inputField properties is there in <mx> framework based NumericStepper component.

inputField are accessiable in <mx> based frework

But when we upgraded our framework and started using spark component then this properties is not more available and our implementation will go wrong. 

inputField is not available in spark controls

Although “mx_internal” may solve many problem but please take this as a reference and be aware that properties or functions defined under mx_internal may change in future versions of SDK.