一、前言

产品研发目标是服务于业务，解决具体业务问题，带来业务价值。

因此，任何产品功能的推出，都应该秉承“从实践中来，到实践中去”的原则，在实战中发现问题，通过新功能设计和功能改进解决这一问题。这样的功能才是最具实用价值的。

然而，实战中我们会遇到大量的层出不穷的问题，而在给定时间范围内资源是有限的。这就要求我们抓住关键矛盾，识别普遍性问题，找出业务影响最大的问题，投入资源，确保ROI最大化。

以上论述对于 Mendix 组件开发同样适用。随着国内Mendix实施项目的增多，平台组件需求与日俱增。一方面，Mendix 鼓励生态伙伴、社区和个人爱好者积极参与贡献（参考历年活动 2021｜2023，欢迎感兴趣的小伙伴踊跃报名）。另一方面，原厂重点投入资源做好那些基础性、普遍性和最具创新性或难度更高的组件。

接下来，Mendix 中国会推出一系列文章，介绍 Mendix平台优质组件以及它们能解决的实际问题，助力项目高效落地。作为首篇，本文将介绍树形组件，其应用场景广泛，但应用条件和配置相对复杂。

二、需求分析

首先，一起来看看以下3个项目需求。

某汽车制造企业公开选型低代码，看重低代码开发平台与制造核心系统、数据的集成能力和实际制造业场景落地实践经验。Mendix 与Teamcener 有现成的connector，可以轻松将研发领域业务数据在低代码平台进行对象建模并获取研发数据。同时，Mendix有大量制造企业应用场景模板和国内外标杆客户，项目实践经验丰富。基于以上原因，该企业选择引进Mendix。在项目开发初期，面临的第一个具体技术问题是，如何将BOM数据结构在Mendix应用中呈现出来。
某消费电子企业，为保持市场竞争力，要进行大量的产品预研和试制，且不同产品研制管理流程差距大。如何高效管理数量庞大的研制项目，IT部门决定引入低代码开发个性化的产品项目管理平台，该平台本身被定位为行业差异化能力（system of differentiator)。Mendix 全栈式低代码能力且支持云原生微服务架构与该企业Cloud First 战略契合，故选择了Mendix平台。实际开发中，需要满足的一个普遍技术场景需求是如何将项目结构WBS在应用中展示出来。
某行业领先家具制造企业，数字化意识强，各主要业务领域通过外采的方式基本完成信息系统全覆盖且稳定运行，企业架构方面有多年的数据中台的实践经验。面向下一个十年，CIO希望更多自主研发，满足个性化业务诉求，探索将本企业业务最佳实践做成数字化产品向同业推广。选择Mendix 平台原因之一，就是Mendix良好的集成性和可扩展性，能与其数据中台快速集成。项目伊始，开发组向我们咨询的第一个技术问题是如何在Mendix中管理并展示公司人员组织架构。

以上3个项目需求都很聚集，也很相似，都是要求前端呈现某种特定数据结构，也就是对前端组件的要求。无论是BOM结构，项目WBS结构，还是组织架构，他们在展示和可操作性上都有以下共性：

有多层次的上下级关系，可以点击打开或收起下级节点，比如装配件A包括零件B和C
每个节点会有一系列属性字段，特定属性可能存在下级节点的上卷计算逻辑，比如采购部门编制数量等于各区域采购团队编制数据加总
选中某个或多选某些节点，可以对这个节点进行详情展示或者属性字段修改、保存操作，或对多个节点进行其他操作

其它可能需求，比如节点展示时可选择展示或隐藏某些字段、不同层次节点呈现不同样式易于辨别、选择节点可勾选单选或多选等，不一而足。

三、树形组件

组件获取

在Mendix Studio Pro中，打开Mendix Marketplace ，搜索关键字 Tree。

即可发现IDE中默认没有的两个组件 Tree View 和Tree Table。（小贴士：都说Mendix 组件库浩如烟海。小伙伴在找组件时别只看IDE中默认安装的，Marketplace是武器库，中文论坛是宝藏，上去搜搜会让你有更多惊喜）

点击下载，三秒搞定安装。此时，你就可以在Toolbox - Widgets - Add-ons 中发现这两个新的组件了！

实体模型适配

在使用树形组件前，需要根据实际数据结构建立正确的实体模型，这一点非常关键！

我们从不同业务场景中抽象出名为Node（E1）的业务数据实体。该实体包含Title（名称）、Text（描述）、Date（创建日期）等业务字段，以及_HasChildren（是否有子节点）、_Root（是否为根节点）这样的Boolean类型的功能性字段。所谓功能性字段，就是不代表实际业务意义但对后续组件配置有作用的字段。我们稍后介绍这两个字段的作用。

除了字段设置，还需要体现出节点之间的层级关系。Mendix强大的建模能力的体现之一，就是我们可以基于同一个实体的自关联关系来建模这种层级关系。体现在上图中就是关联关系ChildSet（A1），表示一个节点可对应多个子节点。

实体建模中另一个非常关键点在于，除了根据实际数据结构建立实体，树形组件要发挥作用，还需要额外引入两个辅助实体，即上图中的TempView（E2）和SelectionHelper（E3），并建立E1、E2、E3之间的必要关联关系A2、A3、A4.

TempView（E2）：非持久存储的辅助实体，将为展示树形组件的页面提供最外层的上下文环境（context），起桥梁作用。
SelectionHelper（E3）：非持久存储的辅助实体，树形组件启用节点选择功能时需要用到该实体，提供记录被选中节点的功能。该实体会默认成为树形组件内置事件的输入参数，提供上下文信息。
A2 ：关联关系，关联当前被选中的节点对象，这一关系的实例化在树形组件内核已实现，用户只需知道并使用即可。
A3 ：关联关系。其中，Nodes用于关联上下文环境实体与需要呈现的数据对象，SelectedMulti和SelectedSingle用于关联当前被选中的多个或单个节点对象，这一信息是从E3的A2获得，并提供给当前页面的其他组件使用。
A4 ：关联关系，配置时需要用到。

以上实体模型和关联关系，大家在理解的基础上，实际使用中基本上可以依葫芦画瓢儿，并在组件配置和事件定义中使用这些实体和关系。（注：后文为方便介绍不同功能需求的实现，给出的截图中的实体模型和上图不完全相同，但涉及的3个核心实体以及4个核心关系都有体现，请大家对号入座加以理解）