Allow specifying properties that a class level @JsonView applies to

[nimo23]

Please add the ability to adjust the (de)serializable fields of a JsonView on class level. For example:

@JsonView(view=JsonViews.Subset.class, properties={ "id", "username" })
public class User {

private String id;
private String username;
..

}

Benefits:

• no more need to annotate @JsonView on properties/getters/setters
• we can now see at class level which properties are parts of this JSONView instead of looking/searching for such annotations in the class.

[JooHyukKim]

@nimo23 How about using @JsonIgnoreProperties or @JsonIncludeProperties instead?
They are class level annotations/functionalities

[nimo23]

Yes, that could cover all use cases. Then I ask to extend the functionality of @JsonIgnoreProperties or @JsonIncludeProperties to allow passing a specified JsonView schema. For example:

@JsonIncludeProperties(view=JsonViews.Subset.class, value={"id", "username"})
@JsonIgnoreProperties(view=JsonViews.Private.class, value={"password"})
public class User {

private String id;
private String username;
private String password;
..

}

I think the benefits of such functionality are obvious (see above).

The only question is which is better. Currently there can only be one class-level annotation of @JsonIncludeProperties and @JsonIgnoreProperties. Something like this is not allowed:

@JsonIncludeProperties(view=JsonViews.OnlyUsername.class, value={"username"})
@JsonIncludeProperties(view=JsonViews.Subset.class, value={"id", "username" })
@JsonIgnoreProperties(view=JsonViews.Private.class, value={"password"})
public class User {

private String id;
private String username;
private String password;
..

}

With @JsonSchema at class level, the following could be possible:

// many JsonSchemas can be defined on class level
@JsonSchema(view=JsonViews.OnlyUsername.class, value={"username"})
@JsonSchema(view=JsonViews.Subset.class, value={"id", "username"})
public class User {

private String id;
private String username;
private String password;
..

}

[cowtowncoder]

-1 for mixing Views with @JsonIncludeProperties and @JsonExcudeProperties, let's not combine the two.

I can see some benefits from the original suggestion, although will likely not have time to work on anything on it -- this would probably require sizable changes to view processing. But would be willing to help if someone wanted to try a PR.

Will convert to Issue.

[cowtowncoder]

@nimo23 Actually, one quick question first... the original example doesn't quite explain the use case since by default, class-level @JsonView applies itself to all properties. Is the idea that a subset would be included ( I guess so, otherwise what's the point).

And from that, instead of properties, should probably have include and/or exclude (only allow specifying one set) to allow specifying properties either by inclusion (only these properties are included in this view) or exclusion (everything except these properties).

[nimo23]

@JSONVIEW applies itself to all properties. Is the idea that a subset would be included ( I guess so, otherwise what's the point).

Yes, exactly.

And from that, instead of properties, should probably have include and/or exclude

That would be perfect. A side note: Even with include/exclude, you have to define .without(MapperFeature.DEFAULT_VIEW_INCLUSION); to (de)serialize only a subset and not a union (of custom and default view), right?

mapper
.getSerializationConfig()
.withView(JsonViews.Subset.class)
.without(MapperFeature.DEFAULT_VIEW_INCLUSION);

For example:

// that what is not included is implicitly excluded:
@JsonView(view=JsonViews.Subset.class, include={ "id", "username" })

// that what is not excluded is implicitly included:
@JsonView(view=JsonViews.Public.class, exclude={ "password" })
public class User {

private String id;
private String username;
String password;
..

}

[cowtowncoder]

On MapperFeature.DEFAULT_VIEW_INCLUSION... probably, yes.

Change to allow multiple instances of @JsonView would require non-trivial changes to AnnotationIntrospector, but I can see why that'd be useful (generally there's almost always more than one view in use).

[cowtowncoder]

Actually, since this is not in jackson-databind, can't convert. So will leave discussion as-is.

If anyone is to work on this, need to create relevant issues in jackson-annotation (for annotation change, small thing) and jackson-databind (for actual use of annotation, main work).