Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to simplify entity view setting API #371

Open
beikov opened this issue Mar 6, 2017 · 0 comments
Open

Try to simplify entity view setting API #371

beikov opened this issue Mar 6, 2017 · 0 comments

Comments

@beikov
Copy link
Member

beikov commented Mar 6, 2017

Currently we drag along the builder type as type variable in the entity view setting which always felt a bit clumsy to me. The reason we do this is so we can return the correct builder type from applySetting which is essential when we do pagination as we want to get access to the PagedList. We could also force the user to do casting in that case but that feels wrong too.

So far, the only thing I came up with that could work, is to have a subtype of EntityViewSetting that serves for paginated stuff. So the API would change to

public static <T> EntityViewSetting<T> create(Class<T> entityViewClass) {...}
public static <T> EntityViewPageSetting<T> create(Class<T> entityViewClass, int firstResult, int maxResults) {...}

The EntityViewManager will get these methods instead

public <T> CriteriaBuilder<T> applySetting(EntityViewSetting<T> setting, CriteriaBuilder<?> criteriaBuilder);
public <T> PaginatedCriteriaBuilder<T> applySetting(EntityViewPageSetting<T> setting, CriteriaBuilder<?> criteriaBuilder);

Currently the user has to specify two separate methods if he wants to support both, paginated and non-paginated querying. This won't change that, but make it easier to read and write the EntityViewSetting and the data access methods.

As this is a major API breaking change, we will defer this change to the next major version.

Here comes another idea. We could additionally introduce a marker interface EntityView to allow more type safety regarding applying an entity view. The marker interface just accepts a type variable that represents the entity type. We could think about allowing to omit the @EntityView annotation in that case.

The EntityViewManager would get these additional methods

public <X, T extends EntityView<X>> CriteriaBuilder<T> applySetting(EntityViewSetting<T> setting, CriteriaBuilder<? extends X> criteriaBuilder);
public <X, T extends EntityView<X>> PaginatedCriteriaBuilder<T> applySetting(EntityViewPageSetting<T> setting, CriteriaBuilder<? extends X> criteriaBuilder);

When we have some kind of type safe support in the core module we could additionally add something like this

public <X, T extends EntityView<X>> CriteriaBuilder<T> applySetting(EntityViewSetting<T> setting, CriteriaBuilder<?> criteriaBuilder, Path<? extends X> viewRoot);
public <X, T extends EntityView<X>> PaginatedCriteriaBuilder<T> applySetting(EntityViewPageSetting<T> setting, CriteriaBuilder<?> criteriaBuilder, Path<? extends X> viewRoot);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant