In Gson, we have a GsonBuilder.setPrettyPrinting() setting. This mostly
works but is inflexible.
However, I think a better approach is to allow a formatter object that
allows configuration per any formatting styles. You can use the formatting
styles of an IDE such as Eclipse. Then provide an Enum with some commonly
used styles for ease of use. In Gson we use this pattern for field name
mapping configuration.
Inder
On Mon, Mar 16, 2015 at 6:32 AM, Eugen Cepoi <cepoi.eugen_at_gmail.com> wrote:
>
>
> 2015-03-16 14:24 GMT+01:00 Martin Grebac <martin.grebac_at_oracle.com>:
>
>> On 16.03.15 14:09, Eugen Cepoi wrote:
>>
>>> 2015-03-16 13:54 GMT+01:00 Martin Grebac <martin.grebac_at_oracle.com
>>> <mailto:martin.grebac_at_oracle.com>>:
>>>
>>> On 12.03.15 17:36, Eugen Cepoi wrote:
>>>
>>> Hey Martins,
>>>
>>> Quick feedback on the API.
>>>
>>> I don't like much the to/from in JsonbConfig. At least for the
>>> formatting it is obvious that it exists only during
>>> serialization.
>>>
>>> What would be the suggestion?
>>>
>>>
>>> When the config is valable only for ser or deser, just use the config
>>> name (+ maybe some prefix use/with/etc). And about configs that exist for
>>> both ser and deser I am not sure. I hesitate between:
>>> - don't allow to configure a same instance with different ser and deser
>>> configs => we can then use the same naming strategy as previously
>>>
>> There are implementations which allow this to be configured separately,
>> but I still find very little benefit in it. This seems like a rare case and
>> you can achieve the same with 2 differently configured Jsonb instances. My
>> vote would be to not allow this, in my local changes I'd change this to
>> withEncoding, withFormating.
>>
>
> Cool :) Instead of formating something like
> xxxIndentation/xxxPrettyPrinting or similar maybe? In jsonp the term used
> is prettyPrinting
>
>
>>
>> - provide the ability to configure separately ser/de => prefix with
>>> serializationEncoding/deserializationEncoding
>>>
>> If, then I'd prefer something shorter, like readEncoding and
>> writeEncoding.
>>
>> - keep as it is
>>>
>>> toJson/fromJson look a bit strange as they are "active terms", working
>>> well when doing the action in Jsonb but less for configuration, that's
>>> probably why I don't like it much. What do others think?
>>>
>> Agree with the active term, this needs correction.
>>
>> MartiNG
>>
>>
>>
>>> Not sure ConfigException is needed, I mean sure in some case
>>> we could throw this exception, but in practice maybe no one
>>> will. Also in multiple places I see IllegalArgumentEx, and it
>>> makes sense, we could same way use other existing exceptions -
>>> instead of ConfigEx.
>>> getProperty could return an Optional and throw an exception
>>> only if the arg is null.
>>>
>>> Both sound good to me, will apply unless hear otherwise.
>>>
>>> We could also add an option to skip null during serialization
>>> in the config.
>>>
>>> We'll handle this separately, but I agree.
>>>
>>> In JsonbBuilder, the newBuilder related to JsonbProvider are a
>>> bit redundant as we also have similar method inside the
>>> provider. But from another side, it provides a single entry
>>> point - this is good. This makes the API more easy to use.
>>>
>>> I didn't read the javadoc carefully.
>>>
>>> About the examples... well they are just examples :)
>>>
>>> That's why I'd like to focus you more on the spec pdf itself at
>>> this point ;)
>>> MartiNG
>>>
>>>
>>> Eugen
>>>
>>>
>>> 2015-03-12 16:46 GMT+01:00 Martin Grebac
>>> <martin.grebac_at_oracle.com <mailto:martin.grebac_at_oracle.com>
>>> <mailto:martin.grebac_at_oracle.com
>>>
>>> <mailto:martin.grebac_at_oracle.com>>>:
>>>
>>> Just would like to explicitly point to the spec document
>>> itself in
>>> this branch:
>>>
>>> https://java.net/projects/jsonb-spec/sources/git/
>>> content/spec/spec.pdf?rev=da7db533076856699cec49a4eebd300b9f4a7230
>>>
>>> MartiNG
>>>
>>>
>>> On 12.03.15 16:35, Martin Vojtek wrote:
>>>
>>> Hi Experts,
>>>
>>> there has been a lot of changes recently in
>>> default_mapping.
>>> This completes the second iteration of default mapping
>>> proposal.
>>>
>>> Generics and integration with JSON Processing is not
>>> part of
>>> this discussion.
>>>
>>> Please take a look and feel free to express your point
>>> of view.
>>>
>>> https://github.com/json-binding/spec/tree/default_mapping
>>>
>>> Looking forward to your feedback.
>>>
>>> MartinV
>>>
>>>
>>>
>>>
>>> -- Martin Grebac, SW Engineering Manager
>>> Oracle Czech, Prague
>>>
>>>
>>>
>> --
>> Martin Grebac, SW Engineering Manager
>> Oracle Czech, Prague
>>
>>
>