xJSFL

Not sure if I understand. The main JavaScript types should serialize correctly:

• http://www.xjsfl.com/support/api/flash/jsflinterface#serialize

Obviously native AS3 classes such as Sprite or NetConnection have no JavaScript equivilent, so there's no way to serialize/deserialize.

Of course, you could always serialise data as JSON/XML before passing data from/to JSFL/AS3, then process (once deserialised) on the other side as you suggest.

Can you post some sample code to illustrate what's not working for you?

OK, had a think and I think I get you.

Basically, instead of an error being thrown, you just want to pass over unknown objects like this:

<custom>{
    "type":"ClassRef",
    "data":{"a":1, "b":2, "c":3}
}
</custom>

That's fine, in itself, but it strikes me that the JSFLInterface class (on both the receiving JSFL and AS3 sides) would need some kind of extra intelligence to know how to instantiate the object on the other side, perhaps by way of a pre-registered callback.

Or if it was done automatically, how would xJSFL know if it's just a static object, or whether it needs a new() constructor?

Either that, or you just accept that for unknown classes, they are serialialised on the passing side, and the receiving side is deserialised to an object only, and the recieving method / function is left to instantiate whatever object needs to be instantiated.

EDIT: this post was made before your last comment

I'm sorry for not being that clear. I ment other classes, like the Rectangle, Point, etc.

The as3corelib jsonencoder does it like this:

else // o is a class instance
{
    // Loop over all of the variables and accessors in the class and 
    // serialize them along with their values.
    for each ( var v:XML in classInfo..*.( 
        name() == "variable"
        ||
        ( 
            name() == "accessor"
            // Issue #116 - Make sure accessors are readable
            && attribute( "access" ).charAt( 0 ) == "r" ) 
        )
    )
    {
        // Issue #110 - If [Transient] metadata exists, then we should skip
        if ( v.metadata && v.metadata.( @name == "Transient" ).length() > 0 )
        {
            continue;
        }
        
        // When the length is 0 we're adding the first item so
        // no comma is necessary
        if ( s.length > 0 ) {
            // We've already added an item, so add the comma separator
            s += ","
        }
        
        s += escapeString( v.@name.toString() ) + ":" + convertToString( o[ v.@name ] );
    }
    
}

With this you can use custom classes in as3 for code-hinting and autocompletion, and have native objects in jsfl with the same properties.

Serializing and deserializing the data by hand is always an option, but it would be nicer if it was done automatically.

If it's not clear, I could change the xJSFL code to show you how powerfull it could be :)

To answer your last comment: yes, like that :)

First step is to just pass it as an plain object, that would be a huge step forward.

After that you there could be something implemented for automatic mapping.
In AS3 this could be done via:

// registering
registerClassAlias('ClassName', ClassName);
// by decoding
var classRef:Class = getClassByAlias(o['_type']);

Yeah, it's a fair request!

I could certainly add the JSON serialization for now, then look at the more advanced stuff for the next, or a later release?

Sounds good!

If you have any questions, at our company we're using the same method to communicate between Flash and PHP/.NET and map DTO's to their correct type, so I have experience with this stuff :)

Well, feel free to update the source and make a pull request on GitHub!

I should really make a 1.02 development branch now the 1.01 release is out anyway...

OK, been doing a test or two, and I can see a problem almost straight away with serialising object from JSFL to AS3.

Once you start iterating deeply into objects like Document, you very quickly get invisible errors when accessing sub-objects like Tools. For example, serializing a Collection would error via the "dom" property, as it contains the Tools object.

The only ways round this I can see for now is to:

1. Change "dom" from a property to a method, i.e. getDOM(); but then that doesn't consider any other objects that may also cause these errors
2. Limit the depth of serialisation of custom objects, perhaps by a function argument, i.e. JSFLInterface.serialize(value, 1);

Although I get the impression that your needs lean towards AS3 > JSFL rather than the other way round, which may be another option, i.e. make JSFLInterface work AS3 > JSFL only for the moment.