CN112287266A - 一种网页配置的处理方法及其装置、设备及存储介质 - Google Patents

Abstract

本申请提供了一种网页配置的处理方法及其装置、设备及存储介质；所述方法包括：对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；基于所述属性标识，获取所述配置属性对应的取值；根据所述配置属性的属性信息和所述取值生成配置文件；将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。通过本申请，能够自动生成网页在管理后台的配置界面。

Description

一种网页配置的处理方法及其装置、设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种网页配置的处理方法及其装置、设备及存储介质。

背景技术

近几年来，互联网产业发展非常迅速，尤其是移动端业务，不管是应用程序(App，Application)或者是网页都呈现了热度高速增长的态势。在这个背景之下，同类型产品之间的竞争渐渐白热化，不同产品的功能差异越来越难成为产品的优势。因此，各个厂商渐渐重视产品的内容质量，这个时候精准投放的重要性就不言而喻了。为了从不同角度为用户提供喜爱的内容，高效、快速、能够紧抓时事热点的运营在这种场景下起到了核心作用。

以网页为例，为了让运营人员能够独立完成内容的运营，开发人员需要基于组件齐全、可扩展性强的用户界面(UI，User Interface)框架开发管理后台，增加了开发人员的工作量，从而提高了人力成本。

发明内容

本申请实施例提供一种网页配置的处理方法及其装置、设备及存储介质，能够自动生成网页在管理后台的配置界面。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种网页配置的处理方法，包括：

对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；

基于所述属性标识，获取所述配置属性对应的取值；

根据所述配置属性的属性信息和所述取值生成配置文件；

将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

本申请实施例提供一种网页配置的处理方法，包括：

接收开发终端生成的配置文件；

获取所述配置文件的第一文件类型；

将所述配置文件转换为所述第一文件类型对应的配置界面。

本申请实施例提供一种网页配置的处理装置，包括：

解析模块，用于对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；

第一获取模块，用于基于所述属性标识，获取所述配置属性对应的取值；

第一生成模块，用于根据所述配置属性的属性信息和所述取值生成配置文件；

文件传输模块，用于将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

本申请实施例提供一种网页配置的处理装置，包括：

第二获取模块，用于获取开发终端生成的配置文件；

第三获取模块，用于获取所述配置文件中各个配置属性的类型；

第一确定模块，用于根据所述各个配置属性的类型确定第一界面组件；

第一转换模块，用于基于所述第一界面组件将所述配置文件转换为对应的配置界面。

本申请实施例提供一种网页配置的处理设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的方法。

本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的方法。

本申请实施例具有以下有益效果：

在对待生成配置文件的组件进行解析，获取到组件中需要配置的属性的基本信息和属性对应的取值后，可以根据配置属性的属性信息和取值自动生成配置文件，进而再将配置文件提供给运营终端，以使得运营终端能够根据配置文件自动转换为与其文件类型对应的配置界面；如此，能够实现配置界面的自动生成，从而无需开发人员额外开发配置界面，进一步降低运营体系的开发成本。

附图说明

图1A为相关技术中可运营体系的架构示意图；

图1B是本申请实施例网页配置的处理方法的网络架构示意图；

图2是本申请实施例提供的装置的一个可选的结构示意图；

图3是本申请实施例提供的网页配置的处理方法的一种实现流程示意图；

图4A为本申请实施例获取配置属性的属性信息的实现流程示意图；

图4B为本申请实施例将React组件自动生成配置文件的示意图；

图5是本申请实施例提供的网页配置的处理方法的另一种实现流程示意图；

图6是本申请实施例提供的网页配置的处理方法的再一种实现流程示意图；

图7为本申请实施例管理后台配置界面示意图；

图8为本申请实施例配置界面自动生成的网络架构示意图；

图9为本申请实施例通过Babel进行配置属性基本信息的采集的实现过程示意图；

图10为本申请实施例采集配置属性的默认值的实现过程示意图；

图11为本申请实施例自动生成管理后台界面的实现流程示意图；

图12是本申请实施例提供的运营终端一个可选的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

React组件，是使用一个名为render()的方法，接收输入的数据并返回需要展示的内容。

