CN117215543B

CN117215543B - 适用于不同业务场景类型的组件开发方法及其对应的系统

Info

Publication number: CN117215543B
Application number: CN202311481395.7A
Authority: CN
Inventors: 李天一
Original assignee: Beijing Ruicheng Times Information Technology Co ltd
Current assignee: Beijing Ruicheng Times Information Technology Co ltd
Priority date: 2023-11-09
Filing date: 2023-11-09
Publication date: 2024-02-09
Anticipated expiration: 2043-11-09
Also published as: CN117215543A

Abstract

本发明公开一种适用于不同业务场景类型的组件开发方法及其对应的系统，用以降低低代码/零代码组件开发过程中成本。组件开发方法包括：确定待抽象组件的组件名称、组件编码、组件版本号并进行DSL表述；对待抽象组件中的元素进行区域划分，并基于组件属性DSL标准，对待抽象组件的全局区域以及划分出的多个区域按照属性的上下级逻辑关系进行属性DSL表述；基于组件数据DSL标准，对待抽象组件所表达的数据及其结构进行数据DSL表述；基于组件事件DSL标准，对待抽象组件所支持的触发事件进行事件DSL表述；基于组件行为DSL标准，对待抽象组件所具备的行为动作进行行为DSL表述；按照接口标准，按需构建待抽象组件的接口，并基于统一的解释器完成组件的发布。

Description

适用于不同业务场景类型的组件开发方法及其对应的系统

技术领域

本发明涉及组件开发领域，尤其涉及一种适用于不同业务场景类型的组件开发方法及其对应的系统。

背景技术

在低代码领域中，实现途径有两种：一种为通过生成代码的方式；一种为通过抽象组件为特定的DSL语言，再配合特定的解释器进行解释。由于第一种方式的复杂程度更高，导致错误率比较高，所以目前领域内通常采用第二种方式。

相关领域中，在采用第二种方式（通过DSL抽象化组件）进行开发实现时，均需针对不同的业务场景类型分别进行DSL抽象和组件化，如针对可视化类业务场景，抽象出常用的图表、地图等为组件；针对流程表单类，抽象出表单相关元素等为组件。然后分别再为其各自开发解释器。现有技术方案中均需要针对可视化类和流程表单类分别进行组件化和解释器的开发，造成开发工作量大、成本高的缺点。且该类低代码/零代码平台从架构层面就需要考虑将不同的业务场景实现方式单独划分出组件进行管理，或者直接作为两套不同的系统进行开发，架构复杂，降低了整套平台系统的稳定性和可扩展性；且在不同业务场景中，通常都有类似的组件，也需要分别抽象开发，造成大量的成本浪费。

发明内容

本发明实施例提供一种适用于不同业务场景类型的组件开发方法及其对应的系统，用以解决现有技术中低代码/零代码组件开发浪费资源的问题。

本发明实施例的适用于不同业务场景类型的组件开发方法，包括：

确定待抽象组件的组件名称、组件编码、组件版本号并进行DSL表述；

对所述待抽象组件中的元素进行区域划分，并基于组件属性DSL标准，对所述待抽象组件的全局区域以及划分出的多个区域按照属性的上下级逻辑关系进行属性DSL表述；所述组件属性DSL标准限定属性DSL表述内容包括属性项名称、属性布局、属性值类型、属性值单位、属性值范围、属性启用状态；

基于组件数据DSL标准，对所述待抽象组件所表达的数据及其结构进行数据DSL表述；所述组件数据DSL标准限定数据DSL表述内容包括数据维度和数据集；

基于组件事件DSL标准，对所述待抽象组件所支持的触发事件进行事件DSL表述；所述组件事件DSL标准限定事件DSL表述内容包括事件声明和区域对应事件声明，所述事件声明包括事件类型、事件名称、事件编码；所述区域对应事件声明用于声明各区域对应支持的事件；

基于组件行为DSL标准，对所述待抽象组件所具备的行为动作进行行为DSL表述；所述组件行为DSL标准限定行为DSL表述内容包括行为名称、行为编码、行为参数、行为启用状态；

按照接口标准，按需构建所述待抽象组件的接口，并基于统一的解释器完成组件的发布。

本发明实施例的适用于不同业务场景类型的组件开发系统，包括：

