![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 10 of 13 total |
![]() |
Thu, Jul 4 2013 11:27 AM | Permanent 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 PM | Permanent Link |
Raul ![]() | 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 PM | Permanent 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 PM | Permanent Link |
Raul ![]() | 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 AM | Permanent 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 ![]() cu Christian |
Fri, Jul 5 2013 3:04 AM | Permanent Link |
Mark Brooks Slikware | >>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 ![]() Totally agreed. A new Variant type could work, without breaking the OP. |
Fri, Jul 5 2013 4:33 AM | Permanent 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 AM | Permanent Link |
Mark Brooks Slikware | >>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 AM | Permanent 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 AM | Permanent 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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, November 29, 2023 at 09:43 PM | Privacy Policy![]() © 2023 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |