SAPUI5 TreeTable - flat OData

Question

플랫 OData 데이터에서 TreeTable을 작성하는 방법에 문제가 있거나 그만한 생각이 있습니다. 데이터는이 (열)과 같습니다 계층 좋아한다

• 문서 번호,
• 년,
• 월,
• 상태,
• 몇 가지 더 많은 열

같은 이 :

DOCUMENT 
`- YEAR 
    `- Month 
     `- STATUS 1 
      - data for status 1 #1 
      - data for status 1 #2 
     `- STATUS 2 
      - data for status 2 #1 
      - data for status 2 #2 

ODATA returns: 
DOCUMENT | YEAR | MONTH | STATUS1 | Data for status 1 #1 
DOCUMENT | YEAR | MONTH | STATUS1 | Data for status 1 #1 
DOCUMENT | YEAR | MONTH | STATUS2 | Data for status 2 #1 
DOCUMENT | YEAR | MONTH | STATUS2 | Data for status 2 #2 

질문은 - 어떤 콜백 함수/JSON 형식으로 데이터를 배치하여 데이터를 재구성하는 데 사용할 수 있습니까? 아니면 다른 아이디어?

CDS보기가 있고 OData가 생성되었으므로 UI5에서이 작업을 수행해야합니다. 도움이 될 것입니다.

건배

Kubas

Answer 1

당신이 테이블에 대한 편집 가능성이 있어야 말했듯이, (당신은 바인딩 stanard 트리 테이블 중 하나로, OData를 사용할 수 있지만, 백엔드는 당신에게 계층 적 데이터를 제공해야합니다 경우 바인딩 표준 양방향으로 인해 편집 기능)을 구현하는 데 비용이 들지 않을 것이다, 당신의 경우에는 하나로, OData 구조는 다음과 같이 표시됩니다

[ 
    { 
     ID: "", 
     NodeID: 1, 
     type: "document", 
     title: "", 
     HierarchyLevel: 1, 
     ParentNodeID: null 
    }, 
    { 
     ID: "", 
     NodeID: 2, 
     type: "year", 
     title: "", 
     HierarchyLevel: 2, 
     ParentNodeID: 1 
    }, 
    { 
     ID: "", 
     NodeID: 3, 
     type: "month", 
     title: "", 
     HierarchyLevel: 3, 
     ParentNodeID: 2 
    }, 
    { 
     ID: "", 
     NodeID: 4, 
     type: "status", 
     title: "", 
     HierarchyLevel: 4, 
     ParentNodeID: 3 
    }, 
    { 
     ID: "", 
     NodeID: 5, 
     type: "data for status", 
     data: {}, 
     title: "", 
     HierarchyLevel: 5, 
     ParentNodeID: 4 
    } 
] 

를 백엔드 t에 대한 가능성이없는 경우 이러한 구조를 제공하면 백엔드 응답을 구문 분석하고 JSON 모델을 구성 할 수 있습니다 (구문 분석은 그룹화 이유 일 뿐이므로 문서 ID, 연도, 월, 상태 등 키를 고려하여 계층 구조로 평면 구조를 그룹화해야합니다.).

JSON 데이터 구조 :

가

[ 
    { 
     DocumentId: "", 
     items: [ 
      { 
       year: "", 
       items: [ 
        { 
         month: "", 
         items: [ 
          { 
           status: "" 
          } 

         ] 
        } 
       ] 
      } 
     ] 
    } 
] 

그러나 JSON-접근법이 백엔드 측에 송신 할 수있는 변화를 추적하기 어렵게 만든다. 따라서 사용자가 변경 한 노드를 찾고 여기에서 이후에 원래 구문 분석 된 데이터와 의 데이터 사이에 diff을 변경하는 것에 대해 생각할 수 있습니다. 또는 사용자가 변경 한 문서 ID의 을 유지하고 사용자가 변경 사항을 제출하기를 원하면이 데이터를 odata 호출로 바꿀 수 있습니다.

UPD 1 : (백엔드를 통해) 평면 하나에 의해 정의 된 트리 구조에 대한 "지연로드"의

구현 문제가 될 것입니다. 내 이해를 위해, 나무에 대한 게으른 로딩은 다음과 같이 보일 것입니다 :

처음 UI는 1 단계에서 모든 항목을로드합니다. 그런 다음 첫 번째 레벨의 '펼치기'버튼을 클릭하면 UI에서 두 번째 레벨을 가져 오는 등의 작업을 수행합니다.

"flat"목록의 지연로드는 다르게 작동하며 사용자가 테이블을 아래로 스크롤하고 "임계 값"속성을 기반으로 맨 아래쪽에 도달하면 테이블에서 새로운 $ skip을 통해 더 많은 데이터를 요청할 수 있습니다 & $ top OData 호출의 속성

그래서 저는 백엔드에서 속성 트리 구조 없이는 게으른 로딩을 할 수 없다는 것에 두려워합니다.

가능한 해결 방법은 항목 수를 줄이기 위해 일종의 필터를 제공하는 것일 수 있습니다.

"이 파싱 할 위치"에 대한 질문으로 컨트롤러에서 수동으로 "읽기"요청을 수행 한 다음 "성공"메서드에서 구문 분석을 호출 한 다음 구문 분석 된 데이터를 기반으로 JSONModel을 구성하고 마지막으로 테이블을이 모델에 바인드합니다.