DSL表述单元，用于：获取待抽象组件的组件名称、组件编码、组件版本号并进行DSL表述；对所述待抽象组件中的元素进行区域划分，并基于组件属性DSL标准，对所述待抽象组件的全局区域以及划分出的多个区域按照属性的上下级逻辑关系进行属性DSL表述；所述组件属性DSL标准限定属性DSL表述内容包括属性项名称、属性布局、属性值类型、属性值单位、属性值范围、属性启用状态；基于组件数据DSL标准，对所述待抽象组件所表达的数据及其结构进行数据DSL表述；所述组件数据DSL标准限定数据DSL表述内容包括数据维度和数据集；基于组件事件DSL标准，对所述待抽象组件所支持的触发事件进行事件DSL表述；所述组件事件DSL标准限定事件DSL表述内容包括事件声明和区域对应事件声明，所述事件声明包括事件类型、事件名称、事件编码；所述区域对应事件声明用于声明各区域对应支持的事件；基于组件行为DSL标准，对所述待抽象组件所具备的行为动作进行行为DSL表述；所述组件行为DSL标准限定行为DSL表述内容包括行为名称、行为编码、行为参数、行为启用状态；

接口配置单元，用于按照接口标准，按需构建所述待抽象组件的接口；

解释器，用于完成组件的发布。

本发明实施例还提出一种计算机设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的适用于不同业务场景类型的组件开发方法的步骤。

本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现如上所述的适用于不同业务场景类型的组件开发方法的步骤。

采用本发明实施例，可以同时支持不同业务类型的系统低代码配置，可以大量降低系统复杂度以及开发、管理的成本。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。在附图中：

图1是本发明实施例适用于不同业务场景类型的组件开发的方法的原理图；

图2是本发明实施例中组件整体结构划分示意图；

图3是本发明实施例中组件属性划分结构示意图；

图4是本发明实施例中组件数据结构划分示意图；

图5是本发明实施例中组件内部的运行流程图；

图6是本发明实施例中适用于不同业务场景类型的组件开发方法时序图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。另外，在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

在描述本发明实施例之前，首先对本发明中涉及到的专业术语进行前置解释，以供读者更容易理解本发明。

低代码/零代码平台：一种无需编码或通过少量代码就可以快速生成应用程序的开发平台，它可以让用户通过“拖拉拽”的交互方式快速配置出相应的功能。

DSL：低代码/零代码平台常用的一种实现方式。通过对特定领域进行抽象，再配合单独的解释器进行解释执行，以实现“拖拉拽”配置的能力。

组件：对系统功能的细粒度抽象。在UI界面方面，可以是一个按钮或者一组具备某种功能的组合；在后端逻辑方便，可以是一个功能服务或包含特定数据结构的算法等。

组件化：抽象定义和开发组件的过程。

对所述待抽象组件中的元素进行区域划分，并基于组件属性DSL标准，对所述待抽象组件的全局区域以及划分出的多个区域按照属性的上下级逻辑关系进行属性DSL表述。每个组件默认都拥有一个全局区域，代表该组件整体。

所述组件属性DSL标准限定属性DSL表述内容包括属性项名称、属性布局、属性值类型、属性值单位、属性值范围、属性启用状态。属性项名称表征属性的名称，如颜色、系列、宽高等。属性布局表征属性在配置面板中的布局方式，例如可以采用数组方式进行表示。属性值类型表征属性的值类型，如字符串、整数等。属性值单位表征值的单位，如px、摄氏度等。属性值范围表征属性的取值范围，针对枚举类型采用数组表示可能取值；针对数字范围采用数学上的开闭区间表示法，如[0, +∞)等。属性启用状态表征是否开放该属性给用户进行配置。

基于组件数据DSL标准，对所述待抽象组件所表达的数据及其结构进行数据DSL表述；所述组件数据DSL标准限定数据DSL表述内容包括数据维度和数据集。数据维度用来描述组件数据支持哪几个维度，每个维度的名字是什么。

基于组件行为DSL标准，对所述待抽象组件所具备的行为动作进行行为DSL表述；所述组件行为DSL标准限定行为DSL表述内容包括行为名称、行为编码、行为参数、行为启用状态；行为名称表征行为的名称；行为编码为行为的编码，在组件内部保持唯一性；行为参数表征是否需要执行参数，如需要继续定义如下：参数名称：参数的名称或说明；参数类型：参数的类型，类型为基本数据类型或对整个组件DSL描述的索引；行为启用状态表征是否开放行为给用户配置。

