Hi Experts,
I have pushed initial version of custom mapping api specification. Javadocs
will be improved asap.
I am looking forward to receiving your feedback.
Thanks,
MartinV
On Wed, May 13, 2015 at 6:21 PM, Martin Grebac <martin.grebac_at_oracle.com>
wrote:
> On 13.05.15 14:53, Martin Vojtek wrote:
>
> On Wed, May 13, 2015 at 1:34 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
>
>>
>>
>> 2015-05-13 8:40 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>>
>>> Hi Experts,
>>>
>>> we should get some conclusion to this discussion.
>>>
>>> I have the following notes:
>>>
>>> 1. Nillable, JsonbProperty, JsonbTransient
>>>
>>> I don't see any problem adding nillable attribute to JsonbProperty
>>> annotation. The situation with JsonbTransient is different, because
>>> transient field is effectively not a JsonbProperty. I think JsonbTransient
>>> should stay as is.
>>>
>>>
>> Adding target Property to JsonbProperty makes sense.
>>>
>>> 2. Property Naming
>>>
>>
>>> I see concept of Mappers equivalent to JsonbAdapter (analogy to
>>> XmlAdapter). It means that JsonbAdapter should see the context to be able
>>> to do complex mapping between type and JSON fragment.
>>>
>>
>> What is the context to you? From memory there is no context in
>> XmlAdapter. Also I think it could make sense to allow users to register
>> Adapters directly to JsonB (using the builder or config) vs only via
>> annotations.
>>
>
> Right now I don't know exactly what information JsonbAdapter needs, but
> the idea behind context is that JsonbAdapter should be able to override as
> much as possible behavior of default mapping. One option is to give access
> to JsonbConfig. It allows to change behavior when some property is set. The
> other option is to have access to information what has already been
> processed. For example if there is dependency between objects in JSON.
> Another interesting option is possibility to skip some part of json, or to
> change some behavior during processing of the JSON. But maybe there should
> be no context and to keep the concept of JsonbAdapter simple in version 1.0.
>
>
>>
>>> Composition of Mappings looks like an advanced feature and maybe it
>>> should be postponed to future spec version.
>>>
>>
>> By composition of mappings do you think of allowing users to provide an
>> Adapter/Mapper for some type that uses another registered adapters/mappers?
>>
>> For example I provide an PersonsAdapter<List<Person>> but inside I
>> don't want to deal with the mapping of each entry and want to delegate to
>> the default adapter of person.
>>
>>
>>> WDYT?
>>>
>> IMO we should keep it simple, unless there's obvious reason to not
> do so. I'd like to see clearer need for the context and more complex
> usecases here.
>
> 3. Property Order
>>>
>>> Case insensitive mapping is special, because it is not 1:1 mapping. To
>>> make PropertyOrderStrategy simple, it should support only 1:1 mapping. In
>>> that case PropertyOrderPolicy should not implement PropertyOrderStrategy. I
>>> am not sure if there is a need to introduce Accessor class. In this case
>>> simple String -> String mapping (accessor name -> JSON key) should work.
>>> Implementations could provide some internal mechanism to call this function
>>> only once per property.
>>>
>>
>> I guess you are talking about naming and mean PropertyNamingStrategy
>> and PropertyNamingPolicy.
>>
>> You are right, I was thining about different things at once and at
> the end I have messed it into one point ...
>
>
>> Even if I like the names "strategy" and "policy" (who doesn't, this
>> sounds pretty cool :)) I find them confusing when used together.
>> I think both mean the same thing :)
>>
>>
> I'm not that good in inventing names :) If you have better names, it is
> still possible to change that.
>
>
>> To me there are two things with some common parts:
>> - Resolve names (using Java Bean convetion/Annotations/Other)
>> - Translate the string to another string
>> (lower/upper/dashed/underscore/blabla)
>>
>>
> +1
>
>
>> The first one could deal directly with "properties" where the second
>> one takes the resolved name and translates it.
>> So here we have the choice of:
>> - Have two separate concepts. One interface PropertyNameResolver that
>> deals with properties or some abstraction. And a
>> PropertyNamingStrategy/Policy interface that takes a string and returns
>> another string (and provides the default impls as static attributes of the
>> interface).
>> - Or we consider that the name resolution is relatively fixed and
>> handled inside the spec impl, thus we expose only the naming
>> strategy/policy. Though I think this too is probably even more fixed...
>> - Or we expose only the name resolution API
>>
>> No matter the choice, I'd be for providing default impls for all those
>> inside the spec. There aren't many ways to implement a name resolution from
>> java bean or annotations, neither to translate camel case to underscore...
>>
>
> Agree with default impls + two separate concepts.
>
> My first comment applies here, too. If we're thinking the most of the need
> is going to be covered by the spec implementation, then is there really a
> need for the flexibility? What are the usecases which this would be
> covering?
>
> MartiNG
>
>