Hello Esteban, On 18 Mar 2013, at 00:48, Esteban A. Maringolo <[email protected]> wrote:
> Hi, > > I'm happily mapping my objects to JSON. But in order to reduce the payload > I'm looking for a way to map my objects differently depending on whether it > is the root object of the mapping or not. > > Let's say I have two classes with the following instvars between > parenthesis: > * ClassA(id, name) > * ClassB(id, classA) > > I'm using #neoJsonMapping: to define the mappings and (NeoJsonWriter > toString: classB) to get the JSON string. > > If in the Class B mappings I reference classA (by instVar or accessor) I get > the whole ClassA instance serialized as JSON. Which is not what I want. I'd > like to have only the id of classA. > > I know I can define a custom mapping using for:customDo: , but I'd like to > know if there is another way to do that. > > And this relates to another point, that is how to define a schema for a > whole hierarchy of objects. All my objects are descendant of a common > superclass. > > There is no way I can do the following on different levels: > super neoJsonMapping: mapper. > mapper for: self do: [:mapping | mapping mapInstVars: #(foo) ] > > Because on every call it overwrites the mapping for the schema of the > current call, ending up mapping only the instVar 'foo'. > > I can work my way around this by writing more, refactoring and so on. But I > would like to know if Sven or somebody else who uses NeoJSON have some > practice patterns that would like to share with the rest of us, mere > mortals. > > Best regards! > > > Esteban. Thanks for using NeoJSON and for giving feedback. NeoJSON is actually two things: a standard JSON parser and encoder using roughly Dictionary for maps and some regular Collection for lists. The mapping layer allows for an efficient conversion of JSON directly to and from Smalltalk objects, bypassing an intermediate Dictionary/Array representation. There is however a problem: the basic JSON spec is deliberately limited and vague about certain aspects, and even non existing for other aspects such as typing, references or cycles. There exist numerous ways to add those to JSON, some very complicated ones, often coming from statically typed languages. Many of those kill the human readability/writability of JSON. The problem of how to encode a type or class in JSON across languages is actually unsolved. That is why I decided not to implement any support for that. With NeoJSON mappings your are supposed to know upfront what types your JSON represents/contains. This works fine in many cases but certainly not all. Circular references will always be a problem. Structure sharing is extra complicated, it requires both reader and writer support with an objet table. STON, which is very similar but incompatible with JSON, has support for all these aspects, right out of the box, no mapping required. If you do not have to interact with foreign systems, that is an option. Support for one of the many semantics built on top of JSON will have to be built by hand. Hopefully the mapping layer can help there. But like you said: you'll have to play with custom mappings. The mapping system is pretty simple to understand. I know this is much help, but I hope it makes things a bit clearer. Regards, Sven PS: I also have to confess that although I am using NeoJSON in various important projects myself, we usually stick with Dictionaries/Collections without doing any mapping. Only in very specific cases do we actually convert to specific Smalltalk objects. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
