Archive for the ‘Enterprise’ Category

Reflection / Introspection in Flex ActionScript

Wednesday, July 15th, 2009

As part of an effort to create enterprise components, libraries, and architectures, a company may want to take advantage of reflection. For example, a company may want a consistent way to create and populate various components. This might allow your developers to work more quickly since all of the components are handled in the same manner. However, many of the components in Flex (and, likely, many of a company’s custom components), have differences in how they’re created and populated … even when the functionality is conceptually similar. In order to accomplish a consistent interface, you may need some abstraction that allows you to dynamically create and populate objects at runtime. To that end, I thought it might be helpful to discuss the low-level how-to’s of reflection within Flex / ActionScript.

The Flex framework includes an implementation of the Class Factory pattern in mx.core.ClassFactory. This class allows you to instantiate classes determined at runtime.

Here are a couple of examples of how to instantiate a class determined at runtime:

INSTANTIATE AN OBJECT FROM IT’S CLASS

import mx.core.ClassFactory;
public static function instantiateUsingClass(classToInstantiate:Class):* {
	var myClassFactory : ClassFactory = new ClassFactory(classToInstantiate);
	var myObjectInstance : * = myClassFactory.newInstance();
	return myObjectInstance;
}

INSTANTIATE AN OBJECT FROM IT’S CLASS NAME (i.e., from a String like “com.domain.Person”)

import flash.utils.getDefinitionByName;
import mx.core.ClassFactory;
public static function instantiateUsingClassName(className:String):* {
	var classToInstantiate : Class = getDefinitionByName(className) as Class;
	var myClassFactory : ClassFactory = new ClassFactory(classToInstantiate);
	var myObjectInstance : * = myClassFactory.newInstance();
	return myObjectInstance;
}

At a basic level, mx.core.ClassFactory does the following to instantiate the class:

public var generator:Class;
...
this.generator = classToInstantiate;
...
var instance:Object = new generator();

There are other times when you need more than to simply instantiate a class. For example, you may need to query the class definition to find out what methods, properties, etc. are declared on that class. The flash.utils package provides some package-level functions for introspecting classes and objects. Here is a link to the flash.utils API: http://livedocs.adobe.com/flex/3/langref/flash/utils/package.html. For the purposes of reflection, the describeType() method is one of the best places to start (the call to getDefinitionByName() that was used above is another package-level function provided by flash.utils). Here is a way to find out what “accessor” methods (get/set methods) are declared for a class:

RETRIEVE NAMES OF ACCESSOR METHODS FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getNonstaticAccessors(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticAccessorsXML:XMLList = xmlDescriptionOfClass.factory.accessor;

	var accessors:Array = [];
	for each (var accessorXML:XML in nonstaticAccessorsXML) {
		accessors.push(accessorXML.@name);
	}
	return accessors;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.accessor, instead of xmlDescriptionOfClass.factory.accessor. In addition to @name, you might also be interested in information contained in @access, @type, and @declaredBy.

When you modify a public property on an object using dot notation (i.e., myPerson.name = “Fred”;), Flex does exactly what you’d expect and modifies the public property value. But, Flex offers an additional convenience. If you decide, at a later time, that you’d like to make the properties private and force them to be accessed through accessor methods (i.e., public function set name(myName:String):void {…}), Flex will automatically call your accessor method (without having to change your code to call the accessor, instead of the property). Hooray!

When it comes to reflection, however, the factual separation between properties (class attributes … class variables … whatever term you prefer) and accessors is maintained. The point of this tangent is that your public properties (that do not have declared accessor methods) will not be returned by the above method. Instead, in order to discover the properties of a given class, you’ll need to query for them specifically (using the “.variable” notation).

Here is an example of how to query for the attributes of a class:

RETRIEVE NAMES OF PROPERTIES (CLASS ATTRIBUTES) FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getProperties(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticPropertiesXML:XMLList = xmlDescriptionOfClass.factory.variable;
	var properties:Array = [];

	for each (var propertyXML:XML in nonstaticPropertiesXML) {
		var property:Property = new Property(	propertyXML.@name,
							propertyXML.@type.toString(),
							isStatic );
		properties.push(propertyXML.@name);
	}
	return properties;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.variable, instead of xmlDescriptionOfClass.factory.variable. In addition to @name, you might also be interested in information contained in @type.

Accessor methods (discussed earlier) are also kept separate from all of the other methods. Here is an example of how to query for the non-accessor methods of a given class

RETRIEVE NAMES OF METHODS FOR A GIVEN CLASS

import flash.utils.describeType;
public static function getMethods(classOfInterest:Class):Array {
	var xmlDescriptionOfClass:XML = describeType(classOfInterest);
	var nonstaticMethodsXML:XMLList = xmlDescriptionOfClass.factory.method;

	var methods:Array = [];
	for each (var methodXML:XML in nonstaticMethodsXML) {
		methods.push(methodXML.@name);
	}
	return methods;
}

In order to obtain the static accessors, use xmlDescriptionOfClass.method, instead of xmlDescriptionOfClass.factory.method. In addition to @name, you might also be interested in information contained in @type.

OK, great! We now have a few tools (I’m sure you’ll discover more as you begin experimenting with the reflection capabilities provided by Flex) to help us with introspection of ActionScript classes at runtime. But, hey, maybe we actually want to DO something with that information. Here is an example of how to trigger a method call on a class and method discovered at runtime:

INVOKE A METHOD ON AN INSTANTIATED OBJECT

public static function invokeMethod(objectContainingMethod:*, methodName:String, parms:Array):* {
	var method:Function = objectContainingMethod[methodName];
	var returnValue:* = method.apply(objectContainingMethod, parms);

	return returnValue;
}

= = = = = = = = = =
Now that I’ve taken your time discussing some basics of how to implement reflection within Flex / ActionScript, I’m now going to suggest that you do it differently!

I was discussing writing a blog on reflection awhile back with Justin Shacklette (Justin’s blog) and Jon Rose (Jon’s blog). Justin immediately pointed out that Spring was splitting their reflection functionality out into a separate library. This reflection library improves on some of the above techniques by implementing work-arounds for some known bugs, etc., etc. behind the scenes. In addition, it allows you to deal with objects that might be a bit more intuitive than the XML object that is returned by describeType(). On the other hand, this means that you’ll occasionally need to step down through the object hierarchy to find the desired value. I found it pretty easy to investigate the various classes and source code at this site: http://as3-commons.googlecode.com/svn/trunk/as3-commons-reflect/src/main/actionscript/org/as3commons/reflect/. The best classes to start with are Type.as and ClassUtils.as.

To get started, download the AS3 Commons Reflection library (as3commons-reflect-1.0.0.swc) from http://code.google.com/p/as3-commons/.

Add this SWC file to your Flex project’s lib folder.

Now, let’s revisit the above examples to see how they might differ when using the AS3 Commons Reflection library.

INSTANTIATE AN OBJECT FROM IT’S CLASS

import org.as3commons.reflect.ClassUtils;
public static function instantiateUsingClass(classToInstantiate:Class):* {
	var myObjectInstance:* = ClassUtils.newInstance(classToInstantiate);
	return myObjectInstance;
}

INSTANTIATE AN OBJECT FROM IT’S CLASS NAME (a String like “com.domain.Person”)

import org.as3commons.reflect.ClassUtils;
public static function instantiateUsingClassName(className:String):* {
	var classToInstantiate:Class = ClassUtils.forName(className);
	var myObjectInstance:* = ClassUtils.newInstance(classToInstantiate);
	return myObjectInstance;
}

RETRIEVE NAMES OF ACCESSOR METHODS FOR A GIVEN CLASS

public static function getStaticAccessors(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);
	var accessors:Array = type.accessors;
	return accessors;
}

RETRIEVE NAMES OF PROPERTIES (CLASS ATTRIBUTES) FOR A GIVEN CLASS

public static function getProperties(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);

	var nonstaticProperties:Array = type.variables;
	var staticProperties:Array = type.staticVariables;

	var properties:Array = nonstaticProperties.concat(staticProperties);
	return properties;
}

RETRIEVE METHODS DECLARED BY A GIVEN CLASS

public static function getMethods(classOfInterest:Class):Array {
	var type:Type = Type.forClass(classOfInterest);
	var methods:Array = type.methods;
	return methods;
}

INVOKE A METHOD ON AN INSTANTIATED OBJECT

public static function invokeMethod(objectContainingMethod:*, methodName:String, parms:Array):* {
	var methodInvoker:MethodInvoker = new MethodInvoker();

	methodInvoker.target = objectContainingMethod;
	methodInvoker.method = methodName;
	methodInvoker.arguments = parms;

	var returnValue:* = methodInvoker.invoke();

	return returnValue;
}

Ultimately, the AS3 Commons Reflection library makes a few things easier or more intuitive. Moreover, it handles some complexities and bug work-arounds for you. But, the nuts-and-bolts are still basically using the the same techniques that I discussed in the upper-half of this post.

Enterprise Reuse of Flex Components and Classes

Wednesday, April 8th, 2009

In a simple Flex (SWF) application, all of the necessary components and classes are defined in a single Flex project. In the enterprise, however, you may want to refactor some of the components and classes into a separate library so that these common components and classes can be reused across multiple Flex applications (or project teams). The most common way to do this is to create a separate Flex project that will be used to create *.SWC file. Each Flex application will then be configured to link to this SWC. A SWC file is basically an archive of external components and classes, similar to a *.jar file in Java land.