JS对象简谱(JavaScript Object Notation，JSON)Schema，是基于JSON的格式规范，用于定义JSON数据的结构。JSON Schema能够用来验证和描述JSON对象结构。

JSDoc，是一个根据JavaScript文件中注释信息，生成JavaScript应用程序或库、模块的应用程序编程接口(API，Application Programming Interface)文档的工具。

抽象语法树(AST，Abstract Syntax Tree)，或简称语法树(Syntax tree)，是源代码语法结构的一种抽象表示。AST以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。

为了更好地理解本申请实施例中提供的信息处理方法，首先对相关技术中整个可运营体系的架构及存在的缺点进行说明。

图1A为相关技术中可运营体系的架构示意图，如图1A所示，在该运营体系的网络架构中包括：用户终端101、前端页面102和后台服务103、内容分发网络(CDN，ContentDelivery Network)服务器104、管理后台105。

该架构的运作流程如下：首先开发人员先开发好前端页面102和后台服务103，并将前端页面102的主文档(即图1A中的超文本标记语言(HTML，Hyper Text MarkupLanguage)文档)和后台服务103部署到服务器上，而页面的静态资源(即图1A中的JavaScript文件和层叠样式表(CSS，Cascading Style Sheets，)文件)则托管到CDN服务器，此时用户终端101可通过统一资源定位符(URL，Uniform Resource Locator)访问到页面。

其后，开发人员根据运营人员的要求将页面需要配置的部分抽离，并开发对应的管理后台界面交由运营人员使用。运营人员在管理后台105进行数据配置后，服务器会将数据通过数据库进行持久化，这样用户再次访问页面时，由于页面内含有获取配置的实时请求，此时后台服务103将运营人员配置的数据返回到用户终端101。

上述网络架构存在以下缺点：

第一，开发人员需要额外开发用于运营人员配置的管理后台图形界面，人力成本高；

第二，每次配置项需要修改，开发人员需要重新部署管理后台代码，部分场景甚至还需要开发新的配置界面，协作效率低下。

第三，运营人员在修改配置后无法进行页面效果的检验，容易出现误操作，产生运营事故。

基于此，本申请实施例提供再一种配置界面的生成方法，能够利用JSON Schema及react-JSON Schema-form组合自动生成可供配置的界面，从而免去开发人员的开发成本，并且管理后台图形界面可通过在线填写配置文件生成，进而克服了每次更新都需要重新部署的问题。

下面说明实现本申请实施例的装置的示例性应用，本申请实施例提供的装置可以实施为服务器。下面，将说明装置实施为服务器时涵盖服务器的示例性应用。

参见图1B，图1B是本申请实施例网页配置的处理方法的网络架构示意图，如图1所示，该网络架构中至少包括用户终端100、开发终端400、服务器200和运营终端300。为实现支撑一个示例性应用，用户终端100和开发终端400以及运营终端300分别通过网络500连接服务器200，网络500可以是广域网或者局域网，又或者是二者的组合，使用无线链路实现数据传输。

开发人员终端开发终端400开发能够自动生成配置文件的组件，并在开发完成之后，获取配置属性的属性信息和默认值，以自动生成配置文件，并将配置文件发送给服务器200，服务器200可以主动将配置文件发送给运营终端300，还可以是运营终端300在需要生成配置界面时从服务器200获取配置文件；在运营终端300获取到配置文件之后，即可根据转换工具将配置文件转换为相应的配置界面，以供运营人员查看并修改配置。

运营人员通过配置界面修改网页配置后，会运营终端300同步生成配置数据的数据快照，并将数据快照存储在服务器200以进行长久性存储。当用户通过用户终端100访问网页时，访问请求中包括获取配置数据的实时请求，此时服务器200将配置数据的数据快照返回到用户终端100，并基于数据快照更新网页内容并输出，以为用户提供内容质量更高的浏览体验。

本申请实施例提供的装置可以实施为硬件或者软硬件结合的方式，下面说明本申请实施例提供的装置的各种示例性实施。

参见图2，图2是本申请实施例提供的开发终端400一个可选的结构示意图，开发终端400可以是台式计算机、平板设备、笔记本电脑等。根据终端400的结构，可以预见装置实施为服务器时的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。

