That is unless you happen to have elements with your xml file that use an xsi:type attribute to indicate that their contents is actually that of a derivative element (such as an extension, restriction, etc). In these cases Flex just ignores the xsi:type and decodes against the original element type – which aint much help. What’s suprisising is that the Flex classes have been built with xsi:type in mind (storing the type in custom classes implementing IXMLSchemaInstance), but just seems to have been missed when implementing XMLDecoder – always saves the element type in the xsitype property of IXMLSchemaInstance

Whether you love it, hate it or are just indifferent,  xsi:type is part of the XSD standard and all it takes is a few tweaks for Flex to handle it correctly.

I’ve included a CustomXMLDecoder class below, but firstly:

A quick primer on xsi:type

If you are unfamiliar with xsi:type here is  a quick example of it in action:

In an XSD file we have a complex type called user:

<xs:complexType name="User">
 <xs:sequence>
 <xs:element name="username" type="xs:string" />
 <xs:element name="password" type="xs:string" />
 </xs:sequence>
 </xs:complexType> 

And we have another complex type that is an extension of User called InternalUser :

<xs:complexType name="InternalUser">
 <xs:complexContent>
 <xs:extension base="User" >
 <xs:sequence>
 <xs:element name="staffId" type="xs:string" />
 </xs:sequence>
 </xs:extension>
 </xs:complexContent>
 </xs:complexType>

In an XML file implementing this schema we have a set of User elements. As you can see below one of which includes contains an xsi:type attribute that indicates that the contents is actually that of an InternalUser.

<user >
 <username>joeCitizen</username>
 <password>1234</password>
 </user>
 <user xsi:type="InternalUser" >
 <username>jamesBond</username>
 <password>5678</password>
 <staffId>007</staffId>
 </user>

CustomXMLDecoder

After hours of trawling through  mx.rpc.xml.XMLDecoder, it was surprisingly straight forward to fix the shortcoming by overriding a couple of methods within XMLDecoder.

As an added tweak i’ve included a property to the class that determines the behaviour when attemptying to decode an xsi:type that hasn’t been registered with the SchemaTypeRegistry.

ignoreXSITypeIfNotRegistered:Boolean = false;

If this property is set to true then the decoder will ignore an xsi:type that is not registered against an ActionScript class, and try to decode it against the original element type instead (esentially replicating the functionality of XMLDecoder). This ensures that unexpected xsi:type extensions to a element  are decoded as the element type rather than generic object proxies.

If the xsi:type is registered then it will always use it.

Here is the class:

