SAPUI5 TreeTable - フラット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-アプローチは、バックエンド側に送信されるように変更を追跡することが難しくなります。したがって、ユーザーによって変更されたノードを見つけることが目的です。ここでは、の後に元の解析データと状態のデータの間に差分を作成することについて考えることができます。または、ユーザーが文書IDに行った変更のマップを保持し、変更を送信したい場合はこのデータをodata呼び出しに変えることができます。

UPD 1：（バックエンドを介して）平坦つによって定義されるツリー構造のための「遅延ロード」の

実装は問題であろう。私の理解では、ツリーの遅延読み込みは次のようになります。

最初のUIはすべてのアイテムを第1レベルからロードします。次に、第1レベルの「展開」ボタンをクリックすると、UIは第2レベルをフェッチするようにコールします。

"フラット"リストの遅延読み込みは、ユーザーがテーブルをスクロールしていて、（thresholdプロパティに基づいて）底面に達している間に、別のデータを要求します。& $ top OData呼び出しのプロパティ。

私は、バックエンドからプロパティツリー構造を使用せずに遅延ロードを行うことはできないことを恐れています。

可能な回避策は、アイテムの量を減らすための種類のフィルタを提供することです。

"この構文解析をどこに置くか"についての質問は、コントローラーで "読み取り"要求を手動で実行し、次に "成功"メソッドで構文解析を呼び出し、解析されたデータに基づいてJSONModelを構築し、テーブルをこのモデルにバインドします。