2015-04-07 20:48 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
>
> Le 7 avr. 2015 20:27, "Eugen Cepoi" <cepoi.eugen_at_gmail.com> a écrit :
> >
> >
> >
> > 2015-04-07 20:05 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> >>
> >> Hi
> >>
> >> This topic is very interesting but I think we should just align by
> default on javabeans and allow a configuration (+api) for other usages
> which are widely spread over applications.
> >>
> >> So I propose:
> >>
> >> - default: getter/setter only, no field check at all,
> >
> >
> > I think it is more friendly to have public methods and fields (for
> example if one has a immutable pojo with all fields public).
> >
>
> Fair enough
>
> >>
> >> support of addX for collections and maybe getter in write mode as in
> jaxb.
> >
> > I am hesitating for addX not sure I like it...
> > What is getter in write mode?
> >
>
> getMyCollection().add(xx) instead of just using setMyCollection(col)
>
Ok I understand better what you mean. I can see only 2 use cases for this:
when adding stuff to the list the pojo is doing something (increment a
counter for example) or updating an existing instance (kind of merge).
I don't think we provide any merge solution now so point 2 is excluded and
1 is still valid even if I don't like it :)
Eugen
> >>
> >> I like it cause it really exposes an API and not internals.
> >> - a shortcut in config api to use fields (either only or in cumulative
> mode) - this is too common to not be handled and the default in most ee API
> (JPA for instance)
> >> - add in API an abstraction for it for advanced mode and evolutions
> (Accessor, and AccessorFinder - I am not happy of the naming but was to
> share the idea). It would allow to add processor on the accessors to filter
> or remap them pretty easily. It makes trivial remapping, version and
> blacklist handling for instance.
> >>
> >> Le 7 avr. 2015 19:57, "Martin Vojtek" <voytoo_at_gmail.com> a écrit :
> >>>
> >>> It would be great to hear opinions from others on this topic.
> >>>
> >>> Current JSON-B proposal is to by default ser/deser only fields where
> field is present. Specifically, if there is field and set/get method,
> set/get method is used. If there is not set/get method, field is used. If
> there is no field, but get/set method, it is not used (JSON-B will not
> consider this property). This behavior should be customizable. Maybe it is
> too restrictive and if there is getter and no field, getter should be used.
> What if there are methods not intended to be getters? What if there is
> method isValue and getValue?
> >>>
> >>> For properties that are being renamed ... I can imagine use of
> annotations.
> >>>
> >>> MartinV
> >>>
> >>> On Tue, Apr 7, 2015 at 4:27 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
> >>>>
> >>>> Oh, yes, in fact this is something I did on purpose for a couple of
> reasons. One of them is to allow people to ser types based on some "parent
> type". For example if a class implements several interfaces and we want to
> serialize using only one "aspect" of the instance.
> >>>> The other reasons are more opinionated :)
> >>>>
> >>>> So in JSONB how do you see things, would we ser only properties that
> have a field+get+set? I would prefer not or at least provide a config for
> it.
> >>>>
> >>>> However something that is a bit similar, from what I've seen, merging
> annotations from field/get/set is the good way to go. Initially I thought
> it would be better to decouple ser from deser aspect. But in the end I
> found that from an usage point of view, people expect that annotations that
> have been put on the field are being used also for get and set. The issue
> with this is how would one handle properties that are being renamed? I am
> quite interested in others opinion on this as I couldn't make my mind yet :)
> >>>>
> >>>> Thanks!
> >>>> Eugen
> >>>>
> >>>> 2015-04-07 16:00 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> >>>>>
> >>>>> The example I was thinking about is following:
> >>>>>
> >>>>> interface FunctionalInterface<T> {
> >>>>> public T getValue();
> >>>>> }
> >>>>>
> >>>>> Genson:
> >>>>>
> >>>>> public void test() {
> >>>>>
> >>>>> FunctionalInterface<String> myFunction = () -> {return
> "value1";};
> >>>>>
> >>>>> assertEquals("{\"value\":\"value1\"}",
> genson.serialize(myFunction));
> >>>>>
> >>>>> }
> >>>>>
> >>>>> Proposed JSON-B:
> >>>>>
> >>>>> FunctionalInterface<String> myFunction = () -> {return "value1";};
> >>>>>
> >>>>> assertEquals("{}", jsonb.toJson(myFunction));
> >>>>>
> >>>>>
> >>>>> The difference is in handling getters when there is no field.
> >>>>>
> >>>>> MartinV
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Apr 6, 2015 at 11:22 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2015-04-06 22:47 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> response inlined.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Martin
> >>>>>>>
> >>>>>>> On Sun, Apr 5, 2015 at 5:57 PM, Oleg Tsal-Tsalko <
> oleg.tsalko_at_gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi guys,
> >>>>>>>>
> >>>>>>>> Feedback on generic mapping serialization examples:
> >>>>>>>> 1) Why there are no examples of actual usage of proposed
> Jsonb#toJson(Object, Type) method?
> >>>>>>>> I assume these examples should justify usage of this advanced
> method in those special/tricky cases where Jsonb#toJson(Object) method is
> not enough.
> >>>>>>>
> >>>>>>>
> >>>>>>> Will add example:
> >>>>>>>
> >>>>>>> List<java.util.Optional<String>> expected =
> Arrays.asList(Optional.empty(), Optional.ofNullable("first"),
> Optional.of("second"));
> >>>>>>>
> >>>>>>> String json = toJson(expected,
> DefaultMappingGenerics.class.getField("listOfOptionalStringField").getGenericType());
> >>>>>>> assertEquals("[null,\"first\",\"second\"]",json);
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 2) Probably it was missed by me but are we going to support
> serialization of anonymous interfaces/classes implementations at all?
> >>>>>>>> As an example:
> >>>>>>>> myFunction = new FunctionalInterface<String>() {
> >>>>>>>>>
> >>>>>>>>> private String value = "initValue";
> >>>>>>>>>
> >>>>>>>>> @Override public String getValue() {
> >>>>>>>>>>
> >>>>>>>>>> return value;
> >>>>>>>>>
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> public void setValue(String value) {
> >>>>>>>>>>
> >>>>>>>>>> this.value = value;
> >>>>>>>>>
> >>>>>>>>> }
> >>>>>>>>
> >>>>>>>> };
> >>>>>>>> assertEquals("{\"value\":\"initValue\"}",
> jsonb.toJson(myFunction));
> >>>>>>>> It doesn't look like valid scenarios to support.
> >>>>>>>> AFAIK, Gson lib doesn't support this...
> >>>>>>>
> >>>>>>>
> >>>>>>> Don't see reason why it is not valid scenario.
> >>>>>>>
> >>>>>>> Genson supports it (with different result in some cases as
> proposed JSON-B) :)
> >>>>>>
> >>>>>>
> >>>>>> Heh looks like you had an in depth look at it :) In what situation
> did it produce different or undexpected results?
> >>>>>>
> >>>>>> I added it because the effort to support it was not so important
> and this can be of some use. But this looks like a rare use case so I am
> not feeling strongly for or against it. I don't feel so concerned by the
> examples as IMO they are just examples and its OK if they don't cover all
> the API (after all it is not the spec).
> >>>>>>
> >>>>>> About supporting deser missing properties I 100% agree with the
> remark but think it should be expressed as a config option that would make
> things clear that impl. have to support this feature (and don't really care
> about the example).
> >>>>>>
> >>>>>> I wonder if providing those examples doesn't make things more
> confusing about what is the contract that impls should respect.
> >>>>>>
> >>>>>> Eugen
> >>>>>>
> >>>>>>>
> >>>>>>> It would be helpful to hear some opinions from others on this
> topic.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 3) Expected result in bounded example doesn't look right:
> >>>>>>>>>
> >>>>>>>>>
> assertEquals("{\"boundedSet\":[3],\"superList\":[{\"radius\":2.5}]}",
> jsonb.toJson(boundedGenericClass));
> >>>>>>>>
> >>>>>>>> I believe it should be:
> >>>>>>>>>
> >>>>>>>>> {"boundedSet":[3],"superList":[{"area":0.0,"radius":2.5}]}
> >>>>>>>>>
> >>>>>>>
> >>>>>>> Will fix asap.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Have a great Easter!
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>>> Oleg
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>