CN114036425A

CN114036425A - 页面访问方法、客户端、服务端及***

Info

Publication number: CN114036425A
Application number: CN202111408032.1A
Authority: CN
Inventors: 赵馨昳
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2021-11-24
Filing date: 2021-11-24
Publication date: 2022-02-11

Abstract

本申请提供了页面访问方法、客户端、服务端及***。该页面访问方法包括：向服务端发送页面访问请求，页面访问请求携带待访问页面的页面标识；接收服务端返回的待访问页面的页面结构信息，页面结构信息为服务端基于页面标识查找页面表和组件表得到，页面表记录有页面标识与页面信息的对应关系，组件表记录有组件标识与组件信息的对应关系；解析页面结构信息，获得目标页面信息和目标组件信息；基于目标页面信息和目标组件信息，渲染得到待访问页面。如此，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

Description

页面访问方法、客户端、服务端及***

技术领域

本申请涉及信息处理技术领域，特别涉及页面访问方法。本申请同时涉及客户端、服务端、页面访问***、计算设备、以及计算机可读存储介质。

背景技术

随着互联网的发展，越来越多的用户选择在线办理业务或浏览信息，而在线办理业务或浏览信息均需要访问相应的网站或应用程序的页面。

现有技术中，当用户打开相关页面时，客户端会从服务端获取到该页面的相关信息，然后根据获取到的信息渲染得到该页面并展示给用户，以使用户进行业务办理或信息浏览。但通常情况下，前端页面开发需要跟随发版周期更新，由于发版时间的规范性和固定性，就造成一次页面的更新周期比较长，在此期间进行页面访问，展示的页面可能不符合访问需求。因此，亟需一种页面访问方法解决上述问题。

发明内容

有鉴于此，本申请实施例提供了页面访问方法。本申请同时涉及客户端、服务端、页面访问***、一种计算设备，以及计算机可读存储介质，以解决现有技术中存在的页面更新周期长，导致访问的页面不符合访问需求的问题。

根据本申请实施例的第一方面，提供了一种页面访问方法，应用于客户端，该方法包括：

向服务端发送页面访问请求，所述页面访问请求携带待访问页面的页面标识；

接收所述服务端返回的所述待访问页面的页面结构信息，所述页面结构信息为所述服务端基于所述页面标识查找页面表和组件表得到，所述页面表记录有页面标识与页面信息的对应关系，所述组件表记录有组件标识与组件信息的对应关系；

解析所述页面结构信息，获得目标页面信息和目标组件信息；

基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面。

根据本申请实施例的第二方面，提供了另一种页面访问方法，应用于服务端，该方法包括：

接收客户端发送的页面访问请求，所述页面访问请求携带待访问页面的页面标识；

根据所述页面标识，从页面表中查找所述待访问页面对应的目标页面信息，所述页面表记录有页面标识与页面信息的对应关系，所述页面信息包括组件标识；

读取所述目标页面信息中的目标组件标识，根据所述目标组件标识，从组件表中查找所述目标组件标识对应的目标组件信息，所述组件表记录有组件标识与组件信息的对应关系；

对所述目标页面信息和所述目标组件信息进行拼接，获得页面结构信息，将所述页面结构信息返回至所述客户端，所述页面结构信息用于所述客户端渲染得到所述待访问页面。

根据本申请实施例的第三方面，提供了一种客户端，包括：

发送模块，被配置为向服务端发送页面访问请求，所述页面访问请求携带待访问页面的页面标识；

第一接收模块，被配置为接收所述服务端返回的所述待访问页面的页面结构信息，所述页面结构信息为所述服务端基于所述页面标识查找页面表和组件表得到，所述页面表记录有页面标识与页面信息的对应关系，所述组件表记录有组件标识与组件信息的对应关系；

解析模块，被配置为解析所述页面结构信息，获得目标页面信息和目标组件信息；

渲染模块，被配置为基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面。

根据本申请实施例的第四方面，提供了一种服务端，包括：

第二接收模块，被配置为接收客户端发送的页面访问请求，所述页面访问请求携带待访问页面的页面标识；

第一查找模块，被配置为根据所述页面标识，从页面表中查找所述待访问页面对应的目标页面信息，所述页面表记录有页面标识与页面信息的对应关系，所述页面信息包括组件标识；

第二查找模块，被配置为读取所述目标页面信息中的目标组件标识，根据所述目标组件标识，从组件表中查找所述目标组件标识对应的目标组件信息，所述组件表记录有组件标识与组件信息的对应关系；

拼接模块，被配置为对所述目标页面信息和所述目标组件信息进行拼接，获得页面结构信息，将所述页面结构信息返回至所述客户端，所述页面结构信息用于所述客户端渲染得到所述待访问页面。

根据本申请实施例的第五方面，提供了一种页面访问***，该页面访问***包括客户端和服务端；

所述客户端向服务端发送页面访问请求，所述页面访问请求携带待访问页面的页面标识；

所述服务端接收客户端发送的页面访问请求，所述页面访问请求携带待访问页面的页面标识；根据所述页面标识，从页面表中查找所述待访问页面对应的目标页面信息，所述页面表记录有页面标识与页面信息的对应关系，所述页面信息包括组件标识；读取所述目标页面信息中的目标组件标识，根据所述目标组件标识，从组件表中查找所述目标组件标识对应的目标组件信息，所述组件表记录有组件标识与组件信息的对应关系；对所述目标页面信息和所述目标组件信息进行拼接，获得页面结构信息，将所述页面结构信息返回至所述客户端，所述页面结构信息用于所述客户端渲染得到所述待访问页面；

所述客户端接收所述服务端返回的所述待访问页面的页面结构信息，所述页面结构信息为所述服务端基于所述页面标识查找页面表和组件表得到，所述页面表记录有页面标识与页面信息的对应关系，所述组件表记录有组件标识与组件信息的对应关系；解析所述页面结构信息，获得目标页面信息和目标组件信息；基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面。

根据本申请实施例的第六方面，提供了一种计算设备，包括：存储器和处理器；

存储器用于存储计算机可执行指令，处理器用于执行计算机可执行指令，以实现上述任一页面访问方法的步骤。

根据本申请实施例的第七方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述任一页面访问方法的步骤。

本申请提供的应用于客户端的页面访问方法，向服务端发送页面访问请求，该页面访问请求携带待访问页面的页面标识；接收服务端返回的待访问页面的页面结构信息，该页面结构信息为服务端基于页面标识查找页面表和组件表得到，该页面表记录有页面标识与页面信息的对应关系，该组件表记录有组件标识与组件信息的对应关系；解析页面结构信息，获得目标页面信息和目标组件信息；基于目标页面信息和目标组件信息，渲染得到待访问页面。上述方法将客户端的页面展示和服务端的信息存储联动起来，在进行页面访问时，客户端可以从服务端获取页面信息和组件信息，并根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

附图说明

图1是本申请一实施例提供的一种应用于客户端的页面访问方法的流程图；

图2是本申请一实施例提供的一种待访问页面的示意图；

图3a是本申请一实施例提供的一种拆解组件底层数据的示意图；

图3b是本申请一实施例提供的一种触发事件后执行的操作的示意图；

图4是本申请一实施例提供的一种应用于服务端的页面访问方法的流程图；

图5是本申请一实施例提供的一种页面访问方法的示意图；

图6是本申请一实施例提供的一种客户端的结构示意图；

图7是本申请一实施例提供的一种服务端的结构示意图；

图8是本申请一实施例提供的一种计算设备的结构框图；

图9是本申请一实施例提供的一种页面访问***的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本申请实施例涉及到的名词术语进行解释说明。

JSON(Java Script Object Notation，JavaScript对象简谱)：利用JS的语法来描述数据对象，是一种轻量级的数据交换格式。

JSON-SCHEMA(Java Script Object Notation，JavaScript对象简谱模式)：是用来定义JSON数据约束的一个标准。根据这个约定模式，交换数据的双方可以理解JSON数据的要求和约束，也可以据此对数据进行验证，保证数据交换的正确性。

渲染：是将后端的一系列数据转换为人眼可见的页面的过程。本申请的页面渲染包括，先根据页面信息渲染得到页面结构，然后根据底层数据和基准组件数据在页面结构上渲染得到基准组件，再根据组件属性结构信息对基准组件进行调整，得到渲染完成的页面。

页面结构信息：包括整个页面的所有信息，通过该页面结构信息可以描述一个完整的页面。在本申请实施例中，页面结构信息可以是一种数据结构，该数据结构中包括描述页面的信息。

页面信息：页面层面的信息，可以用来描述页面整体的结构。

组件信息：组件层面的信息，包括页面中所有组件的信息，可以用来描述页面中的组件。

组件属性结构信息：是组件信息中用于描述组件的属性和结构的信息。例如，组件属性结构信息可以包括组件的样式尺寸、组件在页面中的位置信息等。

组件底层数据：是组件信息中描述组件底层的数据类型的数据。

数据类型：JSON-SCHEMA定义的JSON数据的数据类型。

组件格式：可以认为是预先存储的模板组件的格式，且组件格式不同，组件能够实现的功能不同。模板组件可以是预先设置的一些比较基础的组件。

基准组件数据：可以认为是模板组件的模板数据，该模板数据用来描述模板组件的组件属性。

基准组件：可以认为是渲染出来的模板组件。

第一事件：组件之间转换对应的事件。如组件A被触发则显示组件B属于第一事件。

第二事件：单个组件被触发对应的事件。如组件A被触发可以加载数据或提交页面属于第二事件。

事件类型：第二事件的事件类型，包括加载类和提交类。加载类事件需要加载数据，提交类事件不需要加载数据直接提交信息即可。

嵌套型：一种复杂的数据类型，该种数据类型中嵌套有简单的子数据类型。如object类型的数据包含两个string类型的数据，则object类型是嵌套型。

Event Bus：vue框架中用于集中处理事件的元素，vue是一套用于构建用户界面的渐进式JavaScript框架。

接下来，对本申请的应用场景进行简单说明。

需要说明的是，现有的前端页面开发，特别是企业内部前端页面，存在以下特点：内部前端页面大多仅用于展示和修改数据，页面结构比较简单，不需要多余的样式修饰，因此花费大量时间在开发该类简单页面中，容易造成人力物力浪费的现象。

一般面对这类页面时，主要存在以下几种开发方案：

第一种：分出专业人手负责开发和维护。这种方案相对来说灵活性较高，能够同时应付一些复杂的页面，但从整体性而言技术含量低，一直编写这种技术含量比较低的代码，对开发人员个人能力的提升没有任何帮助。并且当遇到功能重复的页面时，一样需要开发人员从零开始编写，劳动重复率高。

第二种：采用将功能组件化的方法维护。该种方法总结出简单页面的一些共性，例如将数据展示和修改需要用到的表格组件单独抽离，采用传递参数的方式，每次仅需要规范数据格式即可，提高了页面的复用性。但组件化也需要人员开发，没有从根本上解决问题，且对于有特定需求的页面，如需要实现一些复杂功能，仅通过上述通过传递参数规范数据格式的方式可能无法实现，因此该种方式不能满足特定需求。

同时，这两种方法还存在共同的问题：前端页面的集成性比较高，为了不影响同页面中其他功能的使用，前端需要进行发版，跟着版本进度周期性地进行更新。由于发版时间的规范性和固定性，就造成一次页面的更新周期耗时较长，对于一个简单功能的修改，可能需要等待2-3天的时间。

为此，本申请提供了一种页面访问方法，能够解决上述问题，该方法的具体实现可以参见下述各个实施例。

在本申请中，提供了页面访问方法，本申请同时还提供了一种客户端、一种服务端、一种页面访问***、一种计算设备，以及计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1是根据本申请一实施例提供的一种应用于客户端的页面访问方法的流程图，具体包括以下步骤：

步骤102：向服务端发送页面访问请求，页面访问请求携带待访问页面的页面标识。

其中，页面标识可以是能够唯一指示一个页面的标识。该页面标识可以是数字、字母、符号等任意字符的组合。

由于服务端预先存储有页面的页面结构信息，可以存储在页面表和组件表中，因此，客户端在接收到用户针对待访问页面的访问操作后，会向服务端发送页面访问请求，以请求服务端返回该待访问页面的页面结构信息。

进一步地，在向服务端发送页面访问请求的步骤之前，还包括：获取用户在待配置页面拖选组件后生成的待配置页面的页面信息和组件信息；将待配置页面的页面标识、页面信息和组件信息发送至服务端，以对应存储至页面表和组件表。

在本实施例中，在客户端向服务端发送页面访问请求之前，用户可以通过拖拽客户端展示的待配置页面上的组件，对该待配置页面进行配置，为了在后续访问页面时能够获取到最新的页面，客户端可以将用户在待配置页面拖选组件后生成的待配置页面的页面信息和组件信息，以及该待配置页面的页面标识发送至服务端。服务端获取到客户端发送的这些信息后，可以将页面标识和页面信息对应存储在页面表中，将页面信息中的组件标识和组件信息对应存储在组件表中。因此，客户端可以向服务端发送页面访问请求，该页面访问请求中携带页面标识，则服务端可以基于该页面标识反馈待访问页面的页面信息和组件信息给客户端。

在一些实施例中，本方案将JSON-SCHEMA可规范JSON格式的属性应用到组件规范中，在客户端生成页面信息和组件信息时，将页面信息和组件信息简化为JSON数据发送至服务端存储。

在本实施例中，一个前端页面的结构并非随性定义而成，需要有一定的约束和规范。不能仅凭简单的key-value的格式就描述出一个拥有几十个组件和CSS(CascadingStyle Sheets，层叠样式表)样式的复杂页面，更何况大多数时候，组件之间还存在嵌套等复杂关系。同时，考虑到后端存储的问题，该数据结构也应该是高效的。本实施例中的数据结构，即利用一个有特定规则的结构体来描述一个页面的所有属性，假设该页面由不同的组件拼接嵌套而成，因此结构体需要包括但不限于：组件名称，组件属性，组件内数据类型，组件内数据格式，组件UI(User Interface，用户界面)属性等不同的字段。假设一个对象即为一个组件，在实际应用中，还可能存在组件之间嵌套的关系，总结以上多种特性，选用了JSON-SCHEMA这种已有的规范来生成页面信息和组件信息。

例如，表1是部分JSON-SCHEMA字段的说明：

表1部分JSON-SCHEMA字段

从上表可以看到，JSON-SCHEMA本身的语法已经涵盖了许多生成页面时所需要的规则。例如，当需要利用代码生成一个可进行单选和多选的组件时，则可直接利用enum属性进行规范。而在提交一个表单时，type字段则轻易地帮助约束了提交数据的类型，不需要再手写多余的代码进行校验。

作为一种示例，页面对应的JSON数据格式可以如下所示：

作为一种示例，在配置页面的过程中，规范了描述页面的JSON数据之后，需要将JSON数据与前端渲染出的组件进行一一映射。本申请根据现有的前端开发框架多且规则不易的现状，抽离出了核心功能组件，利用配置文件来完成从核心组件到框架组件的映射。核心功能组件是标识输入框的input组件，原生的js中也有这类组件，但是在实际应用的时候，使用elementui iview等框架，这种框架在数值特性上可能与原生有不同(如有更多prop字段，可以更快定义属性等，在数据处理方面，举个例子，iview的input number组件会把undefined值处理成0)。然后核心功能组件到框架组件的映射其实就是维护了一个js文件，里面有一个map，可以进行修改，方便复用到其他框架。

本方案通过前端页面配置和后端信息存储进行联动，利用JSON-SCHEMA对后端存储的页面信息和组件信息进行规范，在前端根据需求动态生成页面，达到利用可视化界面(低代码乃至无代码)，使得前端页面可达到实时编辑的效果，且将编辑后前端页面的页面信息和组件信息实时发送至服务端存储的效果。如此无需用户编写大量代码，也无需跟随发版周期，且客户端展示的待访问页面完全由服务端返回的页面结构信息生成，即每次访问页面时，后端发送给前端的都是最新的页面结构信息，则可以减少访问的页面不符合访问需求的情况出现，且前端能够实时根据需求动态生成页面，进一步避免了访问的页面不符合访问需求的情况，提升了而用户的使用体验，进而能够提高用户粘性。

需要说明的是，本申请中描述的前端可以是客户端，后端可以是服务端。

步骤104：接收服务端返回的待访问页面的页面结构信息，页面结构信息为服务端基于页面标识查找页面表和组件表得到，页面表记录有页面标识与页面信息的对应关系，组件表记录有组件标识与组件信息的对应关系。

在本实施例中，服务端中存储有预先配置好的页面对应的页面表和组件表，该页面表中包括页面信息，组件表中包括组件信息，接收到客户端发送的页面访问请求后，服务端可以根据页面访问请求中携带的页面标识从页面表中查找得到页面信息，然后根据页面信息中的组件标识查找得到组件信息，再将页面信息和组件信息作为页面结构信息发送至客户端，则客户端会接收到服务端发送的待访问页面的页面结构信息。

作为一种示例，页面信息中包括content字段，且该content字段可以是组件标识。或者，该content字段中可以包括该待访问页面中按照顺序排列的组件的组件标识。

在一些实施例中，页面表中包括页面标识和页面信息，且页面标识和页面信息是对应的，页面信息可以包括页面所属的业务类型、页面包含的组件标识和顺序、页面布局属性、页脚属性等。

示例性地，参见表2，表2是一种示例性的页面表。例如，假设页面访问请求携带的页面标识是页面A，则服务端接收到该页面访问请求后，可以从页面表中查找与页面A对应的页面信息，则获取到的页面信息包括业务类型A、页面A包含的组件标识和顺序、页面布局属性A、页脚属性A等。

表2页面表

在一些实施例中，组件表主要描述组件类型、数据格式、UI属性、组件对应的事件信息等，这些信息与组件标识是对应的。并且，组件对应的事件信息可以包括组件之间的第一事件信息和组件自身的第二事件信息。组件之间的第一事件信息可携带有接收组件的组件标识。组件自身的第二事件信息包括第二事件的类型。

示例性地，参见表3，表3是一种示例性的组件表。例如，假设服务端从页面表中查找到与页面A对应的页面信息中包括组件A和组件B，则服务端从组件表中查找到组件A对应的组件信息，包括组件类型A、组件的样式尺寸A、组件在页面中的位置A、数据格式A、UI属性A、组件对应的事件信息A等，以及查找到组件B对应的组件信息，包括组件类型B、组件的样式尺寸B、组件在页面中的位置B、数据格式B、UI属性B、组件对应的事件信息B等。

表3组件表

在本实施例中，JSON数据是前后端交互、或者后端服务之间通信时用到的一种通用数据结构。很多时候，需要对JSON数据进行校验，例如，某些值为数字的字段必须在一个区间范围内(学号必须大于0)；某些字段取值必须在枚举范围内(网络协议：TCP或者UDP)；某两个字段直接必须存在依赖关系，不能单独存在(提交购物信息时，只有填写了credit_card字段，billing_address字段才有意义)。如果在用户代码里自定义这些规则，那么会导致代码臃肿，且不同开发者定义规则的形式不同，也会造成代码之间相互判断逻辑出错，因此，本申请采用用于规范JSON校验的JSON-SCHEMA格式规范页面信息和组件信息。

在本申请实施例中，页面结构信息可以是JSON SCHEMA格式的数据信息，页面信息和组件信息可以是JSON数据，如此能够对存储的信息进行规范，规范化地存储便于后续查找，即提高了信息查找的效率。

步骤106：解析页面结构信息，获得目标页面信息和目标组件信息。

其中，目标页面信息是待访问页面的页面信息，目标组件信息是待访问页面中组件的组件信息。

根据上述步骤可知，页面结构信息是由页面信息和组件信息组成的，并且，页面结构信息中页面信息可以携带有页面信息的标识，组件信息可以携带有组件信息的标识，以便于客户端可以根据页面信息的标识和组件信息的标识将页面结构信息中的页面信息和组件信息区分开来，即通过对页面结构信息进行解析，能够得到待访问页面对应的目标页面信息和目标组件信息。

在实施中，为了使得存储的信息规范化，本申请的页面结构信息可以是JSONSCHEMA格式的数据信息，目标页面信息和目标组件信息为JSON数据。

也即是，客户端在配置页面时，根据用户拖拽组件生成的配置页面的组件信息和页面信息都是JSON数据，则服务端存储的页面结构信息是JSON SCHEMA格式的数据信息，如此能够对存储的信息进行规范，且规范化地存储便于解析处理，即提高了信息解析的效率。

本申请实施例中的页面结构信息可以理解为一种数据结构，解析页面结构信息则是对数据结构进行解析。该数据结构中可以包括目标页面信息和目标组件信息，先确定该数据结构中描述页面的字段和描述组件的字段，然后根据描述页面的字段确定页面信息以及根据描述组件的字段确定组件信息，如此便可以确定页面信息和组件信息。

示例性地，数据结构可以是JSON SCHEMA结构，描述页面的字段可以是page_name，描述组件的字段可以是component n。

例如，假设页面结构信息如下所示：

可以先确定描述页面的字段page_name，描述组件的字段component1和component2，然后将page_name和component1之间的字段(包括page_name)确定为页面信息，将component1和component2之间的字段(包括component1)确定为组件1的组件信息，将component2之后的字段(包括component2)确定为组件2的组件信息。如此，便可以解析得到目标页面信息和目标组件信息。

步骤108：基于目标页面信息和目标组件信息，渲染得到待访问页面。

在本实施例中，目标页面信息包括页面结构或布局等信息，目标组件信息包括组件属性信息和组件底层数据，则可以先根据目标页面信息将页面结构渲染出来，然后根据组件底层数据确定基准组件数据，再在渲染后的页面结构中渲染得到包括底层数据的第一基准组件，最后根据组件属性信息对第一基准组件进行调整，如此便可得到待访问页面。

作为一种示例，通过本申请的解析方式解析得到目标页面信息和目标组件信息后，可以将目标页面信息和目标组件信息作为页面渲染使用的参数，通过现有的渲染工具渲染得到待访问页面。

在实际应用中，目标组件信息可以包括组件属性结构信息和组件底层数据。基于目标页面信息和目标组件信息，渲染得到待访问页面的步骤的具体实现可以包括：基于目标页面信息，对待访问页面的页面结构进行渲染；根据组件底层数据，确定组件底层数据的第一数据类型；根据第一数据类型，确定第一数据类型对应的第一组件格式；基于第一组件格式，确定第一组件格式对应的第一基准组件数据；根据第一数据类型和第一基准组件数据，在渲染后的页面结构中，对待访问页面中的第一基准组件以及第一基准组件的组件底层数据进行渲染；根据组件属性结构信息，调整渲染后的第一基准组件。

在本申请实施例中，组件属性结构信息可以是View component层中用于对组件的属性等进行调整的信息，数据类型可以是field层中处理的数据的类型，组件格式可以是Widget层中模板组件的格式。

作为一种示例，组件属性结构信息用于描述组件的结构和属性方面的信息。示例性地，组件属性结构信息可以包括组件类型、组件的样式尺寸、组件在页面中的位置、组件的UI属性、组件对应的事件信息等。组件底层数据可以是渲染得到组件时需要用到的底层数据。

在一些实施例中，目标页面信息可以包括待访问页面的业务类型和页面布局属性，客户端可以根据待访问页面的业务类型确定待访问页面对应的页面框架，然后根据页面布局属性确定页面框架中每个区域的作用，渲染得到待访问页面的页面结构。

示例性地，参见图2，图2是根据本申请一实施例提供的一种待访问页面的示意图。在图2的页面中，左边部分是拖拽组件工具栏的区域，该区域包括布局组件、基础组件和单选/多选组件，中间部分是页面展示区域，右边部分是配置页面和组件的属性的区域，其中包括页面配置和组件配置两部分，图2目前展示的是组件配置包括的属性1、属性2、属性3和属性4。

在一种可能的实现方式中，field层主要处理组件底层数据的数据类型，例如number，string，boolean值等。在这一阶段，可以按照数据类型将组件底层数据从目标组件信息中拆解出来，得到简单类型的组件底层数据。

在另一种可能的实现方式中，根据组件底层数据，确定组件底层数据的第一数据类型的步骤，包括：识别组件底层数据是否为嵌套型数据；若是，则采用递归拆解的方式，对组件底层数据进行拆解，得到多个子数据；确定多个子数据的第一数据类型。

由于嵌套型数据，通过简单的拆解方式拆解可能会出现错误，因此，可以先识别组件底层数据的数据类型，若该数据是嵌套型数据，则采用递归拆解的方式对该组件底层数据进行拆解，得到多个子数据，然后确定每个子数据的第一数据类型。

作为一种示例，嵌套型数据类型可以是包括子数据类型的数据类型。例如，嵌套型数据类型可以是object或array，这两种数据类型可能包括例如number，string，boolean等简单类型。

示例性地，假设提交的组件底层数据的数据结构如下所示：

其中，username为简单数据类型的字段，其数据类型为string。而address则是包含两个string类型字段的object类型字段。单从address这个字段本身无法感知到其内容类型。因此在拆解address字段时，需要以和拆解info字段时一样的方式递归拆解，将其拆解为如下所示类型的数据结构：

作为一种示例，参见图3a，图3a是根据本申请一实施例提供的一种拆解组件底层数据的示意图。在图3a中，先通过数据类型处理层(field)确定组件底层数据的数据类型，包括array(矩阵型)、boolean(布尔逻辑型)、integer(整型)、number(数值型)、object(对象型)、string(字符串型)这几种数据类型，由于array和boolean这两种数据类型是嵌套型，所以采用递归拆解的方式拆解组件底层数据，对于其他数据类型的组件底层数据，可以将其数据类型确定为第一数据类型。

本申请实施例中，对于嵌套型的组件底层数据，通过递归拆解的方式将嵌套型的组件底层数据进行拆解，再确定组件底层数据的第一数据类型，则能够拆解得到简单类型的子数据，基于该子数据确定数据类型，提高了确定数据类型的准确率。