图2所示的开发终端400包括：至少一个处理器410、存储器440、至少一个网络接口420和用户接口430。开发终端400中的每个组件通过总线系统450耦合在一起。可理解，总线系统450用于实现这些组件之间的连接通信。总线系统450除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统450。

用户接口430可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

存储器440可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器440旨在包括任意适合类型的存储器。

本申请实施例中的存储器440能够存储数据以支持开发终端400的操作。这些数据的示例包括：用于在开发终端400上操作的任何计算机程序，如操作系统和应用程序。其中，操作系统包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序可以包含各种应用程序。

作为本申请实施例提供的方法采用软硬件结合实施的示例，本申请实施例所提供的方法可以直接体现为由处理器410执行的软件模块组合，软件模块可以位于存储介质中，存储介质位于存储器440，处理器410读取存储器440中软件模块包括的可执行指令，结合必要的硬件(例如，包括处理器410以及连接到总线450的其他组件)完成本申请实施例提供的方法。

作为示例，处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

将结合前述的实现本申请实施例的装置的示例性应用和实施，说明实现本申请实施例的方法。

参见图3，图3是本申请实施例提供的网页配置的处理方法的一种实现流程示意图，将结合图3示出的步骤进行说明。

步骤S101，开发终端对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息。

这里，开发终端可以是开发人员用户开发组件的终端，可以是台式计算机、笔记本电脑、平板设备等。待生成配置界面的组件可以是React组件。配置属性是指需要配置的属性，例如需要配置的属性可以是标题(title)、页面介绍等等。

对待生成配置界面的组件进行解析在实现时，可以是对待生成配置界面的React组件源代码进行解析，以获取所述组件中配置属性的属性信息。所述属性信息是指属性的基本信息，在本实施例中，所述属性信息至少包括属性标识和描述信息，属性标识可以为属性名。

步骤S102，开发终端基于所述属性标识，获取所述配置属性对应的取值。

这里，开发终端在获取待需要配置属性的属性名之后，可以根据属性名，从属性默认值中获取出配置属性对应的取值。在本实施例中，获取的配置属性对应的取值可以是配置属性的默认值。

步骤S103，开发终端根据所述配置属性的属性信息和所述取值生成配置文件。

这里，步骤S103在实现时，可以是开发终端通过工具将配置属性的属性信息和取值生成配置文件。举例来说，如果待生成配置界面的组件为React组件，那么步骤S103在实现时可以是利用Node js工具将配置属性的属性信息和所述取值生成配置文件。此时配置文件可以是JSON Schema文件。

步骤S104，开发终端将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

这里，运营终端可以是指运营人员对网页进行配置或调整的终端，运营终端可以是台式计算机、笔记本电脑、平板设备、智能手机等。

开发终端将配置文件提供给运营终端时，可以通以下两种方式实现：

第一种方式，开发终端将配置文件发送给服务器，由服务器将配置文件发送给运营终端。

第二种方式，开发终端将配置文件直接发送给运营终端。

当采用第一种方式实现时，开发终端与运营终端可以不建立有直接的通信连接，只要开发终端与服务器以及运营终端与服务器之间建立有直接的通信连接即可；当采用第二种方式实现时，要求开发终端与运营终端之间建立有直接的通信连接。

在运营终端获取到配置文件之后，可以通过相应的转换工具自动将配置文件转换至与配置文件的文件类型相对应的配置界面。这样，配置文件可以自动生成、配置界面可以通过转换工具自动转换生成，从而不需要开发人员再额外为运营人员开发用于运营人员配置的管理后台图形界面，降低开发成本。

在本申请实施例提供的网页配置的处理方法中，首先在对待生成配置文件的组件进行解析，获取到组件中需要配置的属性的基本信息和属性对应的取值后，可以根据配置属性的属性信息和取值自动生成配置文件，进而再将配置文件提供给运营终端，以使得运营终端能够根据配置文件自动转换为与其文件类型对应的配置界面；如此，能够实现配置界面的自动生成，从而无需开发人员额外开发配置界面，进一步降低运营体系的开发成本。

在一些实施例中，图3中示出的步骤S101可以通过步骤1011至步骤1013实现，图4A为本申请实施例获取配置属性的属性信息的实现流程示意图，下面将结合图4A对各步骤进行说明。

步骤S1011，开发终端对待生成配置界面的组件进行解析，得到具有预设数据结构的对象集合。

这里，步骤S1011在实现时，可以是开发终端利用解析工具对React组件源代码进行解析，得到抽象语法树结构对象集合。该解析工具可以是@babel/parser(解码器)，该解码器对React组件的源代码进行语法分析，生成具有语法意义的token序列(能够区分出关键字、数值、标点符号等)，接着经过语法分析，生成具有语法意义的AST，从而能够区分出语句块、注释、变量声明、函数参数等。

AST中的每个节点可以认为是一个对象。

步骤S1012，开发终端遍历所述预设数据结构的对象集合中的各个对象，基于所述各个对象的标识，确定所述组件的类属性。

这里，步骤S1012在实现时，可以是开发终端利用遍历工具(@babel/traverse)遍历AST中的各个对象，通过各个对象的标识，确定出组件的类属性，也确定出AST中对象标识为Class Property的节点。

步骤S1013，开发终端根据所述组件的类属性，至少获取所述组件中配置属性的属性标识和描述信息。

这里，步骤S1013在实现时，首先要获取具有所述类属性的属性类型信息；然后从所述属性类型信息中，获取所述组件中配置属性的属性标识和描述信息。

图4B为本申请实施例将React组件自动生成配置文件的示意图，在如图4B中401所示的React组件中，propTypes 4011、defaultProps 4012和render()4013都具有所述类属性，此时需要获取具有所述类属性的属性类型信息，也即获取矩形框4011中的属性类型信息，然后再从4011中的属性类型信息中获取到配置属性的属性标识4111和描述信息4112，其中在属性类型信息4011中属性标识为title和description。

在一些实施例中，对配置属性的取值进行采集，由于属性的取值可能是运算结果，因此不能使用抽象语法树进行静态分析后进行采集，而是需要将组件运行起来采集配置属性的取值。在实际应用过程中，可以通过以下步骤实现上述的步骤S102：

步骤S1021，利用预设脚本对所述组件进行引用，以在运行所述组件时获取组件类。

这里，步骤S1021在实现时可以是利用Nodejs脚本通过Import()函数对React组件进行引用，以运行React组件即可获取到该React组件的组件类。

步骤S1022，获取所述组件类的静态属性。

这里，在本实施例中获取的配置属性的取值是获取配置属性的默认值，由于配置属性的默认值为静态属性，从而在步骤S1022中要通过访问组件类的静态属性，从而获取默认值。

步骤S1023，基于所述属性标识，从所述组件的静态属性中获取所述需要配置的属性对应的取值。

这里，在通过访问组件类的静态属性来获取该组件类的静态属性之后，无须创建实例即可通过属性标识进行默认值查找。

如图4B所示，通过React组件401中的示出的4012可以看出，title和description的默认值都为空。

开发人员仅需要在开发React组件时，在组件中对需要配置的属性的名字、类型及是否必须配置进行描述。如果此时配置属性需要默认值，则通过defaultProps进行补充描述，在开发完组件后，即能够根据配置属性的属性信息和取值自动生成配置文件，进而可以由运营终端自动生成配置界面，而不需要开发人员再为专门开发运营人员所需的配置界面，从而降低开发成本，提高界面生成效率。

在一些实施例中，参见图5，图5是本申请实施例提供的网页配置的处理方法的另一种实现流程示意图，基于图3，在步骤104之后，还可以执行以下步骤：

步骤S105，运营终端获取开发终端生成的配置文件。

这里，与步骤S104相对应，步骤S105可以通过以下两种方式获取开发终端生成的配置文件：

第一种方式：运营终端从服务器获取开发终端生成的配置文件；

第二种方式：运营终端直接接收开发终端生成的配置文件。

在图5中，示例性地，步骤S104和步骤S105都是按照第一种方式实现，也即步骤S104为开发终端将配置文件发送给服务器，步骤S105为运营终端获取服务器发送的配置文件。

步骤S106，运营终端获取所述配置文件中各个配置属性的类型。

