Hi Sven, all,
I'm working on a JSON-RPC client, I started using LtJsonRpcClient, but since it's based on the "legacy" JSON package I decided to try to adapt it to use NeoJSON. So I created a NeoJSONRPCClient based on LtJson... because... why not. At its core JSON-RPC is a pretty simple protocol, every response is a JSON object with a 'result' attribute holding the returned object from the RPC call, an 'error' one (nil if no error happened), and a few other ones [1]. If I convert the response using the traditional `NeoJSONReader fromString: responseObject` all the object three is converted to a Dictionary, and what I want is to be able to: 1. Determine whether there was an error in the response 2. If there was no error, convert the 'result' field to my preferred class of object instead of a Dictionary. I plan to make my classes inherit from NeoJSONObject though. All the above to avoid the use of an intermediate set of nested dictionaries (which could be in the thousands). I understand I could subclass NeoJSONReader to perform that at the character stream level, but I wanted to ask first whether there is a pattern/configuration of dealing with something like this. Best regards! [1] http://www.jsonrpc.org/specification#response_object Esteban A. Maringolo |
Esteban,
I had a quick look at the spec you mentioned. I am a bit puzzled though. Result can be anything, so how are you going to map that to specific classes (and why) ? That would require serious prior knowledge and even then, not every situation can be mapped easily to a class. You speak about subclassing NeoJSONObject, which is cool, because it is so flexible, but then why type it further ? If I were you, I would at least start the easy/lazy way. For example you could do NeoJSONObject fromString: '...' And see how far you get. If things get slow, I would look for alternatives. Sven > On 26 Jul 2017, at 02:38, Esteban A. Maringolo <[hidden email]> wrote: > > Hi Sven, all, > > I'm working on a JSON-RPC client, I started using LtJsonRpcClient, but > since it's based on the "legacy" JSON package I decided to try to > adapt it to use NeoJSON. So I created a NeoJSONRPCClient based on > LtJson... because... why not. > > At its core JSON-RPC is a pretty simple protocol, every response is a > JSON object with a 'result' attribute holding the returned object from > the RPC call, an 'error' one (nil if no error happened), and a few > other ones [1]. > > If I convert the response using the traditional `NeoJSONReader > fromString: responseObject` all the object three is converted to a > Dictionary, and what I want is to be able to: > > 1. Determine whether there was an error in the response > 2. If there was no error, convert the 'result' field to my preferred > class of object instead of a Dictionary. I plan to make my classes > inherit from NeoJSONObject though. > > All the above to avoid the use of an intermediate set of nested > dictionaries (which could be in the thousands). > I understand I could subclass NeoJSONReader to perform that at the > character stream level, but I wanted to ask first whether there is a > pattern/configuration of dealing with something like this. > > Best regards! > > [1] http://www.jsonrpc.org/specification#response_object > > Esteban A. Maringolo > |
2017-07-26 18:36 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> Esteban, > > I had a quick look at the spec you mentioned. > > I am a bit puzzled though. Result can be anything, so how are you going to map that to specific classes (and why) ? > That would require serious prior knowledge and even then, not every situation can be mapped easily to a class Since I'm going to use it in the context of RPC calls, I can know beforehand what kind of class is the result, so I want to leverage that knowledge to avoid going through an intermediate Dictionary/map to build the object. > You speak about subclassing NeoJSONObject, which is cool, because it is so flexible, but then why type it further ? > If I were you, I would at least start the easy/lazy way. > For example you could do > NeoJSONObject fromString: '...' > And see how far you get. If things get slow, I would look for alternatives. Yeap... I took your advice after making things unnecessarily complex... after the first... and second attempt. I tried to make a client too smart and early optimize for things I haven't used before, so I ended up making stuff convoluted (I'm specialist). Long story short, I almost ended up where I started, which was a fork of LtRpcJsonClient, with some minor fixes, using NeoJSON instead of the JSON package for parsing/writing and using NeoJSONObject as mapClass, named: NeoJSONRPCClient [1] I'm using it to build a particular client that uses JSON-RPC, so most of my specific needs were moved/implemented in my still unfinished client subclass, if behavior becomes abstract enough, I can push it up to the "general purpose" client. I didn't skip the build of the map object, but for my domain specific classes I pass the map to my specific instances, so each instance holds a reference to the map object used to build it. I didn't feel comfortable subclassing domain specific classes from Dictionary. Regards! Esteban A. Maringolo [1] It's available at https://github.com/eMaringolo/NeoJSONRPC but I'm still learning how to do Baselines and other stuff to work with this pet-project I'm using to learn Iceberg. So the baseline doesn't work... yet :| |
Free forum by Nabble | Edit this page |