在一些实施例中，客户端可以预先存储有数据类型和组件格式的第一映射关系表，以及存储组件格式与基准组件数据的第二映射关系表。或者，该第一映射关系表和第二映射关系表可以是服务端中存储并发送给客户端的。因此，在确定组件底层数据的数据类型后，可以根据第一数据类型从第一映射关系表中查找得到与第一数据类型对应的第一组件格式，然后从第二映射关系表中查找得到与第一组件格式对应的第一基准组件数据，再根据第一数据类型和第一基准组件数据在渲染后的页面结构中对待访问页面中的第一基准组件和该第一基准组件的组件底层数据进行渲染。

作为一种示例，数据类型和组件格式的关系并不是一一对应的，例如对于前端显示的多选框或时间信息或文本输入框来说，他们的底层数据对应的数据类型都是string，但却分别对应不同的外在展示形式。具体的映射关系可以参见表4，表4是一种示例性的第一映射关系表。

表4第一映射关系表

从表4可知，复选框、时间区间和多选框这三种组件格式的组件，其底层数据的数据类型均是Array，数字时间戳和数字输入框这两种组件格式的组件，其底层数据的数据类型均是均是Number/Integer。

示例性地，参见图3a，在图3a中，确定组件底层数据的数据类型integer(整型)、number(数值型)、object(对象型)、string(字符串型)之后，可以确定该数据类型对应的组件格式，或者说，在微件层(Widget层)确定数据类型对应的组件格式。

作为一种示例，基准组件数据可以包括该种组件格式的组件的模板数据。例如，单选框类的组件的外在显示形式是包括边框的方形框，搜索框类的组件的外在显示形式是不包括边框的圆角矩形框，切换框类的组件的外在显示形式是立方体型框。并且，组件格式与基准组件数据可以是一一对应的关系，也可以是一个组件格式对应多个基准组件数据。在一个组件格式对应多个基准组件数据的情况下，可以从中任选一个作为第一基准组件数据。参见表5，表5是一种示例性的第二映射关系表。

表5第二映射关系表

组件格式(Widget)	基准组件数据
		Select(单选框)	基准组件数据1
DateTime(文字时间戳)	基准组件数据2、基准组件数据3
		Input(输入框)	基准组件数据4

从表5可知，单选框对应一个基准组件数据，即基准组件数据1，切换框对应两个基准组件数据，即基准组件数据2。

在一种可能的实现方式中，由于第一映射关系表中，数据类型与组件格式并不是一一对应的关系，因此，基于数据类型可能确定多个组件格式，在该种情况下，可以根据组件属性结构信息中的组件类型从多个组件格式中确定第一组件格式，再确定该第一组件格式对应的基准组件数据，若该第一组件格式对应的基准组件数据是多个，可以从中随机选择一个或者根据预设规则选择一个作为第一基准组件数据。

示例性地，假设第一数据类型是String，根据该第一数据类型从第一映射关系表中查找得到的第一组件格式包括文字时间戳、单选框和输入框，获取组件属性结构信息中的组件类型，假设组件类型中包括单选类型，则可以将该单选框作为第一组件格式，然后从第二映射表中查找单选框对应的第一基准组件数据，即基准组件数据1，基于该第一数据类型String和基准组件数据1在渲染得到的页面结构中对基准组件数据和第一数据类型String进行渲染，则可以得到单选框组件。

在一些实施例中，渲染得到的第一基准组件没有设置属性结构，或者其属性结构是默认的模板组件的属性结构，因此，可以根据组件属性结构信息调整渲染后的第一基准组件。

作为一种示例，组件属性结构信息可以包括组件的样式尺寸、组件在页面中的位置，可以根据组件的样式尺寸对第一基准组件的样式尺寸进行调整，且将第一基准组件调整至组件在页面中的位置处，如此，可以得到调整后的第一基准组件，实现将调整后的第一基准组件渲染到待访问页面的页面结构中，则可以得到待访问页面。

示例性地，确定组件格式后，可以确定该组件格式对应的第一基准组件数据，然后基于第一数据类型和第一基准组件数据在页面结构中渲染得到第一基准组件，参见图3a，再在视图组件层(view component层)根据组件属性结构信息调整渲染后的第一基准组件。

需要说明的是，通过上述描述已经可以渲染得到待访问页面，实现本申请的页面访问方法。但一个前端页面可以包含三个部分：数据(要显示哪些数据)+格式(怎样的排版显示，是表格还是图表等)+交互(例如点击按钮等有一个交互反馈)，组件信息中可以包括组件底层数据、页面信息中可以包括页面的格式，但若待访问页面可以包括UI交互功能，则该待访问页面中包括具有UI功能的组件，该具有UI功能的组件被触发时，会触发其对应的事件，事件是前端页面中重要的一环，表单提交、加载数据等都需要事件来触发。因此，在本申请实施例中，组件的目标组件信息中还可以包括组件对应的事件信息，该事件可以包括组件之间的第一事件信息和组件自身的第二事件信息，该第一事件信息可能是触发第一组件，然后跳转至显示第二组件，该第二事件可能是触发第一组件可以显示一些信息或提交页面信息，在该种情况下，渲染组件时需要将触发的事件也进行渲染。由此可见，不同类型的事件被触发也会影响渲染得到的待访问页面。因此，接下来介绍不同类型的事件被触发时渲染待访问页面的过程。

在一种可能的实现方式中，方法还包括：在识别到发起组件与接收组件间的第一事件被触发的情况下，根据发起组件和接收组件的组件标识，从目标组件信息中读取第一事件信息；根据第一事件信息，对第一事件的事件过程进行渲染。

在具体实施中，目标组件信息与组件标识对应，则目标组件信息中包括的第一事件信息与组件标识对应，其对应的组件标识是发起组件的组件标识，为了明确该第一事件是该发起组件与哪个组件之间的事件，该第一事件还可以携带接收组件的组件标识，如此可以确定第一事件是以其对应的组件为发起组件，且以其携带的组件标识对应的组件为接收组件生成的第一事件。

在一些实施例中，若发起组件被触发，则可以认为检测到发起组件与接收组件之间的第一事件被触发，可以获取发起组件和接收组件的组件标识，先确定与发起组件的组件标识对应的目标组件信息，由于一个组件可能对应多个第一事件，且不同的第一事件是针对不同的接收组件的，因此，可以根据接收组件的组件标识，从该目标组件信息中获取第一事件信息，再根据第一事件信息将第一事件的事件过程进行渲染，则渲染得到的待访问页面中包括第一事件被触发时发起组件和接收组件的切换过程。

作为一种示例，发起组件是被触发的组件，第一事件触发数据是发起组件被触发时获取的事件数据，接收组件是第一事件被触发后展示的组件，第一事件生成数据是发起组件被触发后基于第一事件触发数据生成的事件数据，则发起组件是第一事件触发数据的来源方，接收组件是第一事件生成数据的接收方。

在本申请实施例中，为了便于在widget层中完成事件的记录，可以约束由JSON结构描述的页面内，事件的触发都由按钮组件完成。例如，假设该发起组件是按钮组件，当该按钮组件被触发时，可以获取如query参数之类的信息(即第一事件触发数据)，并将基于query参数之类的信息生成的数据(即第一事件生成数据)传输给接收组件用于展示。

作为一种示例，正是由于在配置页面时，客户端在widget层里为每个组件注册了全局事件，且将全局事件作为组件信息发送至服务端存储，因此，在根据来自服务端的目标页面信息和目标组件信息渲染得到待访问页面时，每当第一事件被触发，按钮组件会向全局的Event Bus发送一个附带接收组件的组件标识的信息，全局的EventBus会根据接收组件的组件标识在已经注册的组件列表中找到接收组件，并根据发起组件的组件标识和接收组件的组件标识从目标组件信息中获取第一事件的结果(即第一事件生成数据)，基于该第一事件的结果对接收组件实时进行渲染，则可以得到更新后的接收组件，并且接收组件中可以展示接收到的第一事件生成数据，如此便完成了一次事件交互。

上述方案在识别到组件之间第一事件被触发时，将组件之间的第一事件的事件过程渲染出来，实现了根据需求实时调整页面的效果，不需要等待排版周期，也不用编写冗杂且重复的代码，提高了页面生成的灵活性。

在另一种可能的实现方式中，方法还包括：

在识别到预设组件的第二事件被触发的情况下，根据预设组件的组件标识，从目标组件信息中读取第二事件信息；根据第二事件信息，识别第二事件的事件类型；若事件类型为加载类型，则向服务端发送数据获取请求，数据获取请求用于触发服务端根据数据获取请求获取待加载数据；根据待加载数据，确定待加载数据的第二数据类型；根据第二数据类型，确定第二数据类型对应的第二组件格式；基于第二组件格式，确定第二组件格式对应的第二基准组件数据；根据第二数据类型和第二基准组件数据，在渲染后的页面结构中，对待访问页面中的第二基准组件以及第二基准组件的待加载数据进行渲染；根据组件属性结构信息，调整渲染后的第二基准组件。