这里，配置属性的类型可以通过配置文件中配置属性的“Type”字段确定。

由于已知要配置的属性为title和description，那么通过图4B自动生成的配置文件402中的4021和4022可以看出，title和description对应的类型为字符串(string)。

步骤S107，运营终端根据所述各个配置属性的类型确定第一界面组件。

这里，步骤S107在实现时，根据各个配置属性的类型进行组件映射，从而挑选对应的UI组件。

步骤S108，运营终端基于所述界面组件将所述配置文件转换为对应的配置界面。

这里，步骤S108在实现时，可以是运营终端基于确定出的第一界面组件，利用预设的转换工具将所述配置文件转换为对应的配置界面，进一步地，转换工具可以是react-JSON Schema-form工具。

通过步骤S105至步骤S108，运营终端在获取到配置文件之后，可以进一步确定转换为配置界面时的界面组件，再自动将配置文件转换为对应的配置界面，如此运营人员能够在页面已发布的情况下独立完成页面内容的配置，并且配置完成后能够立即生效，高效、快捷且不需要开发人员介入。

在一些实施例中，参见图6，图6是本申请实施例提供的网页配置的处理方法的再一种实现流程示意图，基于图5，在步骤S105之后，还可以执行以下步骤：

步骤S106’，运营终端接收对所述配置文件进行编辑的第一操作。

这里，运营终端在接收到配置文件之后，运营人员可以根据运营需求对配置文件进行编辑，此时可以是对配置文件的部分内容进行编辑，还可以是对配置文件的全部内容进行编辑，在本实施例中不做限定。

步骤S107’，运营终端获取基于所述第一操作得到的更新后的配置文件，并根据更新后的配置文件确定第二界面组件。

这里，运营终端在获取到更新后的配置文件后，获取更新后的配置文件中各个配置属性的类型，进而根据更新后的配置文件中各个配置属性的类型确定第二界面组件。

步骤S108’，运营终端基于第二界面组件将所述更新后的配置文件转换为对应的配置界面。

这里，步骤S108’在实现时，可以是运营终端基于确定出的第一界面组件，利用预设的转换工具将所述配置文件转换为对应的配置界面，进一步地，转换工具可以是react-JSON Schema-form工具。

步骤S109，运营终端接收通过所述配置界面对属性进行配置的第二操作。

这里，在运营终端输出自动生成的配置界面之后，运营人员可以通过执行第二操作对配置界面中的配置属性进行配置，运营终端接收该第二操作。

步骤S110，运营终端获取基于所述第二操作得到的更新后的配置界面。

这里，运营终端会基于第二操作，对相应的配置属性进行更新，得到更新后的配置界面。

步骤S111，运营终端基于所述更新后的配置界面生成数据快照。

这里，为了能够使得用户能够在访问页面时呈现给用户最新的页面内容，以及能够使得运营人员便捷地对页面效果进行验证，因此在运营人员更新配置界面后，会生成数据快照。

步骤S112，运营终端将所述数据快照存储至服务器，以使得网页根据所述数据快照对网页内容进行更新。

这里，运营终端将数据快照存储至服务器进行持久化存储。当用户再次访问之前访问过的网页，就能通过实时请求来拉取最新的配置数据，从而完成运营数据的实时更新。

需要说明的是，步骤S109至步骤S112还可以在图5所示的步骤S108之后执行，在本实施例中不做限定。

在一些实施例中，在步骤S112之后，还可以执行一些步骤：

步骤S113，运营终端加载与所述数据快照对应的网页。

步骤S114，运营终端输出基于所述数据快照进行内容更新的网页，以对配置数据的页面效果进行验证。

这里，运营人员通过运营终端中的配置界面对一些属性进行配置之后，可以通过同步生成的数据快照对配置数据的正确性及页面效果进行验证。在生成数据快照之后，还可以存储在运营终端本地，或者当数据快照仅存储在服务器时，运营终端从服务器获取数据快照，并加载对应的网页，从而通过输出的进行内容更新后的网页来验证配置数据的正确性及页面效果。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。在本实施例中以通过React组件生成JSON Schema文件，进而再通过JSON Schem-a文件自动生成配置界面为例进行说明。

