![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 10 of 11 total |
![]() |
Thu, May 18 2017 4:02 AM | Permanent Link |
Mark Brooks Slikware | 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 AM | Permanent 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 AM | Permanent Link |
Mark Brooks Slikware | >>"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 AM | Permanent 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 AM | Permanent Link |
Mark Brooks Slikware | >>"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 AM | Permanent 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 AM | Permanent Link |
Mark Brooks Slikware | >>"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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 PM | Permanent Link |
Mark Brooks Slikware | >>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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, February 11, 2025 at 11:58 AM | Privacy Policy![]() © 2025 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |