Tim,

I hope that you're well.

I wanted to ask if you had any "internal code" that serialized and deserialized back and forth between an object pascal class and some JSON. If you do, could you share it?

If not, would you consider adding a descendant of TObject that had these capabilities. This would be incredibly powerful, particularly since EWB is such a great tool for the consumption of REST APIs. Right now I have to build my own classes and hand-code the LoadFromJSON method and the AsJSON property.

Cheers and keep it up.

Mark

Mark,

<< I hope that you're well. >>

Doing pretty good, thanks.

<< I wanted to ask if you had any "internal code" that serialized and
deserialized back and forth between an object pascal class and some JSON. If
you do, could you share it? >>

I assume that you're referring to both the server-side modules and the EWB
objects on the client-side ?  The quick answer is no, but I agree that this
would be a neat feature that would make things a lot easier on everyone.
I'll see what I can do.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

<<I assume that you're referring to both the server-side modules and the EWB
objects on the client-side ?  The quick answer is no, but I agree that this
would be a neat feature that would make things a lot easier on everyone.
I'll see what I can do.>>

Appreciated Tim. From my perspective it's the client-side that's key for consumption of REST APIs. Let me know if you need any additional info. I have a reasonable feel for mechanisms employed by other solutions.

Cheers
Mark

Mark Brooks wrote:
<<Appreciated Tim. From my perspective it's the client-side that's key for consumption of REST APIs. Let me know if you need any additional info. I have a reasonable feel for mechanisms employed by other solutions. >>

I ended up writing my own basic class using TParser (similar to how framework does it webdata) and it works quite well though it's not that generic (like eval would be for example).

Raul

Tim,

> I assume that you're referring to both the server-side modules and the EWB
> objects on the client-side ?  The quick answer is no, but I agree that this
> would be a neat feature that would make things a lot easier on everyone.
> I'll see what I can do.

I think it is an essential feature if you want to write nowadays web clients.

As the client side lives in the JavaScript world JSON as a native datatype should be at high priority to interact with the rest of the universe.
Manual parsing of JSON data seems a little bit like reinventing the wheel. Working with complex web services in this way will be not acceptable.

A first step could be to implement a new datatype (ANY, VARIANT, JSON...) that represents native JavaScript data.
With simple functions like
  function stringify(aJsonData): string
  function unstringify(aString): JSON
to deal with JSON strings.

The implementation of a json object mapping to Pascal datatypes will be much more complex as you will need concepts like e.g. nullable types and some kind of reflection.

greetings
Günther

Gunther,

<< As the client side lives in the JavaScript world JSON as a native
datatype should be at high priority to interact with the rest of the
universe. >>

Yes, I'm aware of that JavaScript is pretty big on the browser side.  As
for JSON as a datatype, I'm not sure if that will work at all.  I'm still
working through the whole design in my head, though.

<< Manual parsing of JSON data seems a little bit like reinventing the
wheel. >>

Actually, parsing is normally recommended since what is coming over the wire
can be intentionally or unintentionally screwed up and subject to runtime JS
errors that are very difficult to track down without parsing.  It is not
normally recommended that one simply eval() the strings coming over.

<< The implementation of a json object mapping to Pascal datatypes will be
much more complex as you will need concepts like e.g. nullable types and
some kind of reflection. >>

Yes, I am also aware of this, which is why it isn't done yet.  If it was
a matter of simply eval'ing strings and returning the result, that could be
done very easily.  A Null value in an incoming JSON "object" is equivalent
to a "missing property/member variable" in Object Pascal, which is not good.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

I need to way to GET JSON packets from an Azure MVC4 Web API service as well.

I can do a lot on the server, and package it anyway I need, but I need a way to parse it on the client-side and put it into the dataset so that the UI components can work. I also need a way to throw the updated/inserted dataset in the other direction.

Perhaps some reference Web API methods in a demo Visual Studio Project will do. This project should also be able to serve up the generated html/js/etc so the same origin rules are respected.

<<I need to way to GET JSON packets from an Azure MVC4 Web API service as well.

I can do a lot on the server, and package it anyway I need, but I need a way to parse it on the client-side and put it into the dataset so that the UI components can work. I also need a way to throw the updated/inserted dataset in the other direction.

Perhaps some reference Web API methods in a demo Visual Studio Project will do. This project should also be able to serve up the generated html/js/etc so the same origin rules are respected.>>

Hi,

Not sure exactly of your requirements, but if you just want to parse up some JSON returned from the server then the included TParser does a pretty good job. I use this method to serialise / deserialise my objects, although it is of course specific to each. I can drop some sample code if that would help. Really I'd like to treat the JSON like a variant, but we can't do that right now.

Mark

.....

It would suffice if I could have a GetJSON for updated/inserted/deleted/all on datasets. Then I could do a manual server post to Web API on Azure which automatically deserializes JSON to C# POCO's and that spells productivity. So Tim, just give us these 3 GetJSON calls that always have the same format - and of course be able to handle Dataset states manually also. Don't know yet if that's possible.

I dont think that I would like to parse on the client. If we cannot have the the GetJSON calls above, I think I'll experiment with making a series of Web API's that can parse the Transactions on the server. I just don't think I have time to this right now, and for my azure dashboard project. Then I probably have to do this in ASP.NET Forms

<< It would suffice if I could have a GetJSON for
updated/inserted/deleted/all on datasets. Then I could do a manual server
post to Web API on Azure which automatically deserializes JSON to C# POCO's
and that spells productivity. So Tim, just give us these 3 GetJSON calls
that always have the same format - and of course be able to handle Dataset
states manually also. Don't know yet if that's possible. >>

The issue is not with exposing the GetJSON calls, it's all of the other
housekeeping that deals with terminating the transaction, etc. that also
needs to be modified accordingly when the transaction isn't actually
committed by EWB's framework.  It's going to require some re-working to make
it all work.

Did you review the JSON reference to see if the transactional data coming
across would be sufficient for your needs in its *current* form ?

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb1&topic=JSON_Reference

Tim Young
Elevate Software
www.elevatesoft.com