相比于现有技术中低代码/零代码开发中，需要针对可视化类或表单业务流类分别开发，造成工作量大、系统结构复杂、开发和管理成本巨大的问题。本发明实施例可以将不同业务类型下的组件开发方式进行统一，同时支持不同业务类型的系统低代码配置，可以大量降低系统复杂度以及开发、管理的成本。

在上述实施例的基础上，进一步提出各变型实施例，在此需要说明的是，为了使描述简要，在各变型实施例中仅描述与上述实施例的不同之处。

根据本发明的一些实施例，所述接口标准限定了组件初始化接口、组件属性更新接口、组件数据更新接口、组件销毁接口、组件事件注册接口、组件事件取消注册接口、组件兼容性处理接口。

组件初始化接口是组件的初始化创建的接口，组件在该接口实现其自身的初始化创建。组件属性更新接口入参为属性项以及属性新旧值，组件在该接口按需实现各属性变化时自身应该完成的动作。组件数据更新接口入参为组件数据中的数据集部分，组件在该接口实现里完成自身数据的处理。组件销毁接口用来在组件销毁时执行自身的内存释放等操作。组件事件注册接口入参为该组件DSL描述中定义的事件以及区域。组件事件取消注册接口入参与组件事件注册接口入参相同。针对不同版本的兼容性处理接口，组件可在组件兼容性处理接口的实现里进行组件兼容性的处理，入参为组件实例数据的版本号以及实例数据。

根据本发明的一些实施例，所述属性DSL表述、所述数据DSL表述、所述事件DSL表述、以及所述行为DSL表述均采用json数据格式。

根据本发明的一些实施例，所述组件属性DSL标准限定属性DSL表述内容还包括属性说明。

根据本发明的一些实施例，所述区域对应事件声明包括区域编码、区域名称、以及支持的事件或不支持的事件。可以理解，区域对应事件声明可以包括区域编码、区域名称、以及支持的事件；或者，区域对应事件声明包括区域编码、区域名称、以及不支持的事件。区域的编码需要保证唯一性；区域名称能够准确表达区域的内容。支持的事件可单独定义仅支持哪些事件。不支持的事件可单独定义需要排除哪些不支持的事件。

下面参照附图以一个具体的实施例详细描述根据本发明的适用于不同业务场景类型的组件开发方法。值得理解的是，下述描述仅是示例性描述，而不应理解为对本发明的具体限制。

参照图1所示，本发明实施例的适用于不同业务场景类型的组件开发方法包括三部分，分别为：

结合浏览器对界面元素的渲染原理，并考虑不同业务场景类型下组件各自的特性，定义统一的组件化标准，使每个组件都成为一个完整的功能单元；

定义组件的标准接口，约束在低代码/零代码平台实现组件开发时必须实现的接口条件；

针对统一的组件化标准和组件接口标准，实现统一的解释器。

具体的，组件化标准包括组件组成定义与DSL标准。

定义所有组件的组成分为4个方面：

组件的属性：描述组件是什么样子的；

组件的数据：描述组件所表达的数据及其结构；

组件的行为：描述组件能干什么；

组件的事件：描述组件所能响应的交互触发方式；

组件整体结构划分图如图2所示。

以上四个层面分别从组件是什么样子的以及具备什么能力的角度进行抽象，可覆盖所有UI类组件。按照该组件组成定义标准，继续定义DSL描述如下：

组件名称：组件的中文名称；

组件编码：组件的全局唯一编码，采用分段式编码：[公司或组织名称]-[平台名称]-[功能名称]；

组件版本号：标识组件的不同版本；

组件的属性项：集合类型，描述组件所有需要开放的属性；

组件数据：集合类型，采用行列二维表方式；

组件事件：包含所有浏览器所支持的触发事件以及组件特性自定义的事件；

组件行为：针对组件功能所需开放的行为；

组件组成定义标准可采用json数据格式表示，例如：

组件的属性描述一个组件具体是什么样子的。针对每个组件内的元素先进行区域的划分，再针对每个区域进行样式、布局、范围等的描述。按照该标准，其DSL描述如下：

第一层级定义：

区域名称：组件所能划分的区域。定义每个组件默认都拥有一个[全局区域]，代表该组件整体。

其他层级定义：

从第二层级开始，按照属性的逻辑上下级关系进行定义描述，并在每个节点遵循以下描述标准。

属性项名称：限定属性的名称，如颜色、系列、宽高等；

属性说明：属性的详细说明，为可选项；

属性布局：限定属性在配置面板中的布局方式，采用数组方式进行表示，如[1, 2]表示一行两列等；

属性值类型：限定属性的值类型，如字符串、整数等；

属性值单位：值的单位，如px、摄氏度等；

属性值范围：限定属性的取值范围，针对枚举类型采用数组表示可能取值；针对数字范围采用数学上的开闭区间表示法，如[0, +∞)等；

属性是否启用：表征是否开放该属性给用户进行配置，采用布尔类型。

组件属性划分结构图如图3所示。组件属性可采用json数据格式进行表示，例如：

组件数据为组件所表达的数据及其结构，划分为：

数据维度：用来描述组件数据支持哪几个维度，每个维度的名字是什么；

数据集：组件的默认数据，所有的数据集合结构均为二维表格式。

组件数据结构划分图如图4所示。组件数据可采用json数据格式进行表示，例如：

组件的事件定义该组件所支持的触发事件，按照区域进行描述，如“某个区域支持什么事件”。定义分为两部分：

事件声明：默认由平台按照浏览器、移动端等交互媒体进行统一定义，具体如下：

区域对应事件声明：组件所包含区域以及各区域所支持的事件；

区域编码：区域的编码，在组件内需要保证唯一；

区域名称：区域的名称，能够准确表达区域的内容；

支持的事件：可单独定义仅支持哪些事件，为可选项；

不支持的事件：可单独定义需要排除哪些不支持的事件，为可选项；

组件的事件可采用json数据格式进行表示，例如：

组件行为表示组件具备的哪些行为动作，需要根据不同组件按照以下标准继续抽象定义：

行为名称：该行为的名称；

行为编码：该行为的编码，在组件内部保持唯一性；

行为参数：是否需要执行参数，如需要继续定义如下：参数名称：参数的名称或说明；参数类型：参数的类型，类型为基本数据类型或对整个组件DSL描述的索引；

是否启用：是否开放该行为给用户配置。

组件行为可采用json格式进行表示，例如：

组件接口实现标准中，按照对组件的抽象化定义标准，继续定义组件的接口标准：

组件初始化接口：组件的初始化创建的接口，组件在该接口实现其自身的初始化创建；

组件属性更新接口：入参为属性项以及属性新旧值，组件在该接口按需实现各属性变化时自身应该完成的动作；

组件数据更新接口：

入参为组件数据中的数据集部分，组件在该接口实现里完成自身数据的处理；

组件销毁接口：销毁组件的接口，组件可以实现该接口用来在组件销毁时执行自身的内存释放等操作；

组件事件注册接口：组件的事件注册接口，入参为该组件DSL描述中定义的事件以及区域；

组件事件取消注册接口：组件的事件取消注册接口，入参与组件事件注册接口入参相同；

组件兼容性处理接口：针对不同版本的兼容性处理接口，组件可在该接口的实现里进行组件兼容性的处理。入参为组件实例数据的版本号以及实例数据。

以上为组件的标准接口，各组件在实现过程中按需实现各接口。按照接口标准，组件内部的运行流程如图5所示。

组件接口可以采用javascript或其他任何语言进行实现，以下为javascript实现接口标准的参考示例，可参考理解接口标准含义：

/**

* 组件初始化方法

* 1、初始化时调用（ created钩子内），只调用一次

*/

init() { },

/**

* 组件属性修改方法

* 当组件props中config变化时会被调用，每次变化都会调用

* @param {*} config，数组形式

*/

updateConfig(config) { },

/**

* 组件数据修改方法

* 当组件props中的dataset变化时会被调用，每次变化都会调用

* @param {*} dataset

*/

updateDataset(dataset) { },

/**

* 组件销毁方法

* 当组件被销毁时会被调用（ beforeDestroy钩子内）

*/

destroy() { },

/**

* 组件事件注册方法

* @param {*} eventName 事件的类型

* @param {*} triggerElement 触发的区域

* @param {*} interactionId 对应的交互配置ID

*

* 在该方法内部，需要根据区域和事件，自己实现事件的注册；在注册的事件被触发时，

*. 需要统一调用 this.$emit('executeComponentEvent',interactionId)抛出事件

*/

addEventListener(eventName, triggerElement, interactionId) { },

/**

* 组件事件取消注册方法

* @param {*} eventName 事件的类型

* @param {*} triggerElement 触发的区域

* @param {*} interactionId 对应的交互配置ID

*

* 在该方法内部，需要根据区域和事件，以及交互配置ID，自己实现对应事件的取消注册；

*. 需要注意：同一事件同一区域，可能存在多个交互配置ID

*/

removeEventListener(eventName, triggerElement, interactionId){ },

/**

* 组件兼容处理方法

* 1、在组件初始化前调用，只调用一次

* 2、必须针对当前版本返回一份新的数据，组件的props相关内容会被设置为新的数据

* @param {*} originalVersion 组件实例所对应的版本号

* @param {*} originalPropsData 组件实例数据

* @returns 新的数据

*

* 只有在组件需要处理版本兼容性问题时才需要实现该方法，非必需

*/

compat(originalVersion, originalPropsData) {

// 在这里根据历史版本号和当前option生成一份新版本的数据

// ...

return newPropsData

},

// 以上为每个组件的固定方法（或者说是固定的对外接口），需要组件内部按需实现

// 如果组件内部不写某个方法的话，系统会默认注入没有具体实现的同名方法到组件内部（只有refreshDatasource例外）

//这里可以再增加组件自身需要的其他方法

// ...

// something

参照图6所示，采用本发明实施例的方法抽象化组件的实施流程包括：

在按照组件化标准进行实现时，需要按照以下步骤说明进行：

确定要抽象的组件；

按照标准划分组件的属性、数据、事件、行为；

确定组件属性需要划分为哪些区域；

确定组件各区域中的属性元素；

按照组件属性标准DSL定义确定具体属性项；

按照组件数据DSL标准确定组件的数据维度和数据集；

按照组件行为DSL标准确定组件需要开放的行为；

确定组件需要开放的事件，按照标准进行DSL描述定义；

按照接口标准实现接口；

发布组件到统一的解释器执行。

采用本发明实施例的方法，可以实现在不同业务场景类型下低代码/零代码组件的统一。例如：

可视化类的组件，如图表，可以按照组件化标准方法依照其图表类型定义属性，依照其要呈现的数据定义组件的数据以及其可以响应的用户交互触发事件与要执行的行为；

表单流程类组件，如输入框，也可以按照组件化标准定义其属性、数据和事件、行为，其数据即可以为输入框里输入的内容，作为组件数据后，即可以同时成为组件的输入和输出，同时满足可视化和表单输入的场景需求。

本发明实施例的方法既可以统一低代码/零代码的组件，无需要再分别针对不同业务场景类型各自定制组件和开发各自的解释器，可以提供平台的开发效率，降低投入的成本。且因为将低代码/零代码平台的结构统一到一种逻辑组成上，简化了系统的复杂度，使平台系统更加稳定，更加易扩展等。

需要说明的是，以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

解释器，用于完成组件的发布。

根据本发明的一些实施例，所述区域对应事件声明包括区域编码、区域名称、以及支持的事件或不支持的事件。

本领域的技术人员应该明白，上述的本发明的各单元或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，为可选项地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

本发明实施例的计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线、光缆、射频信号等等，或者上述的任意合适的组合。

需要说明的是，本发明说明书中未作详细描述的内容属于本领域专业技术人员的公知技术。

参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

Claims

1.一种适用于不同业务场景类型的组件开发方法，其特征在于，包括：

2.如权利要求1所述的方法，其特征在于，所述接口标准限定了组件初始化接口、组件属性更新接口、组件数据更新接口、组件销毁接口、组件事件注册接口、组件事件取消注册接口、组件兼容性处理接口。

3.如权利要求1所述的方法，其特征在于，所述属性DSL表述、所述数据DSL表述、所述事件DSL表述、以及所述行为DSL表述均采用json数据格式。

4.如权利要求1所述的方法，其特征在于，所述组件属性DSL标准限定属性DSL表述内容还包括属性说明。

5.如权利要求1所述的方法，其特征在于，所述区域对应事件声明包括区域编码、区域名称、以及支持的事件或不支持的事件。

6.一种适用于不同业务场景类型的组件开发系统，其特征在于，包括：

解释器，用于完成组件的发布。

7.如权利要求6所述的系统，其特征在于，所述接口标准限定了组件初始化接口、组件属性更新接口、组件数据更新接口、组件销毁接口、组件事件注册接口、组件事件取消注册接口、组件兼容性处理接口。

8.如权利要求6所述的系统，其特征在于，所述属性DSL表述、所述数据DSL表述、所述事件DSL表述、以及所述行为DSL表述均采用json数据格式。

9.一种计算机设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至5中任一项所述的适用于不同业务场景类型的组件开发方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现如权利要求1至5中任一项所述的适用于不同业务场景类型的组件开发方法的步骤。