为了实现自动生成配置界面，开发人员在开发React组件时，首先在React组件中对需要配置的属性通过JSDoc和propTypes的组合进行名字、类型及是否必须配置进行描述。如果配置属性需要默认值，则可以通过defaultProps进行补充描述。在React组件开发完成后，通过Nodejs工具将配置属性的相关描述转换成JSON Schema文件。

在得到了关于React组件中需要配置的JSON Schema描述文件之后，就能通过react-jsonschema-form工具自动生成对应的管理后台图形用户界面(GUI，GraphicalUser Interface)界面。图7为本申请实施例管理后台配置界面示意图，如图7所示，通过JSON Schema文件701可以生成702所示的GUI界面，运营人员可以通过该GUI界面702进行属性的配置，并且在运营人员对属性进行配置后，该GUI界面会同时生成一份数据快照703，页面在获取到数据快照后会进行页面内容的更新，运营人员可通过这种手段对配置数据的正确性及页面效果进行验证。

在运营人员对需要配置的属性配置完成后，运营管理后台会将数据快照保存到服务器进行持久化存储，此时用户再次访问之前访问过的页面时，就能通过实时请求来拉取最新的配置数据，从而完成运营数据的实时更新。

图8为本申请实施例配置界面自动生成的网络架构示意图，如图8所示，所述网络架构中至少包括：用户终端801，CDN服务器802，管理后台803，后台服务器804和前端开发终端中的网页文件805，其中网页文件805中的HTML文件存储在后台服务器804，Javascript文件和CSS文件可认为是静态资源，可存储在CDN服务器802。前端开发终端可以通过React组件自动生成JSONSchema文件，进而将JSON Schema文件发送给管理后台803，管理后台803在获取到JSON Schema文件后可生成属性配置界面，以供运营人员通过属性配置界面对网页的属性进行配置，管理后台803和后台服务器804之间建立有通信连接，以将运营人员在对属性进行配置后生成的数据快照传输至后台服务器804。

以下结合图8所示的网络架构，对前端开发终端可通过工具自动生成React组件对应的JSON Schema，并且进一步通过JSON Schema自动生成对应的管理后台GUI界面的实现过程进行说明。

首先，对自动生成React组件配置对应的JSON Schema文件的实现过程进行说明。自动生成的JSON Schema文件由两部分组成，第一部分是配置属性的基本信息，如属性名、描述等。第二部分是配置属性的默认值。

图9为本申请实施例通过Babel进行配置属性基本信息的采集的实现过程示意图，如图9所示，首先通过@babel/parser对React组件901源代码进行解析，解析产物为具有一定结构的Javascript对象，也即抽象语法树902，该抽象语法数的具体结构如903所示。在得到这个抽象语法树之后，再通过babel-traverse工具进行节点遍历，确定采集的类型为类属性(ClassProperty)，这个类型事实上就是React组件类的属性。进而再对名为propTypes的ClassProperty加以分析，就能采集出配置属性的基本信息904。

在采集到配置属性的基本信息后，需要对配置属性的默认值进行采集，由于属性值可能是运算结果，因此在实现过程中不能使用抽象语法树进行静态分析后进行采集。图10为本申请实施例采集配置属性的默认值的实现过程示意图，如图10所示，使用一个Nodejs脚本1001对React组件1002进行引用，运行时即可获取到该React组件类，而由于defaultProps为静态属性，所以无须创建实例，通过访问类静态属性1003即可查找出属性名对应的默认值1004。

其次，对自动生成管理后台的界面的实现过程进行说明。图11为本申请实施例自动生成管理后台界面的实现流程示意图，如图11所示，只需要在管理后台1101输入需配置页面(组件)生成的JSON Schema文件1102，含有react-JSON Schema-form工具1103的管理后台就会根据JSON schema文件中配置属性的类型进行组件映射，从而挑选对应的UI组件以生成可供运营人员使用的GUI界面1104。

需要说明的是，在本申请实施例中使用react-JSON Schema-form作为自动生成GUI界面的工具仅为示例性说明，实际上，使用其他基于JSON Schema的UI框架也可以自动生成界面。因此，在本实施例中不具体限定生成GUI界面的工具，本实施例中自动生成GUI界面的部分亦可替换为各种其他新颖的UI框架。