There are various reasons that an enterprise might choose to decouple the common components and classes and put them in a separate, reusable SWC file:

  • * Reuse across Flex projects
  • * Reuse across Enterprise project teams
  • * Reuse across Enterprise applications
  • * Influence/enforce/decouple enterprise look-and-feel
  • * Improve application performance
    • – Startup time
    • – file size
    • – network bandwidth usage

Once the SWC file is created, you must decide how your SWF code will link to the necessary classes residing in the SWC. At a high level, Flex provides two linking options: Static linking and Dynamic linking.

STATIC LINKING (“Merged Into Code”):
When you use static linking, the compiler includes all referenced classes and their dependencies in the application SWF file. The end result is a larger SWF file. Obviously, a larger SWF file takes longer to download from the server. On the other hand, since all of the necessary code is contained in the SWF, it will load and run quickly. Keep in mind that the browser can cache the SWF file. So, if a given user will be accessing the same SWF file multiple times, the initially increased download time might be a reasonable trade-off for faster startup times.

DYNAMIC LINKING (“External” (or Runtime Shared Library “RSL”)):
When you use dynamic linking, the refactored components and classes are not included in (they are not compiled into) the application SWF file. Instead, the SWC file remains separate from the SWF. The result is a smaller SWF file size for the main application. The downside is that the SWC must be loaded at run time. In addition, the application loads the entire library (as opposed to static linking that can limit the linking to only the items that the SWF actually uses). This can result in slower startup times and greater memory usage.

Once again, however, client-side caching can play a role. The external SWC file can be cached and reused by multiple SWF applications. Each individual SWF will be smaller due to the exclusion of the common components and classes. If the enterprise has multiple SWF applications that will use the same SWC file, the cumulative size of the downloads might be lessened by using dynamic linking.

The enterprise will need to consider the tradeoffs of each option with respect to its situation and goals, in order to determine the best course of action. Components that will be reused across the enterprise will likely result in the creation of enterprise guidance and best practices. Components and classes whose reuse is limited to smaller divisions may need the flexibility to make the decision that is best for their particular sitation.

Using Flex to integrate with existing web sites

Thursday, April 2nd, 2009

In a couple of my previous posts, I discussed the integration of a Flex application into an existing web site. One post (link to post) discussed dynamically controlling the HTML real estate used by an embedded Flex application. The other post (link to post) gave a (hopefully) simplified view of code snippets that can be used to communicate between Flex and JavaScript under various scenarios. These were low-level, “how-to” posts. In this post, I’d like to explore some of the ways that this type of integration might benefit the enterprise.

In this particular situation, I was representing a company that had a new product/service offering. This offering is something that many existing E-Commerce web sites would like to add to their existing web site. Conceptually, this is a pretty common situation. However, integration is often more difficult to implement than it is to conceive.

That was not the case in this situation. Implementing this business offering by embedding a Flex application into an existing web site was embarrassingly easy. The integration instructions given to the E-Commerce site’s developers consisted of about 30 lines of text. This text consisted of the HTML Object/Embed tags and the JavaScript functions that the E-Commerce site’s developers needed to copy and paste into their web page. Beyond copying and pasting this text, all the E-Commerce site’s developers needed to do was to modify the JavaScript return values with the values from their web page.

They did not have to change any code on their server. They did not have to change the flow of their web pages. The Flex application that we provided them handled the external-domain server communication. We did not have to work-out the details of how the customer’s servers would access our servers and our services. We did not have to match technologies or protocols. The E-Commerce web site’s developers did not have to modify their server code to know, understand, and call our services.

This integration did not take months or years. This integration took something on the order of minutes or hours. I suppose you could say it took days, if you include time to arrange phone calls between the developers, etc.

Think about that. A new business offering was implemented in a matter of days.

Obviously, the company (or enterprise project team) providing the services, will have to build the backend for the services. But, they would have to do this anyway. The huge payoff is at integration time. And, if these services are used by many “clients” (either by selling the same offering over and over to many customers … or, within an enterprise, by allowing many project teams and existing applications to leverage your services), the cost-benefit analysis becomes compelling. Moreover, the more you can shrink the integration time, the easier it becomes to close a deal. In corporations, various levels of the hierarchy often have different levels of budgetary decision-making power. The lower the integration cost, the fewer levels of approval you will need to close a deal.

Admittedly, this was a specific type of business offering. It clearly does not replace all other forms of integration. As with any architectural tool (or software design pattern), you still must choose the best solution for a given challenge. There are many places where SOA, RESTful Web Services, XML, etc. will be the better solution. But, when this type of solution fits, it can really payoff!