Best Practice to populate TTMSFNCListBox with result of XData Servicerequest TList<TWhatever>

Hi guys,
I am diving a little deeper into your awesome Web Framework,
In several situations I want to use some parts of service request responses which I call from a xdata backend via TXDataWebClient instances.
The response text of calls that provide me lists are as such ...
{
"value": [
{
"$id": 1,
"Id": "00FCF509-633D-4F63-AA88-594EB7727EC2",
"Name": "enter your new storyname here",
"Description": "enter your new storytext here",
"Url": "enter your new storyurl here",
"Status": "Created",
"Doe": "2021-10-09T02:26:09.096",
"Sessionid@xdata.proxy": "Story('00FCF509-633D-4F63-AA88-594EB7727EC2')/Sessionid"
},
{
"$id": 2,
"Id": "AAC2E08D-8925-46E2-ACB7-4962703BF7BB",
"Name": "enter your new storyname here 2",
"Description": "enter your new storytext here 2",
"Url": "enter your new storyurl here 2",
"Status": "Created",
"Doe": "2021-10-09T02:26:14.956",
"Sessionid@xdata.proxy": "Story('AAC2E08D-8925-46E2-ACB7-4962703BF7BB')/Sessionid"
},
[...stuff deleted...]
]
}

I came up with the following to update my listbox, but doubt that it is the best way to do so ... I would rather also use an array of TJSONObjects - as also Holger Flick suggests in his book "TMS Web Core" in chapter 4.13.2 ... the problem is that I cannot figure out any way to get the JSONObjects array deserialized.

Thid is the code that works based on TJSArray ... question is, would there be a way to achieve this with an TJSONArray?

procedure TFormPokerPlay.XGetSessionStoriesLoad(Response: TXDataClientResponse);
var
I: Integer;
it: TTMSFNCListBoxItem;
JA: TJSObjectDynArray;
begin
JA := TJSObjectDynArray(Response.ResultAsObject['value']);
ListBoxStories.BeginUpdate;
ListBoxStories.Items.Clear;
for I := 0 to high(JA) - 1 do
begin
it := ListBoxStories.Items.Add;
it.Text := string(JA[I]['Name']);
it.DBKey := string(JA[I]['Id']);
end;
ListBoxStories.EndUpdate;
ListBoxStories.ItemIndex := 0;
UpdateStoryDetailUI(string(JA[0]['Name']), string(JA[0]['Url']), string(JA[0]['Description']));
UpdateStoryInfo;
end;

BTW, I am totally blasted away by my first deeper experiences with TMS Web Core, it is awesome. Thank you so much for this.

Any concrete reason why you want to use TJSONObject? Using the TJS* classes is the best way in my opinion, since they are "native" ones. The TJSON* classes are just there for Delphi compatibility, but they are a heavier wrapper around the underlying JavaScript objects. Your code is fine.

Is there a write-up somewhere that gives some concrete examples and a comparison of using the TJS* classes vs. the TJSON classes? I know the TJSON* variants do a crazy amount of extra work it seems, for little benefit, but it is precisely because they are the same as the Delphi variant that I find myself using them. I very briefly tried tinkering with the TJS* variants but didn't make any progress at all.

I'm not aware of such document comparing those in details. Basically it's what you say, TJSON* are there to provide Delphi syntax compatibility. Unless you really need to share code between Web Core application and regular Delphi application, the only benefit in using them is just because you might be familiar with it. But again, as you said, it comes at an extra cost.

Basically the TJS* is used by casting variables to their types. You can simply directly cast anything, since everything is JavaScript under the hood. For example, if you know a variable is a JavaScript object under the hood, you can simply cast it to TJSObject and start accessing its properties directly. I'd be happy to help you in a specific situation you might be facing.

I don't have a specific situation I'm facing.... because I just use the TJSON* classes. But I've seen it mentioned a few times now that it is preferable to use the TJS* classes. I understand the "why" just not the "how". A good candidate for my little list of tips for Delphi programmers new to Web Core, as JSON is obviously a huge part of using JS effectively. Dr. Flick's book had some solid examples in it but that's an area where a more thorough exploration would be super beneficial I think. I'll have to think about what that would look like. I realize the objections are always along the lines of it being impossible to write something generic enough and still be useful to the zillion different ways that people use JSON. But surely there's a way to writeup somehting more than what we have now.

1 Like