其中，预设组件可以是触发第二事件的组件。例如，该预设组件可以是按钮组件。加载类型的事件是指在触发第二事件后，会加载待加载数据。例如，加载类型的事件可以是根据问题数据，从服务端获取一个复杂的数据结构并展示在页面上。

在具体实施中，目标组件信息与组件标识对应，则目标组件信息中包括的第二事件信息与组件标识对应，且该第二事件信息携带有事件类型。因此，在识别到预设组件的第二事件被触发时，可以根据预设组件的组件标识，从目标组件信息中获取第二事件信息，且对第二事件信息携带的事件类型进行判断，若该事件类型是加载类型，则需要向服务端发送数据获取请求，以请求服务端发送待加载数据，该数据获取请求中可以携带URL(uniformresource locator，统一资源定位***)信息，服务端可以基于该URL信息获取到待加载数据，并且该待加载数据可以以key-value的形式存储在服务端中，因此，客户端接收到的待加载数据可以是key-value形式的数据。由于待加载数据在页面上是显示在组件中的，因此，可以基于该待加载数据渲染得到第二基准组件。

进一步地，客户端接收到待加载数据后，可以将该待加载数据存储在field层，并通过field层对该待加载数据进行校验，若校验成功，则可以将该待加载数据发送至widget层，进行后续的组件渲染；若校验失败，则可以在页面展示“错误信息”，该“错误信息”可以以弹框的形式展示。

在一些实施例中，可以从第一映射表中查找第二数据类型对应的第二组件格式，然后从第二映射表中查找第二组件格式对应的第二基准数据，再基于第二数据类型和第二基准组件数据，在渲染后的页面结构中对第二基准组件和第二基准组件的待加载数据进行渲染，并且，根据组件属性结构信息对渲染后的第二基准组件进行调整，得到展示待加载数据的第二基准组件。

例如，参见图3b，图3b是根据本申请一实施例提供的一种触发事件后执行的操作的示意图。在图3b中，数据类型处理层field对于嵌套类型(如array或object类型)的数据采用递归拆解的方式拆解为简单类型的数据，并确定数据类型。对于非嵌套类型(如非array和object类型)的数据按照数据类型拆解。将数据类型发送至微件层(widget层)，widget是包在数据类型处理层field外的一层，field是主要处理底层数据的层，widget主要用来处理事件/格式/UI等。若预设组件是按钮组件，在按钮组件的第二事件被触发时，按钮组件会向全局的事件总线(Event Bus)发送组件标识和第二事件信息，全局的Event Bus会在组件信息中确定该组件标识对应的组件的待加载数据，将该待加载数据发送给按钮组件，按钮组件接收到待加载数据后更新自身的视图，将该待加载数据渲染在该按钮组件上。

需要说明的是，渲染得到展示待加载数据的第二基准组件的过程与上述渲染得到第一基准组件的过程相同，具体实现可以参见上述相关描述，本实施例在此不再赘述。

在另一些实施例中，确定待加载数据的数据类型后，若该数据类型是提交类型，则可以获取该预设组件中输入的数据，拼凑成一个数据结构，提交给服务端以完成一系列操作。作为一种示例，若待加载数据的数据类型是提交类型，可以将该待访问页面的页面信息和组件信息提交给服务端，且客户端可以展示“提交完成”的信息，该“提交完成”的信息可以以弹框的形式展示。

上述方法在识别到组件的第二事件被触发时，可以将第二事件的事件结果渲染出来，达到了根据操作实时调整页面的效果，不需要等待排版周期，也不用编写冗杂且重复的代码，提高了页面生成的灵活性。

在本申请实施例中，view component层可以用于定义一个可以描述组件所有属性的结构体，负责从前端的配置页面向JSON数据传值。因此在一次前端页面的生成过程中，通过可实时交互修改的view component层接收与组件相关的所有信息(即组件信息)，在widget层根据组件信息渲染得到对应的组件，并添加事件，最后在field层中定义这个组件内部实际数据的类型。

需要说明的是，通过上述描述已经可以实现本申请的页面访问方法，得到待访问页面。但在本方案中，由于可以在前端通过可视化的操作生成页面，因此，在生成待访问页面后，若需要更新待访问页面中的某个组件或为待访问页面增加组件，可以执行更新操作，并将更新后的组件信息和页面信息反馈给服务端，以便于服务端能够存储最新的页面结构信息，则后续访问页面时能够得到最新的符合访问需求的页面。

因此，在基于目标页面信息和目标组件信息，渲染得到待访问页面的步骤之后，还包括：

在接收到针对待访问页面的更新请求的情况下，展示待访问页面对应的编辑页面；接收在编辑页面输入的组件编辑信息；根据组件编辑信息，更新待访问页面的组件信息，并发送更新后的组件信息至服务端，其中，更新后的组件信息用于服务端对页面表和组件表进行更新。

也就是说，若待访问页面需要更新，可以先展示待访问页面对应的编辑页面，然后接收用户通过客户端在编辑页面输入的组件编辑信息，根据该组件编辑信息对待访问页面的组件信息进行更新，并将更新后的组件信息发送至服务端，以使得服务端可以根据更新后的组件信息对页面表和组件表进行更新。

作为一种示例，在渲染得到待访问页面后客户端会展示该待访问页面给用户，若想要修改该待访问页面的功能，可以触发该待访问页面中的编辑控件，则客户端会接收到对该待访问页面的更新请求，响应于该更新请求，客户端可以展示组件编辑页面，用户在该组件编辑页面中输入组件编辑信息，则客户端根据该组件编辑信息对待访问页面的组件信息进行更新，则该待访问页面的信息发生了变化，为了保证客户端页面编辑和服务端信息存储的同步性，需要将该更新后的组件信息发送至服务端，则服务端可以根据该更新后的组件信息对页面表和组件表进行更新，使得服务端存储的与该待访问页面相关的信息均是最新的，则在访问页面时能够展示最新的页面。

通过上述方式，在需求发生变化时便能够立刻对待访问页面重新进行编辑，即能够实时地对待访问页面进行更新，缩短了页面更新的周期，提高了页面更新的效率，且将更新后的组件信息发送至服务端存储，则服务端存储的信息也能实时更新，因此后续接收到页面访问请求后，根据服务端返回的页面结构信息生成的待访问页面必然也是更新后的页面，符合访问需求。

在一些实施例中，根据组件编辑信息，更新待访问页面的组件信息的步骤，包括：

根据组件编辑信息携带的组件标识，识别组件编辑类型；在组件编辑类型为更新组件的情况下，根据组件编辑信息携带的组件更新信息，更新待访问页面的组件信息中更新组件对应的组件信息；在组件编辑类型为新增组件的情况下，在待访问页面的组件信息中增加新增组件的组件信息。

也就是说，可以先根据组件编辑信息中的组件标识确定组件编辑类型，若组件编辑类型是更新组件，则是对待访问页面中已有的组件(更新组件)进行更新，可以将更新组件的组件信息修改为该组件编辑信息携带的组件更新信息；若组件编辑类型是新增组件，则可以通过拖拽组件的方式在待访问页面中增加新增组件，并在待访问页面的组件信息中增加新增组件的组件信息。

作为一种示例，组件编辑信息可以携带组件标识，若该组件标识在待访问页面的页面信息中存在，则说明此次更新是对待访问页面中已有的组件进行更新，即可以确定组件编辑类型是更新组件；若该组件标识在待访问页面的页面信息中不存在，则说明此次更新是要在待访问页面增加新的组件，即可以确定组件编辑类型是新增组件。

在组件编辑类型是更新组件的情况下，可以先确定待访问页面的组件信息中更新组件的组件信息，然后将该更新组件的组件信息修改为该组件更新信息。在组件编辑类型是新增组件的情况下，可以将组件更新信息作为新增组件的组件信息增加至待访问页面的组件信息中。

通过上述方式，按照组件编辑类型采用不同的方法对待访问页面的组件信息进行更新，能够实现对待访问页面中组件的更新，不需要编写代码，实时性更强。

本申请在客户端编写可用JSON数据描述的自定义组件，并将页面JSON生成的过程可视化为组件的拖拽拼接，开发人员可通过无代码的简易拖拽操作，直观地组合出想要的页面，同时实现JSON数据的拼接和嵌套。并且，由于本申请中待访问页面的生成完全依赖于服务端的页面结构信息，而这个页面结构信息可以在客户端配置页面的过程中实时更改存储，因此解决了现有技术中前端页面存在的发版周期长的问题，真正达到了前端页面的实时修改。

本申请实施例提供的应用于客户端的页面访问方法，向服务端发送页面访问请求，该页面访问请求携带待访问页面的页面标识；接收服务端返回的待访问页面的页面结构信息，该页面结构信息为服务端基于页面标识查找页面表和组件表得到，该页面表记录有页面标识与页面信息的对应关系，该组件表记录有组件标识与组件信息的对应关系；解析页面结构信息，获得目标页面信息和目标组件信息；基于目标页面信息和目标组件信息，渲染得到待访问页面。上述方法将客户端的页面展示和服务端的信息存储联动起来，在进行页面访问时，客户端可以从服务端获取页面信息和组件信息，并根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

