Support for @JsonView Jackson annotation

[sergiorc]

Currently, with the default behaviour, it your controller returns Resource, Resources or PagedResources objects, Jackson Mapper is not able to manage @JSONVIEW properly.

It is posible customize Mapper or MixInAnnotation 's in any way to get this work?

[tinne]

Does Pull request 359 solve your issue?

[sergiorc]

Sorry, Tinne, could you provide a slightly more detailed explanation on how to use?

[tinne]

Sure. Say, you have a detail view for some "configuration item" which is represented by a model bean:

@RequiredArgsConstructor @AllArgsConstructor
public class Configuration extends ResourceSupport {

    @Getter
    private final String guid;

    @Getter
    private final String name;

    @Getter @Setter
    private String description;

    @Getter @Setter
    private boolean active;
}

and you need a collection view with a lot of "Configuration" objects but only minimal data, say, guid and name. Then, annotating these by a custom JsonView interface annotation like this,

@RequiredArgsConstructor @AllArgsConstructor
public class Configuration extends ResourceSupport {

    public interface ConfigurationOverview extends Link.LinkView {}

    @Getter
    @JsonView(ConfigurationOverview.class)
    private final String guid;

    @Getter
    @JsonView(ConfigurationOverview.class)
    private final String name;
...
}

and annotating the overview rest controller like this,

RestController
public class ConfigurationController {

    @RequestMapping(value = "/configuration", method = GET)
    @JsonView(Configuration.ConfigurationOverview.class)
    public HttpEntity<Configuration[]> allConfigurations() { ... }
}

you get an JSON 'view' of the configurations.

[sergiorc]

Thanks Tinne.
This is the same case I had tested, but using ResourceSupport instead Resource.
I'm applying @JSONVIEW annotations directly to the properties of my domain objects, but it's not working (view result is empty).
Is this patch intended to cover also Resource?
Should it be working?

[tinne]

In order for Resource and Resources to work, an additional patch was necessary, which extends the coverage of the Link.LinkView interface to the content property of these two container classes. It has now been added to the pull request, please give it a try.

[sergiorc]

Great work Tinne, It works like a charm.
Only one more thing. Does it make sense to maintain the name Link.LinkView?
May be other options be more intuitive.

[tinne]

I followed the convention introduced by some introductory blog entry, but am free for any alterations. Maybe lifting the marker interface to be a top-level module is also more spring-alike. What do you think?

[sergiorc]

Yes, I think the View interface should be out of Link class.

[tinne]

The marker interface is now a top-level module called ResourcesLinksVisible.

[sergiorc]

It's much clearer for me now. Of course, it keeps working.
Thank you again Tinne.