2015-03-16 17:21 GMT+01:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:
> 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.
>
But do you think that in practice people do need such customization? I
think they only need pretty printing for debuging purposes, where a
readable std format is fine.
> 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
>>>
>>>
>>
>