package
{
import mx.rpc.xml.*;

public class CustomXMLDecoder extends XMLDecoder
 {

 public function CustomXMLDecoder()
 {
 super();
 }

 /**
 * Set this flag if you want unregistered xsi types to be ignored (and objects to be decoded against the
 * base element type instread).
 * If the xsi type is registered then it will always be used over the base element type
 */
 public var ignoreXSITypeIfNotRegistered:Boolean = false;

 /**
 * Decodes a element based on the xsi:type. If the type isn't registered then it
 * checks the ignoreXSITypeIfNotRegistered property of the class.
 *
 * If true - decodes against the element type (and ignores the xsi:type)
 * If false - uses object proxy.
 */
 public override function decodeElementTopLevel(definition:XML, elementQName:QName, value:*):*
 {
 var content:*;

 if(value is XML)
 {
 var xsiType:QName = getXSIType(value);
 var isXSITypeRegistered:Boolean = typeRegistry.getClass(xsiType) != null

 if(xsiType != null && (isXSITypeRegistered || ignoreXSITypeIfNotRegistered == false))
 {
 content = createContent(xsiType);
 decodeType(xsiType, content, elementQName, value);
 return content;
 }
 }
 return super.decodeElementTopLevel(definition, elementQName, value);
 }

 /**
 * Decodes agains the xsi:type (if available) rather than the defined element type
 */
 public override function decode(xml:*, name:QName=null, type:QName=null, definition:XML=null):*
 {
 if(xml is XML)
 {
 var xsiType:QName = getXSIType(xml);

 if(xsiType != null)
 type = xsiType;
 }
 return super.decode(xml, name, type, definition);
 }
}

Hope that helps other people out there  – as this was previously the only real show stopper for using the Schema classes in some of our projects.

———

One last thing,

Can anyone point out to how override the decoding of nested arrays of elements?

Ususally XML will be structured so that an array of items is wrapped within a parent element

e.g the child ‘item’ elements are located within an <items/> element

<item>
 <name>Parent</name>
 <items>
   <item >
     <name>Child A</name>
   </item>
   <item >
     <name>Child B</name>
   </item>
 </items>
</item>

In Flex this data may be registered to a  class such as this one:

package
{
 [Bindable]
 public class ItemVO
{
 public var name:String;
 public var items:ArrayCollection;

 public function ItemVO():void
 {
 }
}
}

Unfortunately the decoder always includes the extra level when decoding – resulting in an ArrayCollection containing a single item (an ArrayCollection) that contains the array of items.

Does anyone know of a way to map this relationship better so that the items.item in the xml maps directly to the items ArrayCollection in the Class?

Ta,

Dom

——-

I don’t like reposting Flex related news; however I’m please to see that Adobe have decided to revisit their original naming strategy for the new Flex 4 components.

There is a good discussion happening on their forums on Flex 3/4 component compatibility – the distinction between flex 3 and flex 4 components, namespace/naming conventions, and IDE/documentation/CSS implications.

It is a response to the community’s criticism of the whole “Fx” thing – naming the new Flex 4 components with a class prefix to distinguish them – such as “FxButton, “FxList”, etc.

Most developers seem to agree that separate namespaces for the halo and spark (gumbo) components would be most consistent and future proof and doesn’t further complicate usage considering that most developers already utilise additional namespaces for custom components and 3rd party libraries.

The general consensus seems to support three namespaces – the default for language specific elements – e.g. <Style>, <Script>), and two separate namespaces for the Flex 3 and Flex 4 components ( e.g. – <mx:Button> and <fx:Button>)

I have to agree that this solution is preferable over the original “Fx” class name prefix strategy. A key concern/priority for Adobe seems to be minimizing the complexity of the initial learning curve for new Flex developers (part of their reasoning behind choosing class prefixes over additional namespaces).

I agree with this concern, but believe that due to the overlapping functionality within the two component sets, any proposed solution is going to increase this complexity but at least the latter provides a consistent usage of xml namespace that existing flex developers will understand immediately, and new developers will appreciate in time.
Adobe is due to finalise their decision soon, and the discussion is ongoing.

Forum discussion here:
http://www.adobeforums.com/webx?128@@.59b7cdf0

Original Post here:
http://davidzuckerman.com/adobe/2009/02/10/help-us-decide-where-to-go-with-flex-4/

1.  Part 1 – Introduction and background
2.  Part 2 – Overview of Flex’s XML Schema classes (inc example code)

Part 2 – Overview of Flex’s XML Schema classes (including example code)

This post covers how to take advantage of these classes (including example code) – as at the time of writing there doesn’t seem to be any discussion of these features by Adobe or the community at large. I’ll also list a few caveats we have come across in using these classes.

First things first. The set of classes I will be referring to are found in the mx.rpc.xml package. If you look at the official documentation you will only find a handful of classes that support simple XML encoding and decoding. This is because the majority of the classes relating to XML Schema contain [ExcludeClass] metadata that excludes them from documentation and code hinting.

The easiest way to get visibility of these classes in your code is to place a copy of this package in your project and comment out all the [ExcludeClass] tags above the class definitions.

The key classes are:

