johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Sandtner <reinhard.sandt...@gmail.com>
Subject Re: JSON-with-types
Date Tue, 17 Nov 2015 14:55:25 GMT
no not yet but this is also something we need…

its linked to https://issues.apache.org/jira/browse/JOHNZON-59 <https://issues.apache.org/jira/browse/JOHNZON-59>

lg
reini


> Am 17.11.2015 um 15:29 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
> 
> Hi Reinhard,
> 
> Is it linked to this topic?
> 
> If not no "plan" but nothing preventing it AFAIK.
> Le 17 nov. 2015 05:24, "Reinhard Sandtner" <reinhard.sandtner@gmail.com> a
> écrit :
> 
>> hey folks,
>> 
>> are there any plans to do a release soon?
>> we need the new version for production and have a release next week..
>> 
>> lg
>> reini
>> 
>> 2015-11-10 6:02 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com>:
>> 
>>> nothing standard if it is the question, several libs - not johnzon for
>> now
>>> - serializes the type in the payload (how ugly is that?!!).
>>> 
>>> From my experience here are the few things I did/tested:
>>> 
>>> - i know the type when I deserialize: I enforce it (you know you it is
>>> Partner and not Person)
>>> - type can be guessed by checking an (or multiple) attribute (partner
>> has a
>>> partnerNumber for instance): instance is created after this condition -
>> we
>>> can enhance johnzon to support a "InstanceFactory" or a
>>> "ClassMappingFactory" for such a case but we would need a kind of
>> @SeeAlso
>>> to browse the hierarchy during model creation
>>> - as other libs serialize the type (I used enums to not have java types
>>> hardcoded but it is pretty close but less java-ish) when none of previous
>>> solution worked...pretty hate it since it makes the model very technical
>>> and no more really data oriented
>>> - never used but..: we could have a companion tree, a bit like additional
>>> fields when we speak about java proxying, holding such information making
>>> previous option less invasive in main model. Only issue is the solution
>> is
>>> different if we serialize arrays where we would enrich each item or
>> object
>>> where we just enrich root object
>>> 
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>> 
>>> 2015-11-09 20:53 GMT-08:00 Mark Struberg <struberg@yahoo.de>:
>>> 
>>>> Hi!
>>>> 
>>>> Please excuse if I’m blank on this side.
>>>> Is there something like a JSON with information about the types?
>>>> 
>>>> E.g. consider a class hierarchy
>>>> Customer extends Person extends Partner
>>>> Employee extends Person extends Partner
>>>> Organisation extends Partner
>>>> 
>>>> Now if you have a class ‚Contract‘ which has a Partner you don’t really
>>>> know whether it is of type Person, Customer, Employee or Organisation.
>>> Got
>>>> me?
>>>> 
>>>> Same is if you have Lists, Sets or Maps…
>>>> 
>>>> My childish idea was to store this additional type information as
>> comment
>>>> in JSON. This can be read back by Johnzon.
>>>> 
>>>> How useful would that be?
>>>> Is there anything in this regard in other JSON libs?
>>>> 
>>>> LieGrue,
>>>> strub
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message