图4是根据本申请一实施例提供的一种应用于服务端的页面访问方法的流程图，具体可以包括以下步骤：

步骤402：接收客户端发送的页面访问请求，页面访问请求携带待访问页面的页面标识。

在本实施例中，在访问页面时，服务端会接收到客户端的页面访问请求，该页面访问请求中携带待访问页面的页面标识，则服务端可以基于该页面标识获取与待访问页面的相关的信息。即服务端可以预先存储有配置完成的页面的页面信息和组件信息。

因此，在接收客户端发送的页面访问请求的步骤之前，方法还包括：

接收客户端发送的待配置页面的页面标识、页面信息和组件信息，其中，待配置页面的页面信息和组件信息为客户端获取到用户在待配置页面拖选组件后生成，页面信息包括所拖选组件的组件标识；将待配置页面的页面标识和页面信息，以对应记录的方式，记录至预先创建的页面表中；将拖选组件的组件标识和待配置页面的组件信息，以对应记录的方式，记录至预先创建的组件表中。

其中，待配置页面是客户端展示的需要配置的页面，页面标识可以用来唯一标识该待配置页面，页面信息可以包括该待配置页面的业务类型、布局属性、组件标识和顺序等信息，组件信息可以包括待配置页面中展示的组件的结构、配置等信息，且页面标识与页面信息对应，组件标识与组件信息对应。

在一些实施例中，在客户端显示待配置页面，通过用户拖拽组件的方式实现对该待配置页面的配置，实现了前端页面动态配置的功能，而要将其存储，以便在下一次访问页面时继续展示，又或者当需求变更时进行修改而实现真正的动态更新，还需要后端的配合。因此，在将拖选组件拖拽至页面展示区域时，可以获取拖选组件的组件标识，基于该组件标识获取该组件的组件信息，并且将该拖选组件的组件标识、该拖选组件在待配置页面中的位置信息以及顺序等添加至该待配置页面的页面信息中，并且将该页面信息、组件信息和页面标识发送至服务端，则服务端可以将页面标识和页面信息对应存储至预先创建的页面表中，且将拖选组件的组件标识和组件信息对应存储至预先创建的组件表中。

例如，参见图2，用户可以通过将待配置页面的组件工具栏的布局组件拖拽至页面展示区域，实现对待配置页面的配置。

进一步地，在配置完待配置页面后，客户端还会设置每个组件的全局事件，并且将全局事件的事件信息记录在对应的组件的组件信息中。并且，全局事件包括第一事件和第二事件，该第一事件和第二事件的详细描述可以参见上述实施例的相关描述。

本申请实施例中，通过拖选组件的方式对客户端的待配置页面进行配置，且将该待配置页面的页面信息存储至服务端的页面表，将该待配置页面的组件信息存储至服务端的组件表中，则服务端可以记录与该待配置页面相关的所有信息，以便于在访问页面时，能够将存储的页面信息和组件信息反馈给客户端，则客户端可以显示页面。并且，每次客户端配置待配置页面后都会由服务端存储页面信息和组件信息，即能够及时存储与该待配置页面相关的所有信息。

步骤404：根据页面标识，从页面表中查找待访问页面对应的目标页面信息，页面表记录有页面标识与页面信息的对应关系，页面信息包括组件标识。

在一些实施例中，页面表中包括页面标识和页面信息的对应关系。示例性地，参见表2，根据页面标识，可以从页面表中查找与该页面表示对应的页面信息，将查找到的页面信息确定为待访问页面对应的目标页面信息。

例如，查找到的目标页面信息如下所示：

其中，page_name可以表示页面名称，id可以表示页面标识，content包括页面中按照顺序排列的组件的组件标识，order包括组件的先后顺序。

步骤406：读取目标页面信息中的目标组件标识，根据目标组件标识，从组件表中查找目标组件标识对应的目标组件信息，组件表记录有组件标识与组件信息的对应关系。

在一些实施例中，页面信息中记录有组件标识，组件表中包括组件标识和组件信息的对应关系。示例性地，页面信息中包括一个content字段，该content字段中按照顺序记录了页面中展示的组件的组件标识。示例性地，参见表2和表3，从目标页面信息中获取到目标组件标识，然后从组件表中查找与该组件标识对应的组件信息，将查找到的组件信息确定为该组件标识对应的目标组件信息。

例如，从组件表(component表)中获取组件1对应的目标组件信息，如下所示：

其中，component_name表示组件名称，width表示组件的宽度。

步骤408：对目标页面信息和目标组件信息进行拼接，获得页面结构信息，将页面结构信息返回至客户端，页面结构信息用于客户端渲染得到待访问页面。

例如，将目标页面信息和获取目标组件信息进行拼接，得到页面结构信息如下所示：

需要说明的是，通过上述步骤，服务端可以获取到待访问页面的页面结构信息，然后将该页面结构信息返回给客户端，客户端按照图1对应的实施例提供的方法对页面结构信息进行拆解渲染，便可以得到待访问页面。

在客户端展示待访问页面的过程中，可以实时对该待访问页面进行更新，即修改该待访问页面的页面信息和/或组件信息，并且在修改后会将发生改变的页面信息和/组件信息发送至服务端，因此服务端会接收到更新组件信息，且基于该更新组件信息对存储的页面表和组件表进行更新。

进一步地，方法还包括：若接收到客户端发送的目标组件的更新组件信息，则根据目标组件的组件标识，将组件表中目标组件的组件标识对应的组件信息更新为更新组件信息。

在具体实施中，目标组件可能是页面中的已有组件，也可能是新增组件，对于已有组件和新增组件可以采用不同的更新组件信息的方式。

在一些实施例中，若目标组件是页面中的已有组件，因此，可以基于组件标识从组件表中查找到目标组件的组件信息，并且，将该目标组件的组件信息修改为更新组件信息。

在另一些实施例中，若目标组件是页面中的新增组件，因此，可以将目标组件的组件标识和更新组件信息以对应的形式存储至组件表中，实现对组件表的更新。

作为一种示例，更新组件信息中还可以包括目标组件在页面中的位置信息，则服务端可以将目标组件的组件标识按照该目标组件在页面中的位置信息存储至该页面的页面信息中，以实现对页面表的更新。

本申请实施例中，每次客户端对页面做了任何更新，都可以及时告知服务端，服务端能够及时更新页面表和组件表，达到实时动态更新页面的效果。

需要说明的是，本实施例中没有记载的实现方式均可以参见上述实施例的相关描述。

本申请实施例提供的应用于服务端的页面访问方法，接收客户端发送的页面访问请求，该页面访问请求中携带待访问页面的页面标识，根据页面标识，从页面表中查找待访问页面对应的目标页面信息，页面表记录有页面标识与页面信息的对应关系，页面信息包括组件标识，读取目标页面信息中的目标组件标识，根据目标组件标识，从组件表中查找目标组件标识对应的目标组件信息，组件表记录有组件标识与组件信息的对应关系。客户端通过拖拽组件的方式配置页面之后，将页面信息和组件信息发送至服务端存储，实现了客户端的页面配置和服务端的信息存储的联动，在进行页面访问时，服务端根据客户端的页面访问请求从页面表中获取页面信息，以及从组件表中获取组件信息，并返回给客户端，以便客户端根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，并且客户端对页面进行任何更新都可以通知服务端及时更新，达到实时动态更新页面的效果，且能够保证每次获取到的页面都是最新配置的页面，提升了用户的使用体验，进而提高用户粘度。

图5是根据本申请一实施例提供的一种页面访问方法的示意图，以访问页面X为例，该方法的具体实现过程如下：

用户通过客户端访问页面X，则客户端生成页面访问请求发送至服务端，以向服务端请求页面结构信息，该页面访问请求中包括该页面X的页面ID，服务端基于页面ID从页面表(page表)中获取页面X的页面信息，该页面信息中包括content字段，该content字段中包括按照顺序排列的组件标识，根据页面信息中的组件标识从组件表中查找到该页面X中展示的组件的组件信息，服务端将组件信息和页面信息拼接成完整的页面结构信息并返回给客户端。

客户端接收到服务端发送的页面结构信息，拆解该页面结构信息，得到拆解的schema字段，该schema字段包括页面信息、组件属性结构信息和组件底层数据，然后根据schema字段中的页面信息开始渲染该页面X的页面结构。由于在配置页面X时，为每个组件设置了全局事件，该全局事件包括第一事件和第二事件，第二事件中包括加载类事件，若该加载类第二事件被触发，则需要获取待加载数据渲染在对应的组件上，因此，在渲染页面X中的组件之前，需要判断是否加载待加载数据。