本申请实施例提供一种自动生成运营平台配置界面的方案，可以使运营人员在页面已发布的情况下独立完成页面内容的配置，并且配置完成后能够立即生效，高效、快捷且不需要开发人员介入。此外，开发人员无须额外开发配置界面，在需配置内容发生改动的情况下，运营也可以通过填写新的JSON Schema文件获取新的GUI配置界面，大大节省了开发人员的开发成本，同时优化并减少了运营体系开发成本。

下面说明软件模块的示例性结构，在一些实施例中，如图2所示，装置440中的软件模块可以包括：

解析模块81，用于对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；

第一获取模块82，用于基于所述属性标识，获取所述配置属性对应的取值；

第一生成模块83，用于根据所述配置属性的属性信息和所述取值生成配置文件；

文件传输模块84，用于将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

在上述方案中，解析模块81还用于：

对待生成配置界面的组件进行解析，得到具有预设数据结构的对象集合；

遍历所述预设数据结构的对象集合中的各个对象，基于所述各个对象的标识，确定所述组件的类属性；

根据所述组件的类属性，至少获取所述组件中配置属性的属性标识和描述信息。

在上述方案中，所述解析模块81还用于：

获取具有所述类属性的属性类型信息；

从所述属性类型信息中，获取所述组件中配置属性的属性标识和描述信息。

在上述方案中，所述第一获取模块82还用于：

利用预设脚本对所述组件进行引用，以在运行所述组件时获取组件类；

获取所述组件类的静态属性；

基于所述属性标识，从所述组件的静态属性中获取所述需要配置的属性对应的取值。

作为本申请实施例提供的方法采用硬件实施的示例，本申请实施例所提供的方法可以直接采用硬件译码处理器形式的处理器410来执行完成，例如，被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex ProgrammableLogic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件执行实现本申请实施例提供的方法。

参见图12，图12是本申请实施例提供的运营终端300一个可选的结构示意图，开发终端300可以是台式计算机、平板设备、笔记本电脑、移动手机等。根据运营终端300的结构，可以预见装置实施为服务器时的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。

图12所示的运营终端300包括：至少一个处理器310、存储器340、至少一个网络接口320和用户接口330。运营终端300中的每个组件通过总线系统350耦合在一起。可理解，总线系统350用于实现这些组件之间的连接通信。总线系统350除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图12中将各种总线都标为总线系统350。

用户接口330可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。

存储器340可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，ReadOnly Memory)。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器340旨在包括任意适合类型的存储器。

作为本申请实施例提供的方法采用软硬件结合实施的示例，本申请实施例所提供的方法可以直接体现为由处理器310执行的软件模块组合，软件模块可以位于存储介质中，存储介质位于存储器340，处理器310读取存储器340中软件模块包括的可执行指令，结合必要的硬件(例如，包括处理器310以及连接到总线350的其他组件)完成本申请实施例提供的方法。

作为示例，处理器310可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

下面说明软件模块的示例性结构，在一些实施例中，如图12所示，装置340中的软件模块可以包括：

第二获取模块91，用于获取开发终端生成的配置文件；

第三获取模块92，用于获取所述配置文件中各个配置属性的类型；

第一确定模块93，用于根据所述各个配置属性的类型确定第一界面组件；

第一转换模块94，用于基于所述第一界面组件将所述配置文件转换为对应的配置界面。

在上述方案中，所述装置还包括：

第一接收模块，用于接收对所述配置文件进行编辑的第一操作；

第四获取模块，用于获取基于所述第一操作得到的更新后的配置文件，并获取所述更新后的配置文件中各个配置属性的类型；

第二确定模块，用于根据更新后的配置文件中各个配置属性的类型确定第二界面组件；

第二转换模块，用于基于所述第二界面组件将所述更新后的配置文件转换为对应的配置界面。

在上述方案中，所述装置还包括：

第二接收模块，用于接收通过所述配置界面对属性进行配置的第二操作；

第五获取模块，用于获取基于所述第二操作得到的更新后的配置界面；

第二生成模块，用于基于所述更新后的配置界面生成数据快照；

