Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 13 total
Thread JSON direct?
Thu, Jul 4 2013 11:27 AMPermanent Link

Matthew Jones

In fiddling with the JSON generated by Delphi XE, which appears to not have the
string values escaped to hide double quotes (poor!), I was talking to my friend who
does javascript and he asked why I'm not just accessing the JSON direct. Apparently
he would normally just read something like:
{"id":"2","name":"Test1","lastuse":"04/07/2013 13:52:46"}

as MyJSON.id or MyJSON.name, and not have to parse the string or load it into a
"DOM" or anything. If nested, then it might be MyJSON.Detail.User or some such.

Is this capability available to me in EWB? If not, could it be?

/Matthew Jones/
Thu, Jul 4 2013 12:26 PMPermanent Link

Raul

Team Elevate Team Elevate


Not at this time AFAIK and I don't see how to accomplish this easily in EWB.

Javascript objects are internally defined as key/value pairs and are
dynamic so you can access as you mentioned. There is parsing (eval)
going on still though so it's not magic.

I dont' see how this would easily map into object pascal though in EWB
including type checking etc  - which is the point of using EWB in the
first place.
Using datasets is a good generic abstraction thought and provides real
easy data access already or one could write own wrappers (DOM like).

Raul

On 7/4/2013 11:27 AM, (Matthew Jones) wrote:
> In fiddling with the JSON generated by Delphi XE, which appears to not have the
> string values escaped to hide double quotes (poor!), I was talking to my friend who
> does javascript and he asked why I'm not just accessing the JSON direct. Apparently
> he would normally just read something like:
> {"id":"2","name":"Test1","lastuse":"04/07/2013 13:52:46"}
>
> as MyJSON.id or MyJSON.name, and not have to parse the string or load it into a
> "DOM" or anything. If nested, then it might be MyJSON.Detail.User or some such.
>
> Is this capability available to me in EWB? If not, could it be?
>
> /Matthew Jones/
>
Thu, Jul 4 2013 3:04 PMPermanent Link

Christian Kaufmann

> Is this capability available to me in EWB? If not, could it be?

I'm looking for the same. Some weeks ago I suggested this:

* TJson as wrapper arround JSON object / array with some kind of
compiler magic:

type
 TJson = class
   constructor Create(AText: String);
   property AsInteger[AName: String]: Integer read write;
   property AsString[AName: String]: String read write;
   property AsDateTime[AName: String]: DateTime read write;
   property AsObject[AName: String]: TJson read write;
   property AsArray[AIndex: Integer]: TJson read write;
   property Text read write;
 end;

Usage in EWB:

   v := TJson.Create('{ "title" : "Hello World!" }');
   ShowMessage(v.AsString['title']);


should compile to:

   var v = JSON.parse('{ "title" : "Hello World!" }');
   ShowMessage(v.title);


Right now I do a lot with a wrapper around a TStringList with the
As... properties. But complex structures are not so easy.

I really would like to see something for JSON.

cu Christian
Thu, Jul 4 2013 3:09 PMPermanent Link

Raul

Team Elevate Team Elevate

On 7/4/2013 3:04 PM, Christian Kaufmann wrote:
> Usage in EWB:
>      v := TJson.Create('{ "title" : "Hello World!" }');
>      ShowMessage(v.AsString['title']);
>
>
> should compile to:
>
>      var v = JSON.parse('{ "title" : "Hello World!" }');
>      ShowMessage(v.title);
>
>

I see the problem in the dymaic nature of this and mapping it to OP -
assuming JSON data is received from outside (meaning unknown at compile
time) how would the compiler know the v.title is a legit call ?

Raul
Fri, Jul 5 2013 2:18 AMPermanent Link

Christian Kaufmann

>I see the problem in the dymaic nature of this and mapping it to OP -
>assuming JSON data is received from outside (meaning unknown at compile
>time) how would the compiler know the v.title is a legit call ?

You already have a similar situation with dataset columns. JSON is a
very compact and simple form to represent structured data. And
browsers are optimized to work with it.

Also for debugging it's much easier to read than e.g. XML.

The only thing I never understood is, why they didn't define a
DateTime type. Now you have the situation, that everybody uses it's
own.

But in the EWB world, DateTime would be milliseconds since 1.1.1970
and I think, this is a good solution.

So look at it again and join the club of people, who vote for this
kind of JSON support in EWB in a future release Smile

cu Christian
Fri, Jul 5 2013 3:04 AMPermanent Link

Mark Brooks

Slikware

Avatar

>>So look at it again and join the club of people, who vote for this
>>kind of JSON support in EWB in a future release Smile

Totally agreed. A new Variant type could work, without breaking the OP.
Fri, Jul 5 2013 4:33 AMPermanent Link

Matthew Jones

I have no idea how it would work, but I'd be happy with a much simpler mechanism.
How about you just take a string and access it like this:

var
 MySource : String;
 MyJSON : TJSON;
begin
 MySource := GetSomeJSONFromServer;
 MyJSON := TJSON.Create(MySource);
 
 MyInteger := MyJSON.GetInteger('mydata.myinteger');
 MyString := MyJSON.GetString('mydata.mystring');
 MyBoolean := MyJSON.GetBoolean('mydata.myboolean');
end;
// note full "boolean" name not "bool" which annoys me! 8-)

So this would take a string to read the content of the JSON, so nothing much clever
by the compiler for variants, but it could quite simply translate it to the
javascript as:
 MyInteget := MyJSON.mydata.myinteger; // or whatever it should be

Obviously if it isn't there, it might do an exception - whatever javascript would
do.

This seems a fair way to do it "native" while making it viable for EWB to do the
business for us. Thoughts?
 
/Matthew Jones/
Fri, Jul 5 2013 7:14 AMPermanent Link

Mark Brooks

Slikware

Avatar

>>I have no idea how it would work, but I'd be happy with a much simpler mechanism.
>>This seems a fair way to do it "native" while making it viable for EWB to do the
>>business for us. Thoughts?
 
I think this approach would struggle with any more "serious" JSON, such as arrays (which are really common). Additionally, the nature of JSON is that "missing" bits should not be considered missing but rather just not set. JSON and JavaScript are very unstructured so the challenge is for EWB to match this.

You really need something a bit like this:

var
 V: variant;

 V.Parse({"someData": [{"key": "value"}, {"key": "value"}]});

to access like this:

 V.someData[0].key

IMHO
Fri, Jul 5 2013 9:00 AMPermanent Link

Matthew Jones

My suggestion handles that nicely - just put in the string what you would put in
javascript. That's the point, it is output exactly as-is to the javascript code.

MyValue := MyJSON.GetString('someData[0].key');

/Matthew Jones/
Fri, Jul 5 2013 10:58 AMPermanent Link

Christian Kaufmann

>My suggestion handles that nicely - just put in the string what you would put in
>javascript. That's the point, it is output exactly as-is to the javascript code.
>
>MyValue := MyJSON.GetString('someData[0].key');

First of all I prefere properties like AsString[], etc.

To have acces to hierarchical structure would be important. And also
the possibility to get an element as JSON object.
For example: The server sends a list of items (JSON array) and then I
have a routine, that handles one item. Or even some kind of business
object with logic and the data is a JSON object from this array.

cu Christian
Page 1 of 2Next Page »
Jump to Page:  1 2
Image