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).
About Nillable, I don't care :) But following the same logic, what about
JsonTransient?
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:
@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
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>