2. ThingWorx Composer开发环境
ThingWorx Composer 是 ThingWorx 平台面向工业物联网应用开发者的核心可视化开发环境。它把实体建模、Mashup 界面编排、数据绑定、服务调用和权限控制集中在一个浏览器工作台中。理解 Composer 的组织方式，是后续所有 Mashup 开发工作的前提。本节围绕四个关键问题展开：项目在 Composer 中如何组织、Mashup 编辑器由哪些区域构成、资源库如何支撑复用、以及版本管理与多人协作需要注意什么。
一、项目组织：从实体到 Mashup 的层次关系
ThingWorx 并不像传统 IDE 那样以“工程文件”为中心，而是以实体（Entity）为基本单位。每个实体都有名称、类型、所属项目（Project）和权限标签。常见的实体类型包括 Thing、ThingTemplate、ThingShape、DataShape、Mashup、Service、Stream、ValueStream、StyleTheme 等。Composer 左侧的 Browse 面板按类型分组展示这些实体，而 Projects 面板则按业务或交付维度把它们组织到一起。
项目（Project）本质上是一个逻辑容器，用于把一组相关实体打包，便于导出、导入、迁移和权限分配。例如一个“空压站监控”项目，可能包含：AirCompressor_Thing（设备实例）、AirCompressor_TT（设备模板）、AirCompressor_DS（数据形状）、AirCompressor_Mashup（监控界面）、AirCompressor_Service（业务服务）以及配套的 StyleTheme。项目不改变实体本身的运行逻辑，但决定了它们能否被整体导出为 .twx 扩展包。
实际组织时建议遵循三条原则：第一，按业务域划分项目，而不是按实体类型划分，避免一个项目里只有 Mashup、另一个项目里只有 Thing；第二，命名带前缀，如 ACS_（Air Compressor Station），便于在全局搜索中快速过滤；第三，模板与实例分离，ThingTemplate 放在基础项目，Thing 实例放在现场项目，便于多站点复用。
二、Mashup 编辑器界面构成
打开一个 Mashup 后，Composer 进入 Mashup 编辑器。它由若干固定区域组成，理解每个区域的作用能显著减少误操作。
- 顶部工具栏：包含保存、撤销/重做、预览（Preview）、设备预览模式切换、以及 Mashup 级别的属性入口。
- 左侧 Widget 面板：按类别列出可用控件，如 Layout（布局容器）、Display（Label、Image）、Input（TextField、Button）、Data（Grid、List、Chart）、IoT 专用控件（Gauge、Map、Timeline）等。拖拽即可放入画布。
- 中间画布（Canvas）：所见即所得的编辑区，支持栅格对齐、层级调整、响应式断点设置。画布上的每个控件都是一个可选中对象。
- 右侧属性面板：随选中对象变化，分为
Properties（外观、尺寸、文本）、Events（触发事件）、Bindings（数据绑定）、Services（可调用服务）等标签页。 - 底部数据面板：管理 Mashup 的数据源，包括
Data（查询/服务返回的数据形状）和Session（会话变量）、Application（应用级参数）。
其中最容易出错的是数据绑定。绑定方向必须明确：控件属性绑定到数据源称为“消费数据”，控件事件触发服务称为“产生动作”。例如把 Grid 的 Data 属性绑定到某个 GetCompressorList 服务的返回结果，再把 Button 的 Click 事件绑定到该服务的执行，就构成了“点击查询—表格刷新”的最小闭环。
三、资源库与复用机制
Composer 的“资源库”并不是一个独立菜单，而是由多个可复用实体共同构成的集合。最常用的是 StyleTheme（样式主题）、Master Mashup（母版 Mashup）、Widget 扩展包和 Extension 扩展。
StyleTheme 用于统一颜色、字体、间距和控件外观。工业 HMI 场景中，通常把“正常/警告/报警”三种状态色定义为主题变量，例如 --state-normal: #22c55e、--state-warning: #f59e0b、--state-alarm: #ef4444。这样当客户要求更换配色时，只需改主题，不必逐个控件调整。
Master Mashup 用于定义页面骨架，例如顶部导航栏、左侧菜单、底部状态栏。新建 Mashup 时选择继承某个 Master，即可自动获得这些公共区域，子 Mashup 只关注内容区。这能显著减少多页面应用中的重复劳动。
Widget 扩展包和 Extension 则用于引入平台原生控件之外的能力，例如自定义图表、特殊协议驱动或行业专用控件。导入扩展后，新控件会出现在左侧 Widget 面板中，使用方式与内置控件一致。
四、版本管理与协作开发要点
ThingWorx Composer 本身不提供 Git 式的分支合并，它的版本管理主要依赖实体导出/导入和项目打包。因此协作开发必须建立约定，否则很容易出现“后导入覆盖前导入”的问题。
推荐的做法是：每个开发者维护自己的开发项目，通过 Export 导出 .twx 文件，由集成负责人统一导入到共享测试环境。导入时注意选择“合并”而非“替换”，并检查实体名称是否冲突。对于 Mashup 这类包含大量绑定的实体，建议在导出前先执行一次 Validate，确认没有断开的绑定或缺失的服务。
版本命名建议采用 项目_实体_日期_版本 格式，例如 ACS_Mashup_20250612_v3.twx。每次导入前先备份当前环境，导入后立即在 Preview 中验证关键页面和绑定是否正常。对于生产环境，应只导入经过测试环境验证的包，并保留回滚用的上一版本文件。
- 实体是否已归入正确项目？
- Mashup 是否继承了正确的 Master？
- StyleTheme 是否已应用且状态色一致？
- 所有绑定是否指向存在的服务或数据源？
- 导出前是否已执行 Validate？
- 导入后是否在 Preview 中验证过关键交互？
掌握以上四点后，开发者就能在 Composer 中稳定地组织项目、编辑 Mashup、复用资源并安全协作。这些能力是后续实现设备监控、报警管理和数据分析类 Mashup 的基础。