Hi Greg,

The point wasn't to encourage the use of XML instead of JSON.  It was just
to see if there was any useful mechanisms of retaining type information
and dealing with circularities.

Seems like if we can define how to record the types, that a single Reviver
parameter should be able to effectively do what AMFDecoder does.

Of course, I could be wrong...

-Alex

On 4/21/17, 12:49 PM, "Greg Dove" <greg.d...@gmail.com> wrote:

>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbooks.go
>>ogle.com%2Fbooks%3Fid%3DqtlUSkC4HRQC%26pg%3DPT1458%26lpg&data=02%7C01%7C%
>>7C424b478160694d23ad5e08d488ef801e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0
>>%7C0%7C636284009615781999&sdata=PVOZOI7ESKVIOErEPvYqs%2BX3%2BiBAR0Rqzm%2B
>>Y%2F0P5LKE%3D&reserved=0
>> =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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbooks.g
>>oogle.com%2Fbooks%3Fid%3DqtlUSkC4HRQC%26pg%3DPT1458%26lpg%3DPT1458%26dq%3
>>DAMFX%2Bspecification%2Badobe%26source%3Dbl%26ots%3D1Hx1n3jo0d%26sig%3Dpu
>>xfHwWuDSkP-jwbXVKGFmriy64%26hl%3Den%26sa%3DX%26ved%3D0ahUKEwipx8fAp7PTAhX
>>psVQKHSL1Cf4Q6AEIRjAH%23v%3Donepage%26q%3DAMFX%2520specification%2520adob
>>e%26f%3Dfalse&data=02%7C01%7C%7C424b478160694d23ad5e08d488ef801e%7Cfa7b1b
>>5a7b34438794aed2c178decee1%7C0%7C0%7C636284009615781999&sdata=4Q%2BIM%2FN
>>Rd%2B3WdeQyL%2BAgmYdMKg6aTAJ70wzZk1wrxps%3D&reserved=0>
>>
>> -Alex
>>
>>

Reply via email to