You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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, TextendsEntityView<X>> CriteriaBuilder<T> applySetting(EntityViewSetting<T> setting, CriteriaBuilder<? extendsX> criteriaBuilder);
public <X, TextendsEntityView<X>> PaginatedCriteriaBuilder<T> applySetting(EntityViewPageSetting<T> setting, CriteriaBuilder<? extendsX> criteriaBuilder);
When we have some kind of type safe support in the core module we could additionally add something like this
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 thePagedList
. 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 toThe
EntityViewManager
will get these methods insteadCurrently 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 methodsWhen we have some kind of type safe support in the core module we could additionally add something like this
The text was updated successfully, but these errors were encountered: