基于数据交换协议的界面生成方法、装置、设备及介质

技术领域

本申请涉及前端开发的技术领域，尤其是涉及一种基于数据交换协议的界面生成方法、装置、设备及介质。

背景技术

在互联网技术中，WEB前端网页开发主要职能就是把网站的WEB前端界面更好地呈现给用户。目前的WEB前端界面主要通过程序员根据界面需求进行编写，每次编写都需要自己部署界面中每个元素的位置，在对网页进行更新时，则需要重新部署规划每个元素的位置，增加程序员的工作量，并且要编写大量的重复代码，从而影响WEB前端网页的开发效率。

发明内容

为了提高WEB前端网页的开发效率，本申请提供一种基于数据交换协议的界面生成方法、装置、设备及介质。

第一方面，本申请提供一种基于数据交换协议的界面生成方法，采用如下的技术方案：

一种基于数据交换协议的界面生成方法，包括：

响应于用户的前端界面生成指令，获取待生成前端界面的数据交换协议对应的协议数据；

基于所述协议数据调用与所述协议数据对应的功能控件；

基于所述协议数据和所述功能控件生成前端界面。

通过采用上述技术方案，在进行WEB前端网页开发时，根据待生成前端界面的协议数据调用相应的功能控件，功能控件根据协议数据自动布局协议数据中每个数据的位置，无需程序员自己布局，只需提供协议数据，从而提高WEB前端网页的开发效率。

可选的，所述基于所述协议数据调用与所述协议数据对应的功能控件包括：

获取所述协议数据的数据结构，基于所述数据结构确定所述功能控件的控件属性；

基于所述功能控件类型调用与所述功能控件类型对应的功能控件。

可选的，所述基于所述协议数据和所述功能控件生成前端界面包括：

获取所述待生成前端界面的页面类型；

判断所述协议数据与所述页面类型是否与所述页面类型相匹配；

若所述协议数据与所述页面类型与所述页面类型相匹配，则对所述协议数据进行数据处理，生成可用协议数据；

基于所述可用协议数据和所述功能控件生成前端界面；

若所述协议数据与所述页面类型与所述页面类型不相匹配，则生成空白页面。

可选的，所述基于所述协议数据和所述功能控件生成前端界面包括：

通过后端API将所述协议数据在前端进行数据转换，生成所述可用协议数据；

所述功能控件对所述可用协议数据进行数据布局，生成布局结果；

获取所述可用协议数据的后台数据值；

基于所述后台数据值和所述布局结果生成前端界面。

可选的，在所述获取待生成前端界面的数据交换协议对应的协议数据之前，还包括：

判断所述协议数据的数据配置格式是否为预设数据配置格式；

若所述协议数据的数据配置格式是预设数据配置格式，则获取所述协议数据；

若所述协议数据的数据配置格式不是预设数据配置格式，则不获取所述协议数据。

第二方面，本申请提供一种基于数据交换协议的界面生成装置，采用如下的技术方案：

一种基于数据交换协议的界面生成装置，包括：

数据获取模块，用于响应于用户的前端界面生成指令，获取待生成前端界面的数据交换协议对应的协议数据；

控件调用模块，用于基于所述协议数据调用与所述协议数据对应的功能控件；

界面生成模块，用于基于所述协议数据和所述功能控件生成前端界面。

通过采用上述技术方案，在进行WEB前端网页开发时，根据待生成前端界面的协议数据调用相应的功能控件，功能控件根据协议数据自动布局协议数据中每个数据的位置，无需程序员自己布局，只需提供协议数据，从而提高WEB前端网页的开发效率。

第三方面，本申请提供一种电子设备，采用如下的技术方案：

一种电子设备，其特征在于，包括处理器，所述处理器与存储器耦合；

所述处理器用于执行所述存储器中存储的计算机程序，以使得所述电子设备执行第一方面任一项所述的基于数据交换协议的界面生成方法的计算机程序。

第四方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，存储有能够被处理器加载并执行第一方面任一项所述的基于数据交换协议的界面生成方法的计算机程序。

附图说明

图1是本申请实施例提供的一种基于数据交换协议的界面生成方法的流程示意图。

图2是本申请实施例提供的一种基于数据交换协议的前端界面结构图。

图3是本申请实施例提供的一种基于数据交换协议的界面生成装置的结构框图。

图4是本申请实施例提供的电子设备的结构框图。

具体实施方式

以下结合附图对本申请作进一步详细说明。

本申请实施例提供一种基于数据交换协议的界面生成方法，该基于数据交换协议的界面生成方法可由电子设备执行，该电子设备可以为服务器也可以为终端设备，其中该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云让算服务的云服务器。终端设备可以是智能手机、平板电脑、台式计算机等，但并不局限于此。

图1为本申请实施例提供的一种基于数据交换协议的界面生成方法的流程示意图。

如图1所示，该方法主要流程描述如下（步骤S101～S103）：

在本实施例中，本方法以插件的形式进行使用，用于提供给WEB前端网页开发的技术人员使用，在技术人员进行使用时，需要将该插件进行安装，并且安装自己所需的功能控件。

步骤S101，响应于用户的前端界面生成指令，获取待生成前端界面的数据交换协议对应的协议数据；

在步骤S101之前，判断协议数据的数据配置格式是否为预设数据配置格式；若协议数据的数据配置格式是预设数据配置格式，则获取协议数据；若协议数据的数据配置格式不是预设数据配置格式，则不获取协议数据。

在本实施例中，待生成前端界面的协议数据需要按照预设数据配置格式进行协议数据配置，在获取待生成前端界面对应的协议数据时，判断已经配置完成的待生成前端界面对应的协议数据是否为根据预设数据配置格式进行协议数据配置完成的协议数据，即协议数据的数据配置格式是否为预设数据配置格式，当判断结果为待生成前端界面对应的协议数据是为根据预设数据配置格式进行协议数据配置完成的协议数据时，则获取带生成前端界面的协议数据，并且在获取待生成前端界面的数据交换协议对应的协议数据时按照预设数据配置格式进行获取。需要说明的是，数据交换协议需要根据实际需求选择能够实现数据交换的数据交换协议，若未设置则默认为JSON。

步骤S102，基于协议数据调用与协议数据对应的功能控件；

针对步骤S102，获取协议数据的数据结构，基于数据结构确定功能控件的控件属性；基于功能控件类型调用与功能控件类型对应的功能控件。

在本实施例中，数据结构为待生成前端界面对应的页面设计中，每个设计点对应的数据，根据数据结构分析数据中每个字段的字段属性，其中，字段属性包括数据名称、数据对应的后端字段、输入数据的长度限制、必填项和图标等，根据字段属性确定每个字段属性对应的功能控件类型，根据功能控件类型调用相应的功能控件。例如，必填项为文本数据需要进行数据输入其对应的功能控件类型为输入类型的功能控件，则调用输入控件，需要说明的是，具体的字段属性和对应的功能控件类型在选择相应的功能控件时，需要根据实际需求进行选择，在此不做进一步举例说明。

步骤S103，基于协议数据和功能控件生成前端界面。

针对步骤S103，获取待生成前端界面的页面类型；判断协议数据与页面类型是否与页面类型相匹配；若协议数据与页面类型与页面类型相匹配，则对协议数据进行数据处理，生成可用协议数据；基于可用协议数据和功能控件生成前端界面；若协议数据与页面类型与页面类型不相匹配，则生成空白页面。

在本实施例中，待生成前端界面的页面类型包括表单页面和表格页面，表单页面和表格页面的协议数据配置中，有相同的协议数据配置也有不同的协议数据配置，当待生成前端界面的页面类型为表单页面时，若获取的协议数据中存在属于表格页面的协议数据，则无法通过功能控件生成前端界面，同理，当待生成前端界面的页面类型为表格页面时，若获取的协议数据中存在属于表单页面的协议数据，则同样无法通过功能控件生成前端界面，当无法通过功能控件生成前端界面时，前端界面将以空白页面的形式进行显示，即生成空白页面。当获取到的协议数据全部都是表单页面的数据或者全部都是表格页面的数据时，将获取到的协议数据进行数据处理，生成可用协议数据，通过可用协议数据和功能控件生成前端界面。

对于表格页面的协议数据配置，除基本的支持表格内容选择的选择控件之外，还可以自定义列数以及每一列的列数据，并且给每一列单独设置后端请求，也可以给每一行数据添件缩略图以及行样式等，在此不做具体限定和进一步举例说明。

对于表单页面的协议数据配置，主要为各类功能控件和页面中各个功能的位置，在表单页面的协议数据配置中，除表单页面中最基本的输入控件、选择控件和日期控件之外，还包括轮播图控件、富文本编辑器控件以及自定义控件等，其中，选择控件包括文件选择和图片选择，即选择控件既可以进行文件上传也可以进行图片上传，自定义控件为根据自己需求的页面中的功能自己定制的专属控件。

进一步的，若需要选择控件仅进行文件选择，则需要进行协议数据配置选择控件的上传类型，需要将上传类型将设置为用户需求的文件类型，例如: doc，zip，ppt等等；若需要选择控件仅进行图片选择，则同样需要进行协议数据配置选择控件的上传类型，需要将上传类型设置为用户需求的图片类型，例如: png，jpge等等。需要说明的是，设置的文件类型需要符合设置的上传类型，具体设置的文件类型在此不做具体限定。

下面分别对表单页面的协议数据配置和表格页面的协议数据配置进行举例说明。

1.表单页面的协议数据配置:

{action: {serviceName: 'file',methodName: 'fileUpload',dto: null,},tabs: {displayName: '**',action: {serviceName: 'file', methodName:'fileUpload',dto:{files:[],isWaterEnabled:false},},fields:[{type:7,label:'',key:'files',},{type:1,key:'isWaterEnabled',label:是否添加水印',valueType:3,isMulti: false,style: 0,},],}}。

2.表格页面的协议数据配置：

{displayName: '某某列表',search: {displayName: '查询',fields: [{rows:1,valueType:1,maxLength: 100,placeholder: '搜索当前文件夹...',type: 0,label:'',key: 'title',isRequired: false,},],},columns: [{columnType: 0,valueType:1,label: '文件名',key: 'title',icon: '图标',url: '',isShow: true,isSort:true,isClick: true,}],multiSelect: false,enablePagination: true,}。

在本实施例中，在表格页面的协议数据配置中,search搜索所使用的就是form表单所使用的协议数据，columns中所保存的为每一列写入的数据中要展示的元素协议数据或者功能协议数据的数据格式，columnType表示其中某一列以什么样的形式进行处理展示，例如，其中的某一列以文本的形式进行处理展示，其中的另一列以下拉框的形式进行处理展示，其中的除上述两列之外的一列以转换器的形式进行处理展示等等；valueType表示数据类型是什么样的；isSort表示此列是否要进行排序；icon表示这一列数据是否要展示图标。需要说明的是，元素协议数据为待生成前端界面中每个元素所对应的位置和外观等，功能协议数据为待生成前端界面中每个具有功能性的需求，例如，输入框、下拉框和复选框等。

其中，排序的目的为进行简单的筛选，使得用户可以方便快速的找到自己需求的数据。在排序时，根据实际需求设置排序的方式和排序的内容，可以让全部的表格按照一种方式进行排序，还可以让表格中所有得到列都拥有自己的排序方式等，在此不做具体限定。

排序的具体实现方式为，把当前列的后台字段进行API请求发送至后端，后端根据自己的设置按照用户需求的排序方式进行数据排列，在排列完毕之后将排列结果发送至前端界面进行页面展示。其中，排序方式包括按照时间等正序排列或者倒序排列，还可以包括按照某种需求以某种固定的形式进行排列等，例如，表格如果有一列是时间, 当前时间从大到小进行排序, 如果点击正序排序, 时间将会从小到大排序, 如果点击倒序排序, 时间不变化，在此不做具体限定和进一步举例说明。

在表单页面的数据配置中,action主要包括了一些request请求的内容；tabs包括一个或者多个tab标签，当tab标签为多个时，每个tab标签包含不同的fields，每个fields中会存放多个功能控件，每个功能控件都对应有基本属性，每个控件的基本属性有label即控件名称、key即对应数据字段、isRequired即是否必填和type即要渲染什么控件等。

其中，设置多个tab标签因为全部的内容放在一个页面上内容太多，所以可以放到多个tab上，当然也可以直接放到一个tab上，当放到多个tab上即设置多个标签页时，多个标签页可以进行反复切换，具体设置为一个tab或者多个tab需要根据实际需求进行设置，在此不做具体限定。

在本实施例中，每个定义好的功能控件都会有自己的type即固定的type，前后端协商好的一个type值，在请求后端API时, 可以根据josn中返回的type渲染相对应的功能组件。

进一步的，通过后端API将协议数据在前端进行数据转换，生成可用协议数据；功能控件对可用协议数据进行数据布局，生成布局结果；获取可用协议数据的后台数据值；基于后台数据值和布局结果生成前端界面。

在本实施例中，无论是表单页面还是表格页面，为实现相应功能而非仅为一个静态页面均需要依赖于设定的数据值，数据值需要在后端中进行设置。获取后端定义的与上述数据结构相关的泛型类，其中，泛型类包括表格泛型类和表单泛型类，泛型类指的是用后端的语言定义的基类, 即所有的表格应用和表单应用都需要继承各自的泛型类，泛型类包括了表格或者表单用到的公共属性。

对于表格来说，在后端进行定义时，根据表格的数据配置确定表格包含的类型，根据表格包含的类型定义相应的类，每个类都携带有与当前类相关的属性，这些属性决定了当前类在表格中展示的样式。例如，设置有有个日期，对于该日期对应有一个日期DateColumn类, 需要定义日期DateColumn类的相关属性，包括label(名称)、icon(图标)、isShow(是否要展示)、isSort(是否要排序)、columnType(表格列的中展示的数据形式)和valueType(值的类型)，其中当值设为类型为日期时，在表格中会直接展示日期或者展示时间提示等。

对于表单来说, 表单的类型定义和表格如出一辙，同样根据数据配置进行设置，只是对应的类和类相关的属性不一样，在此不做进一步举例说明。

后端的泛型类确定之后，需要根据泛型类定义相应的返回给前端的数据，即协议数据，以表格为例进行说明，首先创建一个TableConfigScheme(表格)对象，并且把表格需要的初始值给到类的构造函数中，其中，初始值指的是除表格列之外的表格属性。然后，定义表格的列，分别创建相关表格列的对象，把列的相关属性值通过构造函数传递到类中，当表格类都定义完成之后，完成返回给前端的数据的定义。在本实施例中，在进行协议数据转换时，前后端一同定义协议数据的格式、属性以及一些扩展属性，而后通过前端规定好的数据格式创建后端数据交换协议用于前端的API请求，前端拿到协议数据之后, 把拿到的协议数据转换成前端需要展示的数据，即生成可用协议数据，由于返回给前端的数据即协议数据中包含了渲染控件的数据值，因此可用协议数据才可以用于表单或者表格循环加载调用不同的功能控件，功能控件根据可用协议数据自动布局，根据布局结果生成前端界面。

图2为本申请实施例提供的一种基于数据交换协议的前端界面结构图。

如图2所示，在本实施例中，整体包括以下几个部分：

前端界面设计器，将组件与OpenAPI的请求参数或输出参数进行映射绑定，生成协议数据。

API服务框架，为业务实现逻辑接口，可通过例如Swagger框架这样的Service API可输出标准OpenAPI描述文档。

中间件单元，将协议数据与API描述文档合并生成可用协议数据。

渲染单元，解析可用协议数据，并从组件库中获取协议中需要的功能控件，并组装成前端界面。

需要说明的是，以上各组件和/单元由软件代码实现，无需前端开发人员重复开发界面，对于后端开发人员来说只需开发接口即可完成调用，能有效提高前后端联调效率。

的示例性说明。整体包括以下几个部分：

图3为申请实施例提供的一种基于数据交换协议的界面生成装置200的结构框图。

如图3所示，基于数据交换协议的界面生成装置200主要包括：

数据获取模块201，用于响应于用户的前端界面生成指令，获取待生成前端界面的数据交换协议对应的协议数据；

控件调用模块202，用于基于协议数据调用与协议数据对应的功能控件；

界面生成模块203，用于基于协议数据和功能控件生成前端界面。

作为本实施例的一种可选实施方式，控件调用模块202具体用于获取协议数据的数据结构，基于数据结构确定功能控件的控件属性；基于功能控件类型调用与功能控件类型对应的功能控件。

作为本实施例的一种可选实施方式，界面生成模块203包括：

类型获取模块，用于获取待生成前端界面的页面类型；

类型判断模块，用于判断协议数据与页面类型是否与页面类型相匹配；

数据生成模块，用于对协议数据进行数据处理，生成可用协议数据；

前端生成模块，用于基于可用协议数据和功能控件生成前端界面；

空白生成模块，用于生成空白页面。

作为本实施例的一种可选实施方式，界面生成模块203具体用于通过后端API将协议数据在前端进行数据转换，生成可用协议数据；功能控件对可用协议数据进行数据布局，生成布局结果；获取可用协议数据的后台数据值；基于后台数据值和布局结果生成前端界面。

作为本实施例的一种可选实施方式，该基于数据交换协议的界面生成装置200还包括：

格式判断模块，用于判断协议数据的数据配置格式是否为预设数据配置格式；

协议数据获取模块，用于获取协议数据；

协议数据丢弃模块，用于不获取协议数据。

在一个例子中，以上任一装置中的模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specificintegratedcircuit，ASIC)，或，一个或多个数字信号处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)，或这些集成电路形式中至少两种的组合。

再如，当装置中的模块可以通过处理元件调度程序的形式实现时，该处理元件可以是通用处理器，例如中央处理器(central processing unit，CPU)或其它可以调用程序的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图4为本申请实施例提供的电子设备300的结构框图。

如图4所示，电子设备300包括处理器301和存储器302，还可以进一步包括信息输入/信息输出(I/O)接口303、通信组件304中的一种或多种以及通信总线305。

其中，处理器301用于控制电子设备300的整体操作，以完成上述的基于数据交换协议的界面生成方法的全部或部分步骤；存储器302用于存储各种类型的数据以支持在电子设备300的操作，这些数据例如可以包括用于在该电子设备300上操作的任何应用程序或方法的指令，以及应用程序相关的数据。该存储器302可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random AccessMemory，SRAM)、电可擦除可编程只读存储器(Electrically Erasable ProgrammableRead-Only Memory，EEPROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、只读存储器(Read-Only Memory，ROM)、磁存储器、快闪存储器、磁盘或光盘中的一种或多种。

I/O接口303为处理器301和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件304用于电子设备300与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(NearField Communication，简称NFC)，2G、3G或4G，或它们中的一种或几种的组合，因此相应的该通信组件104可以包括：Wi-Fi部件，蓝牙部件，NFC部件。

电子设备300可以被一个或多个应用专用集成电路 (Application SpecificIntegrated Circuit，简称ASIC)、数字信号处理器(Digital Signal Processor，简称DSP)、数字信号处理设备(Digital Signal Processing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field ProgrammableGate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述实施例给出的基于数据交换协议的界面生成方法。

通信总线305可包括一通路，在上述组件之间传送信息。通信总线305可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA (ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。通信总线305可以分为地址总线、数据总线、控制总线等。

电子设备300可以包括但不限于移动电话、笔记本电脑、数字广播接收器、PDA（个人数字助理）、PAD（平板电脑）、PMP（便携式多媒体播放器）、车载终端（例如车载导航终端）等等的移动终端以及诸如数字TV、台式计算机等等的固定终端，还可以为服务器等。

本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述的基于数据交换协议的界面生成方法的步骤。

该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器 (R ead-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的申请范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述申请构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中申请的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。