Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread JSON Deserialisation Question
Thu, May 18 2017 4:02 AMPermanent Link

Mark Brooks

Slikware

Avatar

Tim et al

I have a query regarding the use of TReader to deserialise JSON into an EWB class instance.

Imagine the scenario where I have a TUser class, for example, which has fields for Name (string), Title (string) and Email (string). I create an instance of this class and use it to deserialise the first User who has values for Name, Title and Email. I then use the class instance to deserialise a second User who does not have a value for Title. In this scenario, my class instance will actually retain the Title value from the first User, resulting in misleading data.

Clearly I could "zap" all fields in my class instance prior to each deserialisation, however I don't believe there is a "generic" mechanism for this (e.g. Object.ZapFields) so I would have to go through each field hard-coded.

Preferably, is there a way to have EWB "zap" a field during deserialisation if it's not found in the incoming JSON?

Thanks in advance
Mark
Thu, May 18 2017 7:48 AMPermanent Link

Matthew Jones

Mark Brooks wrote:

> then use the class instance to deserialise a second User

Just .free the instance, and create a new one. Perfect every time. 8-)

--

Matthew Jones
Thu, May 18 2017 8:43 AMPermanent Link

Mark Brooks

Slikware

Avatar

>>"Matthew Jones" wrote:
>>Just .free the instance, and create a new one. Perfect every time. 8-)

Sure, essentially same as "zapping", just not very "EWB elegant". I shouldn't really need to do this IMHO. I believe that the TReader should handle it properly.
Thu, May 18 2017 9:50 AMPermanent Link

Matthew Jones

Mark Brooks wrote:

> Sure, essentially same as "zapping", just not very "EWB elegant". I shouldn't really need to do this IMHO. I believe that the TReader should handle it properly.

I don't think I agree. If you have an object that is complex, with children and links to other things, you might want to keep those existing properties. I can't see how it would know well enough to give you a sensible default. Whereas object creation does indeed set up the defaults as you want them.

--

Matthew Jones
Thu, May 18 2017 9:57 AMPermanent Link

Mark Brooks

Slikware

Avatar

>>"Matthew Jones" wrote:
>>I don't think I agree. If you have an object that is complex, with children and links to other things, you might want to >>keep those existing properties. I can't see how it would know well enough to give you a sensible default. Whereas >>object creation does indeed set up the defaults as you want them.

I think that's wrong for PUBLISHED properties. You can have what you want elsewhere in the class, but these are specifically the ones that get serialised to and from JSON. They should therefore reflect the JSON post-serialisation surely? That's certainly how c# (boo, hiss) etc seem to work.
Thu, May 18 2017 10:07 AMPermanent Link

Matthew Jones

Mark Brooks wrote:

> That's certainly how c# (boo, hiss) etc seem to work.

You may me go and look, because the way I've used it just gets me the object from scratch. This though implies it leaves the contents as is, and adds to it:

http://www.newtonsoft.com/json/help/html/PopulateObject.htm



--

Matthew Jones
Thu, May 18 2017 10:42 AMPermanent Link

Mark Brooks

Slikware

Avatar

>>"Matthew Jones" wrote:
>>You may me go and look, because the way I've used it just gets me the object from scratch. This though implies it >>leaves the contents as is, and adds to it:

I believe it can be setup this way, although I am no expert. The guys I work with are however (allegedly). The other side issue is the (potentially) large amount of additional JSON that needs to be returned for fields that essentially have no (or the default) value.
Thu, May 18 2017 11:51 AMPermanent Link

Matthew Jones

Mark Brooks wrote:

> The other side issue is the (potentially) large amount of additional JSON that needs to be returned for fields that essentially have no (or the default) value.

Well obviously it isn't down to me to choose, but the solution is simple, and allows for both modes. No one is saying you have to send more data.

--

Matthew Jones
Thu, May 18 2017 12:11 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< Preferably, is there a way to have EWB "zap" a field during deserialisation if it's not found in the incoming JSON? >>

Two things:

1) The default values specified for published properties only affect serialization, not deserialization.  They are used to ensure that the minimal amount of JSON is generated during serialization, but only at design-time with on-disk JSON.  They are currently not used at run-time because EWB does not emit default values as part of the RTTI in the JS, in an effort to keep the JS as small as possible. An effort, I might add, that EWB has been losing for a while.

2) It's just as quick to simply destroy/create a class instance as it is to "zap" the member variables for a class.

If you want to initialize an existing class instead before deserialization, you should use the BeforeLoad protected method to do so.

Tim Young
Elevate Software
www.elevatesoft.com
Thu, May 18 2017 1:00 PMPermanent Link

Mark Brooks

Slikware

Avatar

>>Tim Young [Elevate Software] wrote:
>>It's just as quick to simply destroy/create a class instance as it is to "zap" the member variables for a class.
>>
>>If you want to initialize an existing class instead before deserialization, you should use the BeforeLoad protected >>method to do so.

Hi Tim.

Hope you're good and thanks for the response.

I want to try and keep this mechanism as generic and at as low a level as possible. Since all of my classes that use TReader descend from a base class, that would be a great place to handle my issue. So, your suggestion of BeforeLoad sounds perfect, apart from I'm struggling to find it! Can you just confirm which class this method belongs to?

Thanks
Mark
Page 1 of 2Next Page »
Jump to Page:  1 2
Image