2015-03-16 17:35 GMT+01:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
>
>
> 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.
>
+1, this is a shortcut for a common use case IMO, but doesnt prevent
vendor to use properties to do much more
>>
>> 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
>>>>
>>>
>>
>