• SchemaManager (manages multiple schema definitions)
• Schema (manages a single XML Schema Definition)
• SchemaLoader (manages the loading of an XML schema (including any imports/includes) at runtime)
• SchemaTypeRegistry (maps an XML schema type to an ActionScript Class)
• XMLDecoder (decodes an XML document into ActionScript objects based on a XML Schema definition
• XMLEncoder (encodes an ActionScript object into XML based of an XML Schema)

Example and explanation:

A really basic example Flex app that covers the core functionality of these classes can be viewed here (right click for source).

The primary steps are outlined below:

1. Create an instance of SchemaLoader and asynchronously load an XML schema from a given URL

This automatically loads any other schemas that are defined in XSD import or include elements.

schemaLoader = new SchemaLoader();
schemaLoader.addEventListener(SchemaLoadEvent.LOAD, schemaLoader_loadHandler);
schemaLoader.load("example.xsd");

2. Once the schema is loaded, add it to the SchemaManager and register any ActionScript classes to their corresponding schema type:

private function schemaXMLLoader_loadHandler(event:SchemaLoadEvent):void
{
    schema = event.schema;
    schemaManager.addSchema(schema);
    schemaTypeRegistry.registerClass(new QName(schema.targetNamespace.uri, "example"), ExampleVO);
}

3. Load an XML file based off that schema.

4. Once the XML is loaded, decode the contents using XMLDecoder. Any classes registered in the schemaTypeRegistry will be used when decoding the xml

var xmlDecoder:XMLDecoder;
var qName:QName;
var result:*;

xmlDecoder = new XMLDecoder();
xmlDecoder.schemaManager = schemaManager;

qName = new QName(schema.targetNamespace.uri, "results");
result = xmlDecoder.decode(xml, qName)

5. Encode a custom ActionScript class back into XML using XMLEncoder. XMLEncoder.encode() supports various ways to define the corresponding element in the schema  (top level element, a specific type or even a custom XSD definition) that will be used to encode the Actionscript object.

var qName:QName;
var xmlEncoder:XMLEncoder;
var xmlList:XMLList;

qName = new QName(schema.targetNamespace.uri, "Example");
xmlEncoder = new XMLEncoder();
xmlEncoder.schemaManager = schemaManager;
xmlList = xmlEncoder.encode(exampleVO, qName);

For futher explaination check out the source inside the example applicatio.

Issues and Notes

There are a few things to be aware of when using these classes.

1. It requires a XML Schema to already be in memory when decoding a loaded XML file. As this is an asynchronous task it is best to load the schemas required before loading any XML files based off them. The alternative is to check each XML file for schema information when they load, and delay the decoding of the data until that schema has then loaded. This would require additional checks and steps each time xml data is loaded.

2. Any additional schemas included or imported within the top level schema loaded by SchemaLoader must be referenced using an absolute path. This is because SchemaLoader assumes that relative paths are relative to the main application swf URL (and not relative to the original XSD url).  As these two locations are unlikely to be the same in a real world project, changing these URLs to be relative to the swf will make it work with Flex, but will prevent any other XSD editor from being able to find the corresponding includes or imports.

As this will be an issue when relying on any XML API using relative paths that is outside the direct control of the Flex developer, I would say this is a bug and have submitted it to Adobe as such (link). Feel free to add your support to it.

—————————–

UPDATE July 2010

I’ve  created an updated version of this example project that demonstrates some of the more advanced scenarios that people have posted questions about. This version targets flex 4.0 – but the code base is essentially identical to the old 3.x versions. I’d always recommend targeting the most recent 3.x or 4.x version of the flex rpc library as the flex team seem to make improvements in every release. Having said that, these mx.rpc libraries aren’t something i’m using on a regular basis – so i’m not actively checking what’s new or changed in each release.

This example includes the following additional scenarios/use cases:

• encoding to multiple ActionScript classes
• encoding/decoding from multiple actionscript classes
• encoding/decoding attributes as well as elements
• nested child elements decoding to an ArrayCollection
• basic validation of an XML file against the XSD

view it here (right click to view source)

1.  Part 1 – Introduction and background
2.  Part 2 – Overview of Flex’s XML Schema classes (inc example code)

Part 1 – Introduction and background

This post explains some reasons on why the automated mapping of ActionScript classes to XML Schema definitions can be a better alternative to other data integration options available to Flex (in certain circumstances).

Preface

Earlier in the year we were re-evaluating the various data formats available, in order to determine which options required the least amount of hand crafted serialisation for both the front end (Flex) and the backend (at Massive this is almost always .NET, however a significant proportion of our applications rely on 3rd party back ends utilising all manor of technologies).

We have utilised pretty much all data formats at some point or another (remoting with WebORB and Fluorine, JSON, SOAP and XML), they all have their pros and cons depending on the nature of project. Also, our .NET team generally prefer XML based REST API’s over SOAP/Remoting, as (among other things) these can be easily debugged in a browser, and are more easily cached (a factor that becomes significant when determining the scalability of large projects with high levels of data transfer). They also don’t tie the output from the server to a specific frontend solution (ie Flex/Flash) as is the case with remoting.

Flex provides functionality to automatically convert pretty much all the raw data types into primitive ActionScript objects, however apart from explicitly mapping ActionScript classes to server objects using remoting and [RemoteClass] none of the others support automated serialisation to and from custom ActionScript classes. So pretty much every data format requires some sort of manual serialisation (i.e custom code) to convert the data from the server into instances of specific classes (such as value objects – VOs) within the application.

Our aim was to determine if there was an existing solution that required minimal effort (code) on both the front end and back end that would facilitate automatic mapping of data between the server objects and ActionScript classes, and not limit the ability to cache common requests on the server.

Introduction

It was about then that I stumbled across the suite of XML Schema classes available in Flex 3 in the mx.rpc.xml package.  It allows you to encode/decode an XML document at run time using it’s referenced XML Schema (XSD). Not only does this automatically convert to and from primitive XSD elements (something the Flex SOAP classes also support – a good example being xsd:DateTime into a Date object), but more importantly, it allows you to register specific ActionScript class definitions against element definitions defined within the XSD using the following syntax:

SchemaTypeRegistry.getInstance().registerClass("ns::example", ExampleVO);

This means that the content of any XML document that references a valid XSD schema can be automattically serialised into strongly typed ActionScript objects without any manual parsing/populating of the data.

If you look at the documentation for the mx.rpc.xml package you will only see a handful of classes that support simple XML encoding and decoding. This is because the majority of the classes relating to XML Schema contain [ExcludeClass] metadata that excludes them from documentation and code hinting.

At the time I did a few google searches on this topic that turned up nothing, which is surprising as this approach provides some of the key befits of remoting just by including XSD schema definitions along side an XML document/API.

In my next post I will run through the various classes in use, provide a simple example showing how they work and explain some of the cavets I have found.

Rather than explaining it all here, I suggest you have a read of Darron Schall’s explanation of it here.

I’ve used this method for cloning custom objects in several projects without issue, but when I implemented this functionality in a current project, everytime I called ObjectUtil.copy() I received the following error:

ArgumentError: Error #2004: One of the parameters is invalid.
    at flash.utils::ByteArray/writeObject()

There is only one parameter for ObjectUtil.copy() – the object to be copied, so obviously there was something in one of my classes that didn’t like being deserialised. Unfortunately by this time there was already a reasonable inheritance chain going in my classes, and eventually I had to start stripping bits out of my classes (and superclasses) until the error went away.

It turns out that the culprit was a custom namespace property in my superclass. Whenever the namespace was defined, ByteArray.writeObject() fails to deserialise the byte array, and the copy fails.

package
{
    [RemoteClass]
    public class Example
    {
        public var ns:Namespace = new Namespace("http://www.misprintt.net");

        public function Example()
        {

        }
    }
}

Cloning an instance of this class will always throw an error:

var example:Example();= new Example();
var o:Object = ObjectUtil.copy(example);

Luckily the solution is also describe in Darron’s post. While he doesn’t indentify what problems he was having, he explains how he used the [Transient] metadata tag to avoid issues with ObjectUtil.copy().

So now that the culprit has been identified, it is just a matter of adding the [Transient] metadata tag to avoid the namespace being serialised in the first place.

package
{
    [RemoteClass]
    public class Example
    {

	[Transient]
        public var ns:Namespace = new Namespace("http://www.misprintt.net");

        public function Example()
        {

        }
    }
}

Anyway, hopefully this saves some time for those trying to decipher yet another one of those vague flash player errors :)