存储模块，用于将所述数据快照存储至服务器，以使得网页根据所述数据快照对网页内容进行更新。

在上述方案中，所述装置还包括：

加载模块，用于加载与所述数据快照对应的网页；

输出模块，用于输出基于所述数据快照进行内容更新的网页，以对配置数据的页面效果进行验证。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图3、图4A、图5及图6示出的方法。

在一些实施例中，存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，通过本申请实施例，能够自动生成管理后台图形界面的配置文件，并且进一步自动生成管理后台图形界面，无须开发人员额外开发，从而降低了开发成本；并且运营管理后台的图形界面可通过在线填写配置文件生成，克服了每次更新都需要重新部署的问题；运营人员在管理后台修改配置后可立即查看页面应用效果，进而能够协助运营人员快速、准确、高效地完成配置修改。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种网页配置的处理方法，其特征在于，所述方法包括：

对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；

基于所述属性标识，获取所述配置属性对应的取值；

根据所述配置属性的属性信息和所述取值生成配置文件；

将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

2.根据权利要求1中所述的方法，其特征在于，所述对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，包括：

对待生成配置界面的组件进行解析，得到具有预设数据结构的对象集合；

遍历所述预设数据结构的对象集合中的各个对象，基于所述各个对象的标识，确定所述组件的类属性；

根据所述组件的类属性，至少获取所述组件中配置属性的属性标识和描述信息。

3.根据权利要求2中所述的方法，其特征在于，所述根据所述组件的类属性，至少获取所述组件中配置属性的属性标识和描述信息，包括：

获取具有所述类属性的属性类型信息；

从所述属性类型信息中，获取所述组件中配置属性的属性标识和描述信息。

4.根据权利要求1中所述的方法，其特征在于，所述基于所述属性标识，获取所述配置属性对应的取值，包括：

利用预设脚本对所述组件进行引用，以在运行所述组件时获取组件类；

获取所述组件类的静态属性；

基于所述属性标识，从所述组件的静态属性中获取所述需要配置的属性对应的取值。

5.一种网页配置的处理方法，其特征在于，所述方法包括：

获取开发终端生成的配置文件；

获取所述配置文件中各个配置属性的类型；

根据所述各个配置属性的类型确定第一界面组件；

基于所述第一界面组件将所述配置文件转换为对应的配置界面。

6.根据权利要求5中所述的方法，其特征在于，所述方法还包括：

接收对所述配置文件进行编辑的第一操作；

获取基于所述第一操作得到的更新后的配置文件，并获取更新后的配置文件中各个配置属性的类型；

根据更新后的配置文件中各个配置属性的类型确定第二界面组件；

基于所述第二界面组件将所述更新后的配置文件转换为对应的配置界面。

7.根据权利要求5中所述的方法，其特征在于，所述方法还包括：

接收通过所述配置界面对属性进行配置的第二操作；

获取基于所述第二操作得到的更新后的配置界面；

基于所述更新后的配置界面生成数据快照；

将所述数据快照存储至服务器，以使得网页根据所述数据快照对网页内容进行更新。

8.根据权利要求7中所述的方法，其特征在于，所述方法还包括：

加载与所述数据快照对应的网页；

输出基于所述数据快照进行内容更新的网页，以对配置数据的页面效果进行验证。

9.一种网页配置的处理装置，其特征在于，包括：

解析模块，用于对待生成配置界面的组件进行解析，获取所述组件中配置属性的属性信息，所述属性信息至少包括属性标识和描述信息；

第一获取模块，用于基于所述属性标识，获取所述配置属性对应的取值；

第一生成模块，用于根据所述配置属性的属性信息和所述取值生成配置文件；

文件传输模块，用于将所述配置文件提供给运营终端，以使得运营终端将所述配置文件转换为对应的配置界面。

10.一种网页配置的处理方法，其特征在于，所述装置包括：

第二获取模块，用于获取开发终端生成的配置文件；

第三获取模块，用于获取所述配置文件中各个配置属性的类型；

第一确定模块，用于根据所述各个配置属性的类型确定第一界面组件；

第一转换模块，用于基于所述第一界面组件将所述配置文件转换为对应的配置界面。

Images