由于第二事件通常是按钮组件对应的事件，因此若按钮组件被触发，则可以获取该按钮组件对应的第二事件信息，根据该第二事件信息确定该第二事件的事件类型，在该第二事件是加载类型时，认为需要加载待加载数据，即若是，客户端向服务端发送携带URL链接的数据获取请求，则服务端基于该URL链接获取到该待加载数据，且该待加载数据以key-value形式存储在服务端，服务端以key-value的形式将待加载数据发送至客户端的field层，客户端校验该待加载数据，如可以通过预设的校验算法进行校验。若校验失败，则可以弹出错误信息，如以弹框的形式显示“错误信息”，提示获取的待加载数据错误，用户可以选择继续触发该按钮组件以重新获取待加载数据，或者停止触发该按钮组件。若校验成功，则客户端将该待加载数据发送至Widget层，在Widget层，对待访问页面中的基准组件和基准组件的组件底层数据进行渲染，具体的，在Widget层根据schema字段中的组件底层数据的数据类型，从第一映射关系表中确定组件格式，再根据组件格式从第二映射关系表中确定基准组件数据，然后根据数据类型和基准组件数据，在渲染得到的页面结构中对待访问页面中的基准组件和基准组件的组件底层数据进行渲染，然后进入view层，基于组件属性结构信息调整渲染后的基准组件，以丰富基准组件的其他配置信息，如长度、是否可编辑等，渲染得到页面X。

渲染完成后，若由于需求发生变化导致页面X的功能需要更改，则可以对该页面X进行更新，因此在渲染完成后，可以判断需求是否发生变化。在具体实施中，若需求没有发生变化，则表示渲染完成；若想要修改该页面X的功能，可以触发页面X展示的编辑控件，则客户端会接收到对该页面X的更新请求，可以认为需求发生了变化，即若是，客户端展示编辑页面，该编辑页面可以展示页面X中所有组件的组件信息，用户可以在编辑页面输入携带组件标识的组件编辑信息，根据组件标识确定组件编辑类型，若该组件编辑类型是更新组件，如对已有组件A进行更新，则可以将更新组件A对应的组件信息修改为该组件编辑信息携带的组件更新信息，即在view层表示组件信息的表单中，将更新组件A的组件信息修改为组件更新信息；若组件编辑类型是新增组件，可以从客户端记录的组件表中拖拽新增组件至页面展示区域的相应位置，并在view层表示组件信息的表单中增加新增组件的组件信息。在更新组件完成后，保存新的页面信息和组件信息，并且将该新的页面信息和组件信息发送至服务端，以便于服务端可以更新其存储的页面表和组件表，因此，在重新加载进入该页面X时，由于服务端存储的信息已经更新，则获取的前端页面X会实时更新，展示是更新后的页面。

例如，在新增组件之前，假设页面X包括组件1(component 1)和组件2(component2)。新增了组件3(component 3)之后，页面X包括组件1、组件2和组件3，则页面信息发生变化，组件表中的组件信息也新增了组件3的组件信息。

该组件1的组件信息包括：

“id:1,

component_type:string,

component_name:'comp1',

component_title:'测试组件1',

options:{}”

该组件2的组件信息包括：

“id:2,

component_type:string,

component_name:'comp2',

component_title:'测试组件2',

options:{}”

该页面X的页面信息如下所示：

“page_id:0,

page_name:example,

page_content:comp1 comp2”

新增了组件3(component 3)之后，该组件3的组件信息包括：

“id:3,

component_type:string,

component_name:'comp3',

component_title:'测试组件3',

options:{}”

新增组件3之后，新的页面信息如下所示：

“page_id:0,

page_name:example,

page_content:comp1 comp2 comp3”

其中，id可以表示组件标识，component_type可以表示组件底层数据类型，component_name可以表示组件名称，component_title可以表示组件标题，page_id:可以表示页面标识，page_name可以表示页面名称，page_content可以表示页面中展示的组件的组件名称。

本申请实施例中，在访问页面时，只要通过客户端进入该页面则会向服务端请求一次该页面的页面结构信息，根据服务端返回的页面结构信息生成页面，若在客户端增加了新的组件，则可以将该新的组件的组件信息和页面更新后的页面信息发送至服务端，因此在下次访问页面时，客户端展示的是包括新的组件的页面。如此，能够将客户端的页面配置和服务端的信息存储联动起来，在进行页面访问时，客户端可以从服务端获取页面信息和组件信息，并根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

与图1的方法实施例相对应，本申请还提供了客户端实施例，图6是根据本申请一实施例提供的一种客户端的结构示意图。如图6所示，该客户端包括：

发送模块602，被配置为向服务端发送页面访问请求，所述页面访问请求携带待访问页面的页面标识；

第一接收模块604，被配置为接收所述服务端返回的所述待访问页面的页面结构信息，所述页面结构信息为所述服务端基于所述页面标识查找页面表和组件表得到，所述页面表记录有页面标识与页面信息的对应关系，所述组件表记录有组件标识与组件信息的对应关系；

解析模块606，被配置为解析所述页面结构信息，获得目标页面信息和目标组件信息；

渲染模块608，被配置为基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面。

可选地，所述目标组件信息包括组件属性结构信息和组件底层数据；

所述渲染模块608，进一步被配置为：

基于所述目标页面信息，对所述待访问页面的页面结构进行渲染；

根据所述组件底层数据，确定所述组件底层数据的第一数据类型；

根据所述第一数据类型，确定所述第一数据类型对应的第一组件格式；

基于所述第一组件格式，确定所述第一组件格式对应的第一基准组件数据；

根据所述第一数据类型和所述第一基准组件数据，在渲染后的页面结构中，对所述待访问页面中的第一基准组件以及所述第一基准组件的所述组件底层数据进行渲染；

根据所述组件属性结构信息，调整渲染后的所述第一基准组件。

可选地，所述渲染模块608还被配置为：

在识别到发起组件与接收组件间的第一事件被触发的情况下，根据所述发起组件和所述接收组件的组件标识，从所述目标组件信息中读取第一事件信息；

根据所述第一事件信息，对所述第一事件的事件过程进行渲染。

可选地，所述渲染模块608还被配置为：

在识别到预设组件的第二事件被触发的情况下，根据所述预设组件的组件标识，从所述目标组件信息中读取第二事件信息；

根据所述第二事件信息，识别所述第二事件的事件类型；

若所述事件类型为加载类型，则向所述服务端发送数据获取请求，所述数据获取请求用于触发所述服务端根据所述数据获取请求获取待加载数据；

根据所述待加载数据，确定所述待加载数据的第二数据类型；

根据所述第二数据类型，确定所述第二数据类型对应的第二组件格式；

基于所述第二组件格式，确定所述第二组件格式对应的第二基准组件数据；

根据所述第二数据类型和所述第二基准组件数据，在渲染后的页面结构中，对所述待访问页面中的第二基准组件以及所述第二基准组件的所述待加载数据进行渲染；

根据所述组件属性结构信息，调整渲染后的所述第二基准组件。

可选地，所述渲染模块608，进一步被配置为：

识别所述组件底层数据是否为嵌套型数据；

若是，则采用递归拆解的方式，对所述组件底层数据进行拆解，得到多个子数据；

确定所述多个子数据的第一数据类型。

可选地，所述客户端还包括：

展示模块，被配置为在接收到针对所述待访问页面的更新请求的情况下，展示所述待访问页面对应的编辑页面；

第三接收模块，被配置为接收在所述编辑页面输入的组件编辑信息；

第一更新模块，被配置为根据所述组件编辑信息，更新所述待访问页面的组件信息，并发送更新后的所述组件信息至所述服务端，其中，更新后的所述组件信息用于所述服务端对所述页面表和所述组件表进行更新。

可选地，所述第一更新模块进一步被配置为：

根据所述组件编辑信息携带的组件标识，识别组件编辑类型；

在所述组件编辑类型为更新组件的情况下，根据所述组件编辑信息携带的组件更新信息，更新所述待访问页面的组件信息中更新组件对应的组件信息；

在所述组件编辑类型为新增组件的情况下，在所述待访问页面的组件信息中增加新增组件的组件信息。

可选地，所述发送模块602还被配置为：

获取用户在待配置页面拖选组件后生成的所述待配置页面的页面信息和组件信息；

将所述待配置页面的页面标识、页面信息和组件信息发送至所述服务端，以对应存储至所述页面表和所述组件表。

可选地，所述页面结构信息是JSON SCHEMA格式的数据信息，所述目标页面信息和目标组件信息为JSON数据。

本申请实施例提供的客户端，向服务端发送页面访问请求，该页面访问请求携带待访问页面的页面标识；接收服务端返回的待访问页面的页面结构信息，该页面结构信息为服务端基于页面标识查找页面表和组件表得到，该页面表记录有页面标识与页面信息的对应关系，该组件表记录有组件标识与组件信息的对应关系；解析页面结构信息，获得目标页面信息和目标组件信息；基于目标页面信息和目标组件信息，渲染得到待访问页面。上述方法将客户端的页面展示和服务端的信息存储联动起来，在进行页面访问时，客户端可以从服务端获取页面信息和组件信息，并根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

上述为本实施例的一种客户端的示意性方案。需要说明的是，该客户端的技术方案与上述的应用于客户端的页面访问方法的技术方案属于同一构思，该客户端的技术方案未详细描述的细节内容，均可以参见上述应用于客户端的页面访问方法的技术方案的描述。

与图4的方法实施例相对应，本申请还提供了服务端实施例，图7示出了本申请一实施例提供的一种服务端的结构示意图。如图7所示，该服务端包括：

第二接收模块702，被配置为接收客户端发送的页面访问请求，所述页面访问请求携带待访问页面的页面标识；

第一查找模块704，被配置为根据所述页面标识，从页面表中查找所述待访问页面对应的目标页面信息，所述页面表记录有页面标识与页面信息的对应关系，所述页面信息包括组件标识；

第二查找模块706，被配置为读取所述目标页面信息中的目标组件标识，根据所述目标组件标识，从组件表中查找所述目标组件标识对应的目标组件信息，所述组件表记录有组件标识与组件信息的对应关系；

拼接模块708，被配置为对所述目标页面信息和所述目标组件信息进行拼接，获得页面结构信息，将所述页面结构信息返回至所述客户端，所述页面结构信息用于所述客户端渲染得到所述待访问页面。

可选地，第二接收模块702还被配置为：

接收所述客户端发送的待配置页面的页面标识、页面信息和组件信息，其中，所述待配置页面的页面信息和组件信息为所述客户端获取到用户在所述待配置页面拖选组件后生成，所述页面信息包括所拖选组件的组件标识；

将所述待配置页面的页面标识和页面信息，以对应记录的方式，记录至预先创建的页面表中；

将所述拖选组件的组件标识和所述待配置页面的组件信息，以对应记录的方式，记录至预先创建的组件表中。

可选地，所述服务端还包括：

第二更新模块，被配置为若接收到所述客户端发送的目标组件的更新组件信息，则根据所述目标组件的组件标识，将所述组件表中所述目标组件的组件标识对应的组件信息更新为所述更新组件信息。

本申请实施例提供的服务端，接收客户端发送的页面访问请求，该页面访问请求中携带待访问页面的页面标识，根据页面标识，从页面表中查找待访问页面对应的目标页面信息，页面表记录有页面标识与页面信息的对应关系，页面信息包括组件标识，读取目标页面信息中的目标组件标识，根据目标组件标识，从组件表中查找目标组件标识对应的目标组件信息，组件表记录有组件标识与组件信息的对应关系。客户端通过拖拽组件的方式配置页面之后，将页面信息和组件信息发送至服务端存储，实现了客户端的页面配置和服务端的信息存储的联动，在进行页面访问时，服务端根据客户端的页面访问请求从页面表中获取页面信息，以及从组件表中获取组件信息，并返回给客户端，以便客户端根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，并且客户端对页面进行任何更新都可以通知服务端及时更新，达到实时动态更新页面的效果，且能够保证每次获取到的页面都是最新配置的页面，提升了用户的使用体验，进而提高用户粘度。

上述为本实施例的一种服务端的示意性方案。需要说明的是，该服务端的技术方案与上述的应用于服务端的页面访问方法的技术方案属于同一构思，该服务端的技术方案未详细描述的细节内容，均可以参见上述应用于服务端的页面访问方法的技术方案的描述。

图8是根据本申请一实施例提供的一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。

计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(PSTN，Public SwitchedTelephone Network)、局域网(LAN，Local Area Network)、广域网(WAN，Wide AreaNetwork)、个域网(PAN，Personal Area Network)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，NetworkInterface Card))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，Wireless LocalArea Networks)无线接口、全球微波互联接入(Wi-MAX，World Interoperability forMicrowave Access)接口、以太网接口、通用串行总线(USB，Universal Serial Bus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，Near Field Communication)接口，等等。

在本申请的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备800还可以是移动式或静止式的服务端。

其中，处理器820执行计算机指令时实现上述任一页面访问方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述任一页面访问方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述任一页面访问方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述任一页面访问方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的任一页面访问方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述任一页面访问方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。

本申请还提供了一种页面访问***，图9是根据本申请一实施例提供的一种页面访问***的结构示意图，该页面访问***包括客户端902和服务端904。

所述客户端902向服务端发送页面访问请求，所述页面访问请求携带待访问页面的页面标识；

所述服务端904接收客户端发送的页面访问请求，所述页面访问请求携带待访问页面的页面标识；根据所述页面标识，从页面表中查找所述待访问页面对应的目标页面信息，所述页面表记录有页面标识与页面信息的对应关系，所述页面信息包括组件标识；读取所述目标页面信息中的目标组件标识，根据所述目标组件标识，从组件表中查找所述目标组件标识对应的目标组件信息，所述组件表记录有组件标识与组件信息的对应关系；对所述目标页面信息和所述目标组件信息进行拼接，获得页面结构信息，将所述页面结构信息返回至所述客户端，所述页面结构信息用于所述客户端渲染得到所述待访问页面；

所述客户端902接收所述服务端返回的所述待访问页面的页面结构信息，所述页面结构信息为所述服务端基于所述页面标识查找页面表和组件表得到，所述页面表记录有页面标识与页面信息的对应关系，所述组件表记录有组件标识与组件信息的对应关系；解析所述页面结构信息，获得目标页面信息和目标组件信息；基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面。

本申请实施例提供的页面访问***，客户端通过拖拽组件的方式配置页面之后，客户端将页面信息和组件信息发送至服务端存储，实现了客户端的页面配置和服务端的信息存储的联动，在进行页面访问时，客户端可以从服务端获取页面信息和组件信息，并根据页面信息和组件信息生成待访问页面，不需要等待到版本更新的时间跟随发版周期更新页面，可以实时地根据需求更新页面，以使得页面访问后展示的页面符合访问需求，提升用户的使用体验，进而提高用户粘度。

上述为本实施例的一种页面访问***的示意性方案。需要说明的是，该页面访问***的技术方案与上述的页面访问方法的技术方案属于同一构思，该页面访问***的技术方案未详细描述的细节内容，均可以参见上述页面访问方法的技术方案的描述。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims

1.一种页面访问方法，其特征在于，应用于客户端，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述目标组件信息包括组件属性结构信息和组件底层数据；

所述基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面的步骤，包括：

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

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

根据所述第二事件信息，识别所述第二事件的事件类型；

5.根据权利要求2所述的方法，其特征在于，所述根据所述组件底层数据，确定所述组件底层数据的第一数据类型的步骤，包括：

识别所述组件底层数据是否为嵌套型数据；

确定所述多个子数据的第一数据类型。

6.根据权利要求1-5中任一项所述的方法，其特征在于，在所述基于所述目标页面信息和所述目标组件信息，渲染得到所述待访问页面的步骤之后，所述方法还包括：

在接收到针对所述待访问页面的更新请求的情况下，展示所述待访问页面对应的编辑页面；

接收在所述编辑页面输入的组件编辑信息；

根据所述组件编辑信息，更新所述待访问页面的组件信息，并发送更新后的所述组件信息至所述服务端，其中，更新后的所述组件信息用于所述服务端对所述页面表和所述组件表进行更新。

7.根据权利要求6所述的方法，其特征在于，所述根据所述组件编辑信息，更新所述待访问页面的组件信息的步骤，包括：

8.根据权利要求1-5中任一项所述的方法，其特征在于，在所述向服务端发送页面访问请求的步骤之前，所述方法还包括：

9.根据权利要求1-5中任一项所述的方法，其特征在于，所述页面结构信息是JSONSCHEMA格式的数据信息，所述目标页面信息和目标组件信息为JSON数据。

10.一种页面访问方法，其特征在于，应用于服务端，所述方法包括：

11.根据权利要求10所述的方法，其特征在于，在所述接收客户端发送的页面访问请求的步骤之前，所述方法还包括：

12.根据权利要求10或11所述的方法，其特征在于，所述方法还包括：

若接收到所述客户端发送的目标组件的更新组件信息，则根据所述目标组件的组件标识，将所述组件表中所述目标组件的组件标识对应的组件信息更新为所述更新组件信息。

13.一种客户端，其特征在于，包括：

14.一种服务端，其特征在于，包括：

15.一种页面访问***，其特征在于，所述页面访问***包括客户端和服务端；

16.一种计算设备，其特征在于，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现权利要求1-9或权利要求10-12中任意一项所述方法的步骤。

17.一种计算机可读存储介质，其特征在于，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1-9或权利要求10-12中任意一项所述方法的步骤。