Package org.cxbox.core.dto.rowmeta

Class FieldsGroupingHierarchyMeta<T extends org.cxbox.api.data.dto.DataResponseDTO>

java.lang.Object
org.cxbox.api.data.dto.rowmeta.FieldsDTO
org.cxbox.core.dto.rowmeta.RowDependentFieldsCommonMeta<T>
org.cxbox.core.dto.rowmeta.RowDependentFieldsDictionaryDeprecatedMeta<T>
org.cxbox.core.dto.rowmeta.RowDependentFieldsDictionaryMeta<T>
org.cxbox.core.dto.rowmeta.RowDependentFieldsMeta<T>
org.cxbox.core.dto.rowmeta.FieldsCommonMeta<T>
org.cxbox.core.dto.rowmeta.FieldsDictionaryDeprecatedMeta<T>
org.cxbox.core.dto.rowmeta.FieldsDictionaryMeta<T>
org.cxbox.core.dto.rowmeta.FieldsGroupingHierarchyMeta<T>
All Implemented Interfaces:
Iterable<org.cxbox.api.data.dto.rowmeta.FieldDTO>
Direct Known Subclasses:
FieldsMeta
public class FieldsGroupingHierarchyMeta<T extends org.cxbox.api.data.dto.DataResponseDTO> extends FieldsDictionaryMeta<T>

  • Constructor Details

    • FieldsGroupingHierarchyMeta

      public FieldsGroupingHierarchyMeta(@Qualifier("cxboxObjectMapper") com.fasterxml.jackson.databind.ObjectMapper objectMapper, Optional<DictionaryProvider> dictionaryProvider)

  • Method Details

    • defaultGroupingHierarchy

      public <D extends org.cxbox.api.data.dto.DataResponseDTO, E1> void defaultGroupingHierarchy(@NonNull @NonNull DtoField<D,E1> field1, @NonNull @NonNull UnaryOperator<org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E1,?>> hierarchyBuilder)


      This method sets default hierarchy for "GroupingHierarchy" widget, that will always be shown (even, when widget has no data from backend). Use this method only for hierarchies grouped by SINGLE column

      Example 1: explicitly provided default hierarchy (grouped by single Enum field document): 
      
 fields.defaultGroupingHierarchy(
  MeetingDocumentsDTO_.document,
  lvl -> lvl
    .add(Documents.REFERENCE),
    .add(Documents.POLICY)
 );

      Resulting "GroupingHierarchy" widget in UI, when NO data came from backend (e.g. only default hierarchy will be shown): 
      
  UI ("default hierarchy")
 _________________________
 |Document↓   |File      |
 _________________________
 |Reference(0)|          |
 |Policy   (0)|          |
 _________________________
            ↑ ↑
       Backend data
 _________________________
 |Document    |File      |
 _________________________
 _________________________
      Resulting "GroupingHierarchy" widget in UI, when data came from backend (e.g. default hierarchy merged with backend data will be shown) 
      
 UI ("default hierarchy" merged with data)
 _________________________
 |Document↓    |File     |
 _________________________
 |Reference (0)|         |
 |Policy↓   (2)|File1.jpg|
 |             |File2.jpg|
 |Legal     (1)|File3.jpg|
 _________________________
            ↑ ↑
       Backend data
 _________________________
 |Document     |File     |
 _________________________
 |Policy       |File1.jpg|
 |Policy       |File2.jpg|
 |Legal        |File3.jpg|
 _________________________


      Example 2: dynamically provided default hierarchy tree (grouped by single Enum field document). Can be convenient, when default hierarchy structure is configurable through admin UI, so needed to be loaded from DB/microservice: 
      
 fields.defaultGroupingHierarchy(
  MeetingDocumentsDTO_.document,
  l -> Arrays.stream(Documents.values()).collect(Hierarchy.toHierarchyWithCfg(
    e -> e,
    (e, cfg) -> cfg.options(Map.of("sdfsdf", "sdzfdsf"))
   )
  )
 );


      Preconditions for both examples: 
      
 {
  "name": "meetingDocumentsList",
  "title": "",
  "type": "GroupingHierarchy",
  "bc": "meetingDocumentEdit",
  "fields": [
    {
      "title": "Document",
      "key": "document",
      "type": "dictionary"
    },
    {
      "title": "File",
      "key": "file",
      "type": "fileUpload",
      "fileIdKey": "fileId"
    }
  ],
  "options": {
    "groupingHierarchy": {
      "counterMode": "always",
      "fields": ["document"]
    }
  }
 }
 
      
 public enum Documents {
  REFERENCE("Reference"),
  POLICY("Policy"),
  LEGAL("Legal");

  @JsonValue
  private final String value;
 }
 
      
 public class MeetingDocumentsDTO extends DataResponseDTO {
  @SearchParameter(name = "document", provider = EnumValueProvider.class)
  private Documents document;

  @SearchParameter(name = "file", provider = StringValueProvider.class)
  private String file;

  private String fileId;;
 }
      see details in documentation

      Type Parameters:
      D - DTO type
      E1 - DTO field type. Usually one will use field with "type":"input" or "type":"dictionary, so DTO field types will usually be String or Enum
      Parameters:
      field1 - FIRST field listed in .widget. json -> "options" -> "groupingHierarchy" -> "fields"
      hierarchyBuilder - builder for default hierarchy. See usage example at this java-doc beginning

    • defaultGroupingHierarchy

      public <D extends org.cxbox.api.data.dto.DataResponseDTO, E1, E2> void defaultGroupingHierarchy(@NonNull @NonNull DtoField<D,E1> field1, @NonNull @NonNull DtoField<D,E2> field2, @NonNull @NonNull UnaryOperator<org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E1,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E2,?>>> hierarchyBuilder)


      This method sets default hierarchy for "GroupingHierarchy" widget, that will always be shown (even, when widget has no data from backend). Use this method only for hierarchies grouped by TWO columns

      Example 1: explicitly provided default hierarchy tree (grouped by two Enum fields document and then briefing): 
      
 fields.defaultGroupingHierarchy(
  MeetingDocumentsDTO_.document,
  MeetingDocumentsDTO_.briefing,
  lvl -> lvl
    .add(
        Documents.REFERENCE,
        lvl2 -> lvl2.
          add(Briefings.FINANCIAL),
          add(Briefings.PROJECT)
        )
     ),
    .add(
        Documents.POLICY
     )
  )
 );

      Resulting "GroupingHierarchy" widget in UI, when NO data came from backend (e.g. only default hierarchy will be shown): 
      
       UI ("default hierarchy")
 _______________________________________
 |Document↓    | Briefing↓   |File     |
 _______________________________________
 |Reference↓(0)| Financial(0)|         |
 |             | Project  (0)|         |
 |Policy    (0)|             |         |
 _______________________________________
                   ↑ ↑
              Backend data
 _______________________________________
 |Document     | Briefing    |File     |
 _______________________________________
 ______________________________________|

      Resulting "GroupingHierarchy" widget in UI, when data came from backend (e.g. default hierarchy merged with backend data will be shown) 
      
 UI ("default hierarchy" merged with data)
 _________________________________________
 |Document↓    | Briefing↓     |File     |
 _________________________________________
 |Reference↓(1)| Financial  (0)|         |
 |             | Project    (0)|         |
 |             | Operational(1)|File1.jpg|
 |Policy↓   (3)| Security↓  (2)|File2.jpg|
 |             |               |File3.jpg|
 |             | Project    (1)|File4.jpg|
 |Legal     (1)| Operational(1)|File5.jpg|
 _________________________________________
                   ↑ ↑
              Backend data
 _________________________________________
 |Document     | Briefing      |File     |
 _________________________________________
 |Reference    | Operational   |File1.jpg|
 |Policy       | Security      |File2.jpg|
 |Policy       | Security      |File3.jpg|
 |Policy       | Project       |File4.jpg|
 |Legal        | Operational   |File5.jpg|
 _________________________________________


      Example 2: dynamically provided default hierarchy tree (grouped by single Enum field document). Can be convenient, when default hierarchy structure is configurable through admin UI, so needed to be loaded from DB/microservice: 
      
 Map<Documents, Set<Briefings>> external = Map.of(
  Documents.REFERENCE, Set.of(Briefings.FINANCIAL, Briefings.PROJECT),
  Documents.POLICY, new HashSet<>()
 );
 fields.defaultGroupingHierarchy(
  MeetingDocumentsDTO_.document,
  MeetingDocumentsDTO_.briefing,
  lvl1 -> external.entrySet().stream().collect(Hierarchy.toHierarchy(
    Entry::getKey,
    (doc, lvl2) -> doc.getValue().stream().collect(Hierarchy.toHierarchy(brief -> brief))
   )
  )
 );


      Preconditions for both examples: 
      
 {
  "name": "meetingDocumentsList",
  "title": "",
  "type": "GroupingHierarchy",
  "bc": "meetingDocumentEdit",
  "fields": [
    {
      "title": "Document",
      "key": "document",
      "type": "dictionary"
    },
    {
      "title": "Briefing",
      "key": "briefing",
      "type": "dictionary"
    },
    {
      "title": "File",
      "key": "file",
      "type": "fileUpload",
      "fileIdKey": "fileId"
    }
  ],
  "options": {
    "groupingHierarchy": {
      "counterMode": "always",
      "fields": ["document", "briefing"]
    }
  }
 }
 
      
 public enum Documents {
  REFERENCE("Reference"),
  POLICY("Policy"),
  LEGAL("Legal");

  @JsonValue
  private final String value;
 }
 
      
 public enum Briefings {
  FINANCIAL("Financial"),
  PROJECT("Project"),
  SECURITY("Security"),
  OPERATIONAL("Operational");

  @JsonValue
  private final String value;
 }
 
      
 public class MeetingDocumentsDTO extends DataResponseDTO {
  @SearchParameter(name = "document", provider = EnumValueProvider.class)
  private Documents document;

  @SearchParameter(name = "briefing", provider = EnumValueProvider.class)
  private Briefings briefing;

  @SearchParameter(name = "file", provider = StringValueProvider.class)
  private String file;

  private String fileId;;
 }

      Type Parameters:
      D - DTO type
      E1 - DTO field type. Usually one will use field with "type":"input" or "type":"dictionary, so DTO field types will usually be String or Enum
      Parameters:
      field1 - FIRST field listed in .widget. json -> "options" -> "groupingHierarchy" -> "fields"
      field2 - SECOND field listed in .widget. json -> "options" -> "groupingHierarchy" -> "fields"
      hierarchyBuilder - builder for default hierarchy. See usage example at this java-doc beginning

    • defaultGroupingHierarchy

      public <D extends org.cxbox.api.data.dto.DataResponseDTO, E1, E2, E3> void defaultGroupingHierarchy(@NonNull @NonNull DtoField<D,E1> field1, @NonNull @NonNull DtoField<D,E2> field2, @NonNull @NonNull DtoField<D,E3> field3, @NonNull @NonNull UnaryOperator<org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E1,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E2,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E3,?>>>> hierarchyBuilder)


      This method sets default hierarchy for "GroupingHierarchy" widget, that will always be shown (even, when widget has no data from backend). Use this method only for hierarchies grouped by TREE columns

      See usage example here defaultGroupingHierarchy(DtoField, DtoField, UnaryOperator)

      Type Parameters:
      D - DTO type
      E1 - DTO field type. Usually one will use field with "type":"input" or "type":"dictionary, so DTO field types will usually be String or Enum
      Parameters:
      field1 - FIRST field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      field2 - SECOND field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      field3 - THIRD field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      hierarchyBuilder - builder for default hierarchy. See usage example at this java-doc beginning

    • defaultGroupingHierarchy

      public <D extends org.cxbox.api.data.dto.DataResponseDTO, E1, E2, E3, E4> void defaultGroupingHierarchy(@NonNull @NonNull DtoField<D,E1> field1, @NonNull @NonNull DtoField<D,E2> field2, @NonNull @NonNull DtoField<D,E3> field3, @NonNull @NonNull DtoField<D,E4> field4, @NonNull @NonNull UnaryOperator<org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E1,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E2,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E3,org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<E4,?>>>>> hierarchyBuilder)
      ---------------------------------------------------------------------------------------------------------------
      This method sets default hierarchy for "GroupingHierarchy" widget, that will always be shown (even, when widget has no data from backend). Use this method only for hierarchies grouped by FOUR columns

      See usage example here defaultGroupingHierarchy(DtoField, DtoField, UnaryOperator)

      Type Parameters:
      D - DTO type
      E1 - DTO field type. Usually one will use field with "type":"input" or "type":"dictionary, so DTO field types will usually be String or Enum
      Parameters:
      field1 - FIRST field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      field2 - SECOND field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      field3 - THIRD field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      field4 - FOURTH field listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields"
      hierarchyBuilder - builder for default hierarchy. See usage example at this java-doc beginning

    • defaultGroupingHierarchy

      public <D extends org.cxbox.api.data.dto.DataResponseDTO> void defaultGroupingHierarchy(@NonNull @NonNull List<DtoField<D,?>> groupByFields, @NonNull @NonNull org.cxbox.api.data.dto.hierarhy.grouping.Hierarchy<?,?> hierarchy)


      Internal API.

      This method sets default hierarchy for "GroupingHierarchy" widget, that will always be shown (even, when widget has no data from backend). This method is designed to support hierarchies grouped by more, then FOUR columns, but is not strongly typed, so is marked as internal for other cases.

      Please, do not use this method directly. Use one of existing STRONGLY TYPED methods:
      or create own analog if more, then FOUR hierarchy levels are needed
      Type Parameters:
      D - - DTO
      Parameters:
      groupByFields - for widget with "type": "GroupingHierarchy" exactly equal to fields listed in .widget.json -> "options" -> "groupingHierarchy" -> "fields". Fields must be listed in same sequence
      hierarchy - hierarchy structure. This structure will be shown even when widget has no data. If data is present - hierarchy parts that are not present in data will be shown too