Hi,
At the moment, you can't pass native DataTypes from AS3 to JSFL:
throw new Error('Objects of type ' + type + ' cannot be passed to JSFL');
Is there a reason for not using the JSON encoder/decoder to pass values around, so you could encode any object (to native object).
And you could also pass the type as an extra field (like amfphp does) so you can reconstruct the same object on the other side.
Not sure if I understand. The main JavaScript types should serialize correctly:
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']);
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:
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.
It looks like you're new here. If you want to get involved, click one of these buttons!