SAPUI5 TreeTable - 平坦的OData

时间:2017-09-04 18:36:00

标签: json odata sapui5

我有一个问题或缺乏想法如何从平坦的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

1 个答案:

答案 0 :(得分:1)

如果你说的那样表格应该有编辑的可能性,你可以使用标准的TreeTable 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
    }
]

如果后端没有机会提供这样的结构,你可以解析你的后端响应并构建JSON模型(解析只是出于分组的原因,你需要将平面结构分组到考虑到密钥的层次结构中:文档ID,年,月,状态..)。

JSON数据结构:

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

                        ]
                    }
                ]
            }
        ]
    }
]

但是这种JSON方法更难以跟踪要发送到后端的更改。因此,任务是找到用户更改的节点,在这里您可以考虑在原始解析数据和之后更改后的状态中使 diff 由用户应用。或者,您可以保留用户对文档ID进行更改的地图,并在用户想要提交更改后将此数据转换为odata调用。

UPD 1:

由平坦的(通过后端)定义的树结构的“延迟加载”的实现将是有问题的。因为据我所知,树的延迟加载如下所示:

最初UI加载了第一级的所有项目。然后在点击第1级的“展开”按钮后,UI会调用以获取第2级,依此类推。

“平面”列表的延迟加载工作方式不同,当用户向下滚动表并到达最底层(基于“阈值”属性)时,表可以通过新的$ skip& OData调用中的$ top属性。

所以我担心在没有后端属性树结构的情况下进行延迟加载是不可能的。

可能的解决方法可能是提供一种过滤器来减少物品数量。

关于“将解析放在何处”的问题 - 你需要在控制器中手动执行“读取”请求,然后在“success”方法中调用解析,然后根据解析的数据构造JSONModel,最后绑定这个模型的表格。