A good example of this is Flex’s inbuilt Drag and Drop. Generally on the web, drag and drop functionality varies greatly from implementation to implementation. Many cases don’t provide enough visual feedback to the user to fully utilise the benefits of a drag and drop system – easy, direct manipulation of information on screen.

Drag and Drop functionality within Flex is pretty solid. It works out of the box with inbuilt components, and adding it to custom components is relatively straight forward (once you understand the order of all the events in a drag-drop interaction by reading this PDF- http://blogs.adobe.com/flexdoc/pdf/dragdrop.pdf). It also allows for a reasonable amount of customization to the visual states during a drag-drop process, with the exception below.

Flex provides two possible behaviours when an object is dropped:

1. The drop is rejected and the dragged item animates back to it’s original position
2. The drop is accepted and the dragged item animates into the new position.

These behaviours are correct, however there is no means to override the actual animations that occur as a result of these behaviours, so we are stuck with the following “zoom to mouse position” transition when a drop is accepted (from mx.managers.dragClasses.DragProxy) :

// Zoom into mouse location to show drag was accepted.
var e:Zoom = new Zoom(this);
e.zoomWidthFrom = e.zoomHeightFrom = 1.0;
e.zoomWidthTo = e.zoomHeightTo = 0;
e.duration = 200;
e.play();

var m:Move = new Move(this);
m.addEventListener(EffectEvent.EFFECT_END, effectEndHandler);
m.xFrom = x;
m.yFrom = this.y;
m.xTo = parent.mouseX;
m.yTo = parent.mouseY;
m.duration = 200;
m.play();

This transition may work well when dragging data from one list to another (which is the most common use case when using the inbuilt components), but can look a bit much when dragging a large container around the screen.

You drag an object from one area of the screen to another, and when you release the mouse it scales down into obscurity before appearing in its new position. There should be a means to override this default effect.

In this example try dropping the item in the bottom right corner of one of the (white) drop areas. This transition looks wrong as the mouse coordinates are not always the intended final destination of the dropped object.

Basically there should be some way to define or override the animation that occurs on a successful drop event. It seems surprising that this animation is hardcoded within the framework, while every other visual state during the drag/drop operation is customisable.

I know it is hardly a show stopper, but I’ve submitted an enhancement request to the Flex Bug and Issue Management System (https://bugs.adobe.com/jira/browse/SDK-13472) as it is an UI issue that has already arisen in one of our commercial projects.

– D

Click on the image for the full sized version.

And if you don’t believe me – here’s the evidence: http://coldfusion.sys-con.com/read/450703.htm

The International War Crimes tribunal is probably not the right place to report atrocities such as this, but I’m sure it breaks some part of the Geneva Convention.

And why do so many people blame Flash when they see a page like this? Flash is just the tool, not the actual tool who thought it was a good idea to combine a floating ad, an expanding ad, two video ads, and three banner ads on the top of a single page (and there is more if you scroll down).

There are so many guilty parties involved – including the webmaster, the online advertisers, and especially the person who invented the eyeblaster.

Rant over and out,

Dom

While this solution solves the problem of FDT not recognising intrinsic classes such as Object and String, It doesn’t resolve a very nasty potential bug.

DON’T rename a project if you have selected “Refactoring” – “Flash Explorer File Operations” in the FDT preferences.

What happens is it refactors all the intrinsic classes in the core library and renames all the classes in the FP7 and FP8 folders as if the folders were package names. E.g. Object becomes FP8.Object, String becomes FP8.String.

This causes FDT all kinds of problems, and Eclipse hangs while trying to refresh the workspace (while consuming 100% CPU).

This has happened to me on several occasions and it took me hours to work out the issue – i tried cleaning out all the cache and project metadata from eclipse, I tried reinstalling the FDT plugin, all with no success. I eventually set up a new workspace and imported a single project and eventually discovered what had happened.

The only solution is to copy over the core classes (C:\Program Files\Macromedia\Flash 8\en\First Run\Classes) with a fresh copy, or go through and re-edit each intrinsic class.

I’ve posted the bug here.

function set value(s:String):Void
{
if(s == undefined) _value = s;
else _value = "default";
}

One option is using a logical OR operator to set default values. For example:

function set value(s:String):Void
{
_value = s || "default";
}

According to the flash LiveDocs a non-Boolean logical OR operation first converts the first operand (i.e. the expression on the left of the ||) to Boolean and if true returns the resolved value of the first operand. Otherwise it will return the resolved value of the second operand (expression on the right of the ||)

In the use case above it works fine, but after exploring the non-boolean implementation of the OR operator we found the following behaviour. In both the string literal (“hey”) and the string variable (s), the Boolean value equals true, but when placed in a logical OR operation they return different results. See below:

var s:String;
s = "hey";
trace(Boolean(s));//true
trace(Boolean("hey") //true
trace("hey" || "dude");//"dude"
trace(s || "dude");//"hey"

Can anyone explain why the String literal is treated differently than a variable containing a String literal?

Oh and word up to Ian on this one for his input :)

[UPDATE] I know I could have gone with “toBoolean() || !toBoolean()” for the title but I think that is taking it a little too far.

[UPDATE 2] The only gotcha with this approach is with numbers as a value of zero converts to false.

Amazingly over half the people in the audience weren’t using any form of version control. While we’ve been using version control for a few years now on our flash projects, It made me think about the development methodologies and processes that we have developed in the flash team at Massive over the last few years, specifically in relation to maintaining a common centralised code base.

The way i see it, there are two types of common code libraries – constant and evolving.

Constant code base
This comprises of functionality that rarely changes. Good examples of this are utility classes (e.g. trimming white space on a String or a generic XML parser). These classes are added to over time (in the case of utility classes as new conversions/formats are required), but the usage of existing methods remains the same across all projects – the returned format of a NumberUtil.toDollarsAndCents() method is always going to need to return a string with 2 decimal places.

Evolving code base
This is the common code base that evolves over time. At massive this is primarily the frameworks we use for our applications. While there is little change individually from project to project, over time our processes evolve and all the subtle improvements add up to a distinctly different framework. A project that is only 6-12 months old looks and behaves quite differently to a project started today.

Despite this, it is still necessary to version control the code base for our frameworks – because the alternative is to copy and paste core classes by hand every time we start a new project – yuck! At the same time we don’t want to have to maintain backwards compatibility in our common code base just in order to be able to recompile old projects.

Solution

Our solution to this problem has been to not version control the actual classes for our frameworks, but instead version control scripts that can automatically generate them. This way each project has its own version of the core classes that are fixed within that project, and every new project contains the most recent set of classes and structure.

There are heaps of benefits to this approach – not only do we not have to worry about breaking old projects – but we gain an extra level of standardisation across our projects no matter who initially creates them. Setting up a new project by hand can take hours and is often the most tedious part of the process. Automating this process saves time and heaps of monkey work.

Because we primarily use Eclipse for our actionscript development, we’ve been using Ant for all our build scripts (Eclipse has inbuilt support for it). Initially our scripts were responsible for creating a few folders, and some stub core classes. Over time we have extended this further to auto-generate project specific build scripts for both compiling a project and also creating specific class types on demand.

It’s an interesting variation on the various flash drawing tools that are out there.
http://jacksonpollock.org/

http://www.aharef.info/2006/05/websites_as_graphs.htm

The complex the web page the more complex the image that is created. Check out the difference between google and ninemsn. The ninemsn site nearly crashed my browser!

It threads various images in a three dimensional canvas where the user chooses which “path” to travel. While it is actually pretty linear, the animation and style works nicely.
It is created by thebarbariangroup.

Screenshots [1][2][3]

It looks terrible, almost as if Eddie knocked it up himself in his spare time…

Take a look at a couple of choice shots [1[2][3]
Follow the “download now” link here.

http://etsy.com/

This post gets three thumbnails!

Timeline browse:
Screenshots: [1] [2] [3]

Color browse:
Screenshots: [1] [2]

Location browse:
Screenshots: [1] [2]

I particularly liked the knitted sushi: