Thanks for that info.
Most often for client work, I don't choose the data transfer format, and
tbh I would probably choose json vs. xml if I could choose between the two.
The simplest json based 'typed' data I have seen sends
"__type":"typename_here" in the generic objects, which can be used during
deserialization. This is kind of like class alias, but afaik there is no
official standard for anything like this (I have not searched/checked
recently).
I think it could be useful to add compiler-generated support into
metadata-marked classes so that they supported the ability to create and/or
update existing values for values from generic objects, which might include
nested complex types.
something like (pseudo code) (inside ThisClass ):
//support methods
private static const _permittedFields:Array = ['field1', 'field2'];
public static function fromObject(object:Object,
inst:ThisClass=null):ThisClass{
if (!inst) inst = new ThisClass();
for (var field:String in obj) {
//the raw object might have meta data for deserialization or
unlrelated fields:
if(_permittedFields.indexOf(field)==-1) continue;
switch (field) {
//compiler-generated special-casing of complex type fields:
case "complexField" :
inst[field] = ComplexFieldType.fromObject(ob
j[field],inst[field]]);
break;
default:
inst[field] = obj[field]
break;
}
}
return inst;
}
public static function toObject
//interface methods
public function updateFrom(obj:Object) :void{
fromObject(object,this)
}
public function getAsObject():Object{
//tbd but similar to a reverse version of the above
}
This type of thing could support both the simple VO case and more complex
deserialization
I have done the above sort of thing manually in the past on a few occasions
at least.
I haven't thought too deeply about this (inherited fieldsets need to be
considered and whether a parent class has the option enabled or not so that
part needs some thought, for example) so maybe there are flaws in the above
idea and perhaps it is more complicated to have the compiler support it
than I think. But if there is consensus that this type of thing is
worthwhile, I would be happy to try for this as some sort of opt-in
compiler support.
On Fri, Apr 21, 2017 at 3:08 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 4/19/17, 1:29 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Yes I was thinking more in terms of the times I did this type of thing to
> >support nested typed objects from raw json, more than simple VOs. Not so
> >much in terms of using reviver, but going through from json -> generic
> >object -> typed object with most of the support for the last part being in
> >the abstract base class, and extra field mappings to complex field types
> >defined in subclasses for specific fields. It was maintainable at the
> >individual class level, but still quite complicated. Poor man's amf.
> >
> >Probably not relevant here for simple VOs.
>
> Did you look at the AMFX classes (not regular AMF)? It might serve as a
> starting point for a JSON version.
>
> [1]
> https://books.google.com/books?id=qtlUSkC4HRQC&pg=PT1458&lpg
> =PT1458&dq=AMFX
> +specification+adobe&source=bl&ots=1Hx1n3jo0d&sig=puxfHwWuDS
> kP-jwbXVKGFmriy
> 64&hl=en&sa=X&ved=0ahUKEwipx8fAp7PTAhXpsVQKHSL1Cf4Q6AEIRjAH#
> v=onepage&q=AMF
> X%20specification%20adobe&f=false
> <https://books.google.com/books?id=qtlUSkC4HRQC&pg=PT1458&lpg=PT1458&dq=AMFX+specification+adobe&source=bl&ots=1Hx1n3jo0d&sig=puxfHwWuDSkP-jwbXVKGFmriy64&hl=en&sa=X&ved=0ahUKEwipx8fAp7PTAhXpsVQKHSL1Cf4Q6AEIRjAH#v=onepage&q=AMFX%20specification%20adobe&f=false>
>
> -Alex
>
>
