feat: extract interface HierarchicalTreeData from TreeData#23950
feat: extract interface HierarchicalTreeData from TreeData#23950sclassen wants to merge 5 commits intovaadin:mainfrom
Conversation
|
|
TreeDataProvider currently takes a TreeData as its source. But it relies only on a few methods of TreeData. This change extracts those methods into an interface. It then introduces a super class to TreeDataProvider which accepts a HierarchicalTreeData instead of a TreeData. A client has now the choice to either use the TreeData and the TreeDataProvider, or it can implement the HierarchicalTreeData interface and use the HierarchicalTreeDataProvider. This change introduces a new interface and a class but does not change or break any existing API. Fixes vaadin#9808
sclassen
force-pushed
the
hierarchicalTreeDataInterface
branch
from
50682ae to
510379c
Compare
|
This is the minimal change I could find to satisfy the desire to have a custom tree data implementation as it is expressed in #9808.
The name of the new interface is semi optimal, as "hierarchical" is already used in other class names with a slightly different semantics. |
This second gerenic parameter represents the concrete type of the HierarchicalTreeData. Having this as a generic parameter allows for better type safty. The client of the provider can get the underlying data structure in a type safe manner. This eases writing stable code.
mshabarov
added
the
Contribution
|
| * @param <T> | ||
| * data type | ||
| */ | ||
| public interface HierarchicalTreeData<T> extends Serializable { |
There was a problem hiding this comment.
Better name is HierarchicalData IMHO.
| * @return {@code true} if the item is in this hierarchy, {@code false} if | ||
| * not | ||
| */ | ||
| boolean contains(T item); |
There was a problem hiding this comment.
Makes sense to add List<T> getRootItems(); as a convenient shorthand even though it's not currently used by TreeDataProvider.
There was a problem hiding this comment.
I do not agree.
This would require that every implementation can produce the list of all roots from any given item. This is demanding if the underlying implementation relies on references instead of a central map.
For me this is a high barrier to pass especially for a functionality which is not used by flow at all.
...data/src/main/java/com/vaadin/flow/data/provider/hierarchy/HierarchicalTreeDataProvider.java
Outdated
Show resolved
Hide resolved
...data/src/main/java/com/vaadin/flow/data/provider/hierarchy/HierarchicalTreeDataProvider.java
Outdated
Show resolved
Hide resolved
.../src/main/java/com/vaadin/flow/data/provider/hierarchy/InMemoryHierarchicalDataProvider.java
Show resolved
Hide resolved
- rename HierarchicalTreeDataProvider.java -> InMemoryHierarchicalDataProvider.java - rename HierarchicalTreeData.java -> HierarchicalData.java - add method InMemoryHierarchicalDataProvider.getHierarchicalData()
4 participants
Description
TreeDataProvider currently takes a TreeData as its source. But it relies only on a few methods of TreeData.
This change extracts those methods into an interface. It then introduces a super class to TreeDataProvider which accepts a HierarchicalTreeData instead of a TreeData. A client has now the choice to either use the TreeData and the TreeDataProvider, or it can implement the HierarchicalTreeData interface and use the HierarchicalTreeDataProvider.
This change introduces a new interface and a new class but does not change or break any existing API.
Fixes #9808
Type of change
Checklist
Additional for
Featuretype of change