2015-04-29 21:54 GMT+02:00 Eugen Cepoi <cepoi.eugen_at_gmail.com>:
> I think JsonbProperty should accept Parameter as target. This would allow to
> use it on constructor parameters (and factory methods).
>
> About all the naming policy, I agre with Romain. We should have an interface
> that defines the naming strategy api (convert from one string to another or
> from a Method/Field/Param to a String) and provide impls as an enum for the
> actual policies.
>
> I don't think NullSerPolicy is useful. IMO it should be an option at the
> builder or jsonbconfig level and provide some way to the user to implement a
> custom strategy (so a kind of Adapter/Converter/Whatever where he has enough
> information to decide how he should ser/de).
>
> In PropertyOrderStrategy we give to the user control to a mutable structure
> the array of strings, perhaps we should provide just a collection/iterable
> or document that the user can or not modify the original structure. Also I
> am not sure there is enough information to sort things properly. For example
> the user doesn't know from which class the property comes (ex: A extends B,
> does it come from A or B).
>
That is why a mapping API (class -> Map<String /* json key */,
Accessor> map(Class)) is nice but I agree it is less user friendly
since it mixed 3 concerns (naming, merging and accessibility). We can
of course provide helpers but not sure it is a good idea for a v1.0 of
the API.
> About Nillable, I don't care :) But following the same logic, what about
> JsonTransient?
>
+1 for transient (as annotation or field of property one depending
what we decide here) is important to fully ignore a field.
> For JsonPointer, Path & cie, jsonp will come with an impl of jsonpointer
> over the DOM model. This could make things easier... Also what's the
> advantage of @JsonbProperty({"foo", "bar"}) vs @JsonbProperty("/foo/bar") ?
> The sad thing is that I think we can't express something like:
>
or even foo.bar? just the fact you can use all "single string" naming
as key and not path:
{ // Map
"/home/rmannibucau/Desktop": "5MB",
"/home/rmannibucau/dev": "65MB"
}
which is valid to map to:
public class MyFiles {
@JsonbProperty("/home/rmannibucau/Desktop")
private String desktop;
@JsonbProperty("/home/rmannibucau/dev")
private String dev;
}
> @JsonProperty("/person/childrens/name")
> List<String> childrenNames;
>
> where the json would be
> {
> person {
> childrens: [ {...name: foo}, {...name: bar} ]
> }
> }
>
>
> I agree with Romain about the composition part. This can be pretty neat, not
> only for naming but also for property resolution.
>
>
> 2015-04-29 21:08 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
>>
>>
>> Le 29 avr. 2015 19:18, "Martin Vojtek" <voytoo_at_gmail.com> a écrit :
>> >
>> >
>> >
>> > On Wed, Apr 29, 2015 at 6:56 PM, Romain MB <rmannibucau_at_tomitribe.com>
>> > wrote:
>> >>
>> >> 2015-04-29 18:30 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>> >> > Hi,
>> >> >
>> >> > ad 1) interface for PropertyNamingPolicy?
>> >> >
>> >> > I was experimenting with the idea of interface, but there is an open
>> >> > question how to design API to provide support also for the reverse
>> >> > mapping.
>> >> >
>> >> > For example, if I have case insensitive mapping, I need to know how
>> >> > to map
>> >> > from JSON key to field name (in efficient way). I have removed such
>> >> > an
>> >> > interface to see if there is a need for such customization (obviously
>> >> > there
>> >> > is :)).
>> >> >
>> >> > The alternative is to provide mechanism analogical to JAXBAdapter
>> >> > mechanism
>> >> > (or general mapper for given type).
>> >> >
>> >>
>> >> think we can do better than something called each time here. Why not
>> >> just a Mapper? String map(Accessor)?
>> >>
>> >
>> > this is mapping from Accessor to JSON. This works in many cases (like
>> > 1:1), but what about other cases like case insensitive special case?
>> >
>>
>> I would expect to be able to compose them in my code:
>>
>> new MyMapping(DefaultMappings.LEXICOGRAPHIC,
>> DefaultMappings.CASE_INSENSITIVE);
>>
>> The impl being just a chain in this case but could also managed an exclude
>> list to skip JPA state fields for instance - these fields are not in user
>> code so cant be ignored by static code (annotations).
>>
>> > If we agree that this is enough and the special case will be handled by
>> > JsonbAdapter, that it is ok.
>> >
>> >
>> >>
>> >> > ad 2)
>> >> >
>> >> > The difference between JsonbNillable and JsonbProperty is also in
>> >> > scope. It
>> >> > makes sense to make JsonbNillable property to be available for
>> >> > Type/Package
>> >> > target.
>> >> >
>> >>
>> >> Makes sense but i would still add it in property and keep @Nillable
>> >> for type and packages only.
>> >>
>> >
>> > Don't have strong opinion about this. What others think?
>> >
>> >
>> >>
>> >> > ad 3)
>> >> >
>> >> > Maybe it makes sense to make it more general. What about JSON
>> >> > Pointer?
>> >> >
>> >>
>> >> can make sense but should stay simple/fluent cause it is super common
>> >> (github/confluence/...). If you have some pseudo code we can discuss
>> >> around I would be more than happy to dig into it.
>> >>
>> >
>> > I was thinking about similar functionality as MOXy XPath provides.
>> >
>> > https://wiki.eclipse.org/EclipseLink/Examples/MOXy/XPath
>> >
>> > JSON-B could support reasonable subset of JSON Pointer to map field
>> > (JavaBean property) to given node.
>> >
>>
>> Let s try it. Maybe needs its own thread then.
>>
>> >>
>> >> > ad ProertyOrderStrategy with enum)
>> >> >
>> >> > no problem to introduce enum. In that case I would also add
>> >> > LEXICOGRAPHICAL,
>> >> > which is default (and slightly different than ALPHABETICAL).
>> >> >
>> >> > MartinV
>> >> >
>> >> >
>> >> > On Wed, Apr 29, 2015 at 6:09 PM, Romain MB
>> >> > <rmannibucau_at_tomitribe.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi
>> >> >>
>> >> >> @JsonbProperty is good to rename a property.
>> >> >>
>> >> >> However I don't like much PropertyNamingPolicy being an enum. How do
>> >> >> I
>> >> >> do if I want to prefix everything with "mysuperapp_"? I would use an
>> >> >> interface instead with default implementations (as constants in
>> >> >> Jsonb
>> >> >> or in a DefaultPropertyNamingPolicies enum if you want). This would
>> >> >> also be consistent with PropertyOrderStrategy (why not having an
>> >> >> enum
>> >> >> with ALPHABETICAL, REFLECTION, REVERSE...)
>> >> >>
>> >> >> I think having nillable as an attribute of @JsonProperty is maybe
>> >> >> better.
>> >> >>
>> >> >> Now the harder question. Suppose I have this json:
>> >> >>
>> >> >> {
>> >> >> "foo": {
>> >> >> "bar": "dummy"
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> Can I map foo/bar to a field directly? I'm super tempted to support
>> >> >> it. It means @JsonbProperty needs an array of string instead a
>> >> >> simple
>> >> >> String:
>> >> >>
>> >> >> public class MyBinding {
>> >> >> @JsonbProperty({ "foo", "bar" })
>> >> >> private String bar;
>> >> >> }
>> >> >>
>> >> >> Side note: of course this doesn't prevent simple renaming with the
>> >> >> same user API as today (speaking about the "look") thanks to
>> >> >> annotations properties:
>> >> >>
>> >> >> public class MyBinding {
>> >> >> @JsonbProperty("foo")
>> >> >> private Foo _foo;
>> >> >> }
>> >> >>
>> >> >> trying to summarize my feedback, here are the points I'd like to
>> >> >> discuss:
>> >> >>
>> >> >> 1) interface for PropertyNamingPolicy?
>> >> >> 2) nillable in @JsonbProperty (means value() would have an empty
>> >> >> default to keep a nice API in all cases)
>> >> >> 3) nested attribute support?
>> >> >>
>> >> >>
>> >> >> Romain Manni-Bucau
>> >> >> @rmannibucau
>> >> >> http://www.tomitribe.com
>> >> >> http://rmannibucau.wordpress.com
>> >> >> https://github.com/rmannibucau
>> >> >>
>> >> >>
>> >> >> 2015-04-29 17:36 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
>> >> >> > Hi Experts,
>> >> >> >
>> >> >> > I have pushed proposal regarding Customizing names.
>> >> >> >
>> >> >> > Short summary:
>> >> >> >
>> >> >> > introduce annotation and enum with most common naming policies.
>> >> >> >
>> >> >> > 1. use of javax.json.bind.annotation.JsonbProperty
>> >> >> > 2. using javax.json.bind.config.PropertyNamingPolicy
>> >> >> >
>> >> >> > JsonbProperty annotation is applicable to Field, getter or setter.
>> >> >> >
>> >> >> > PropertyNamingPolicy enum contains several different policies like
>> >> >> > IDENTITY,
>> >> >> > CASE_INSENSITIVE, LOWER_CASE_WITH_UNDERSCORE ...
>> >> >> >
>> >> >> > Details could be found in specification and in code (api +
>> >> >> > examples).
>> >> >> >
>> >> >> > MartinV
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>