CN113296856A - 页面跳转与路由配置方法、设备、系统及存储介质 - Google Patents

Abstract

本申请实施例提供一种页面跳转与路由配置方法、设备、系统及存储介质。在本申请实施例中，提供一种新的应用架构，在该应用架构中除了包括应用端和与应用端对应的服务端之外，还增加了路由配置端，路由配置端通过应用端所支持的组件为应用端进行前端路由的配置，应用端根据组件和路由配置端所配置的前端路由进行页面跳转。在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

Description

页面跳转与路由配置方法、设备、系统及存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种页面跳转与路由配置方法、设备、系统及存储介质。

背景技术

近几年，前端技术的发展和越来越快的迭代速度，每隔一两年就出现一些新的框架和设计模式。现在前端在路由、插槽、单页、微前端、响应式、面向终态的数据驱动等有了很多设计模式，尤其是单页应用不再从服务端配置路由路径，而是由前端掌控，实现前后端之间的解耦。但是，现有前端路由在实现上存在路由访问不够灵活，不能满足人们不断变化的路由需求等问题。

发明内容

本申请的多个方面提供一种页面跳转与路由配置方法、设备、系统及存储介质，用以提高路由访问不够灵活，进而提高应用端的服务质量。

本申请实施例提供一种应用系统，包括：应用端、路由配置端和服务端；路由配置端，用于为应用端配置组件数据并保存至服务端；组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；应用端，用于在用户发起访问请求的情况下获取组件数据；根据组件数据中包含的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。

本申请实施例还提供一种页面跳转方法，适用于应用端，该方法包括：在用户发起访问请求的情况下获取组件数据，组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。

本申请实施例还提供一种路由配置方法，适用于应用系统中的路由配置端，该方法包括：获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，为应用端生成组件数据。

本申请实施例还提供一种终端设备，包括：存储器和处理器；存储器，用于存储应用端对应的计算机程序；处理器，与存储器耦合，用于执行计算机程序，以用于：在用户发起访问请求的情况下获取组件数据，组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。

本申请实施例还提供一种配置设备，包括：存储器、处理器和通信组件；存储器，用于存储路由配置端对应的计算机程序；处理器，与存储器耦合，用于执行计算机程序，以用于：通过通信组件获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，为应用端生成组件数据。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器实现本申请实施例中任一项页面跳转方法和路由配置方法中的步骤。

在本申请实施例中，提供一种新的应用架构，在该应用架构中除了包括应用端和与应用端对应的服务端之外，还增加了路由配置端，路由配置端通过应用端所支持的组件为应用端进行前端路由的配置，应用端根据组件和路由配置端所配置的前端路由进行页面跳转。在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请示例性实施例提供的一种应用系统的结构示意图；

图1b为本申请示例性实施例提供的一种三级路由视图的页面示意图；

图1c为本申请示例性实施例提供的一种三级路由视图的关系示意图；

图1d为本申请示例性实施例提供的一种财务系统使用其他系统开发的权限管理模块的状态示意图；

图1e为本申请示例性实施例提供的一种组件配置界面的状态示意图；

图1f为本申请示例性实施例列举的组件跳转类型的示意图；

图1g为本申请示例性实施例示出的可以配置是否明细的组件配置界面示意图；

图2为本申请示例性实施例提供的一种基于前端路由的页面跳转方法的流程示意图；

图3为本申请示例性实施例提供的一种路由配置方法的流程示意图；

图4为本申请示例性实施例提供的一种终端设备的结构示意图；

图5为本申请示例性实施例提供的一种配置设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

随着前端技术的发展，在页面路由上实现了前后端的解耦，但是，现有前端路由在实现上是将各种路由配置写死在前端代码中的，随之带来的问题是功能权限、路由访问深度，菜单国际化都没法很好地控制，前端路由访问不够灵活。鉴于此，在本申请一些实施例中，提供一种新的应用架构，在该应用架构中除了包括应用端和与应用端对应的服务端之外，还增加了路由配置端，路由配置端通过应用端所支持的组件为应用端进行前端路由的配置，应用端根据组件和路由配置端所配置的前端路由进行页面跳转。在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1a为本申请示例性实施例提供的一种应用系统的结构示意图；如图1a所示，该应用系统100包括：应用端101、路由配置端102和服务端103。

在本实施例中，应用端101也可以称为前端应用，与服务端103对应，应用端101负责与用户交互，为用户提供本地服务，例如向用户展示各种页面，响应用户指令等；服务端103负责响应应用端101的请求，为应用端101提供数据、接口、存储等各种服务。在本实施例中，并不限定应用端101的实现形式，例如可以是小程序、App、单页应用、客户端(如浏览器)等。在部署实施上，应用端101可以部署在智能手机、笔记本电脑、平板电脑、台式电脑、自助服务设备、智能机器人、智能手表或智能手环等终端设备上；相应地，服务端103可部署在传统服务器、云服务器、服务器阵列、虚拟机或数据中心等服务端设备中。

在本申请实施例中，应用端101不仅可以向用户展示各种页面，而且可响应用户发起的访问请求，借助前端路由技术向用户展示不同页面，即在不同页面之间进行跳转。前端路由不同于传统路由，它不需要服务端103进行解析，可以通过一个hash函数或者H5提供的history API来实现。其中，hash指的是URL链接中#后面的部分，hash值的变化是通过应用端101监听hash值改变事件(hashchange事件)得到的，当监听到hash值发生变化时，应用端101不会向发送服务端103发送页面更新请求以刷新整个页面，而是根据跳转路径请求加载页面组件以实现页面跳转。H5提供的history API允许在不刷新页面的前提下，通过脚本语言的方式来进行页面上某块局部内容的更新。例如，当页面P2与页面P1只有局部区域中显示的界面不同，而大部分区域中显示的界面相同时，在H5中，可以通过history API执行如下处理：通过AJAX请求向服务器端请求页面P2中与页面P1中不同的局部区域及该区域中的信息；在页面P1中通过脚本语言装载该区域及其中的信息；通过history API在不刷新页面的前提下在应用端101的地址栏中从页面P1的URL地址切换到页面P2的URL地址。经过该处理后，用户将看到应用端101的地址栏中从页面P1的URL地址切换到页面P2的URL地址，并且显示的页面也完全为页面P2的页面，从而实现在不刷新页面的前提下将浏览器中的页面切换到另一个页面的功能。

在应用端101的开发过程中，前端路由用来设定跳转路径，并将跳转路径与相应的页面组件映射起来；在应用端101使用过程中，针对用户发起的访问请求，前端路由可解析该访问请求对应的跳转路径，根据开发过程中建立的映射关系实现不同页面组件间的切换。前端路由技术涉及三个要素，分别是路由映射(RouterMap)、路由视图(RouterView)和路由链接(RouterLink)；路由映射负责跳转路径与页面组件之间的映射关系；路由视图是用来切换前端页面的容器(Panel)，主要负责跳转路径对应的页面组件在前端页面上的渲染位置；路由链接一般用来配置跳转路径，类似Html中的<a>标签，是指可以使地址栏发生变化的导航链接。

在本实施例中，并不限定应用端101采用的路由形式，例如路由可以不分级，全部采用一级路由，也可以采用分级路由。在采用分级路由的情况下，应用端101可以采用二级路由，也可以采用三级路由，甚至也可以根据应用需求拓展四级路由、五级路由等具有更高深度的路由形式。每一级路由都有相应的路由视图与之对应。以应用端采用三级路由为例，如图1b所示，三级路由对应三级路由视图，具有三级路由视图的页面主要分为三部分：第一部分是顶部导航(HeaderMenu)，其位于页面的顶端，主要放置一级菜单、工具栏、用户头像等；第二部分是侧边栏(SiderMenu)，位于页面的左端，主要放置子级菜单树，即二级菜单、三级菜单直至末级菜单，点击末级菜单可跳转到不同的页面；第三部分是工作区(Workspace)，位于页面的中部，它是用户的工作界面，可以显示不同的页面内容。在三级路由视图中，路由就相当于经脉或者骨架，隐藏在页面之下，控制页面的不同展示方式。

在本实施例中，无论应用端101采用何种路由形式，应用端101具有菜单功能，在其展示的页面上包括多级菜单，例如一级菜单，二级菜单，…，五级菜单等。菜单的级别与路由的级别是各自定义的，两者之间没有直接关系，例如前端应用101可以采用三级路由和十级菜单，也可以采用二级路由和五级菜单，还可以采用三级路由和四级菜单等。虽然菜单的级别和路由的级别是各自定义的，但菜单与路由以及路由视图之间具有一定对应关系。如图1c所示，以应用端101采用三级路由及三级路由视图架构为例，应用端101的首页可对应一级路由及一级路由视图，应用端101的一级菜单对应二级路由及二级路由视图，应用端101的末级菜单对应三级路由及三级路由视图。在应用端101采用三级路由的情况下，若应用端101采用二级菜单，则二级菜单即为末级菜单；若应用端101采用三级甚至更多级菜单，则在一级菜单和末级菜单之间还会有其它级别的菜单，且不论末级菜单有多少个层次，例如5层深度，它所对应的路由只能是三级路由。换句话说，应用端101支持的至少部分菜单与应用端101的前端路由及路由视图之间存在对应关系，且在应用端101采用三级路由的情况下，至少部分菜单包括应用端101支持的一级菜单和末级菜单。其中，根据路由视图的大小范围来看，各级路由视图之间的关系为：一级路由视图包含二级路由视图，二级路由视图包含三级路由视图，如图1c所示。

进一步，如图1c所示，在应用端101实现为浏览器的情况下，用户在浏览器的首页面中输入域名路径，然后点击回车访问。此时，整个页面就是一级路由视图，而浏览器的地址窗口就承载了路由链接的作用。然后，用户点击页面顶端导航的一级菜单，整个二级路由视图区域就切换成了不同的页面，侧边栏根据不同的一级菜单展示不同的菜单树。接下来，用户点击侧边栏菜单树中的末级菜单，工作区(即三级路由视图区域)就会切换成不同的工作界面。

在此说明，在上文中，结合图1b和图1c对应用端101所支持的菜单与路由视图之间的对应关系进行了示例性说明，但并不限于此。应用端101除了支持菜单这一种组件之外，还可以支持其它多种组件，例如窗口、下拉菜单、文本(text)组件、按钮(button)、标签(tag)、消息列表、导航组件等等。每类组件之间可以存在级别关系，且这些组件都可以与应用端101支持的路由视图进行关联，实现组件之间的跳转。在本实施例中，为了使应用端101更加灵活地进行页面显示和跳转，在应用系统100中增设路由配置端102，主要通过应用端101所支持的组件为应用端101进行前端路由的配置，将前端路由的配置与应用端进行解耦，使得应用端101的路由配置更加灵活，进而更加灵活地进行页面显示和跳转。在部署实施上，路由配置端102可以部署在智能手机、笔记本电脑、平板电脑、台式电脑、自助服务设备、智能机器人、智能手表或智能手环等终端设备上，也可以部署在传统服务器、云服务器、服务器阵列、虚拟机或数据中心等服务端设备中。

具体地，路由配置端102可以为应用端101配置组件数据并保存至服务端103；该组件数据包含应用端101所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数。可选地，若组件是菜单，则路由配置端102可以为前端应用101配置菜单数据并保存至服务端103；该菜单数据包含前端应用101所支持的至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数。

其中，至少部分组件是指应用端101所支持的多级组件中与应用端101的路由及路由视图存在对应关系的一个或多个组件。至少部分组件之间的从属关系指的是组件之间的从属依赖关系。例如，以至少部分组件是多级菜单中至少部分菜单为例，则二级菜单的父级菜单是一级菜单，三级菜单的父级菜单是二级菜单，也就是说，二级菜单从属于一级菜单，三级菜单从属于二级菜单。其中，组件数据中每个组件是被配置跳转路径的组件，每个组件对应的跳转路径参数是指从该组件或该组件对应的地址信息(如URL)进行路由跳转时，需要用到的路径参数，该路径参数可唯一指向一个待显示页面组件，是指跳转至该待显示页面组件所需的路径参数，例如可以是待显示页面组件的名称或标识，或者，也可以是待显示页面组件的域名、存储路径等参数，对此不做限定。待显示页面组件是指从该组件需要跳转到的页面组件。

可选地，为应用端101配置组件数据的操作可由配置人员发起，基于此，一种配置组件数据的实施方式包括：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系以及部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据。当然，除了由配置人员发起配置操作之外，也可以由其它事件或方式触发为应用端101配置组件数据的操作。例如，还可以设置定时任务和配置脚本，配置脚本中预先定义好至少部分组件之间的从属关系以及部分组件对应的跳转路径参数，基于此，当定时任务到达时，路由配置端102可从配置脚本中获取至少部分组件之间的从属关系以及部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据。

进一步可选地，在为应用端101配置组件数据的操作可由配置人员发起实施例中，针对至少部分组件中的每个组件，响应配置人员针对组件发起的配置操作，应用端101展示组件对应的组件配置界面，该组件配置界面上包含标识配置项、父节点配置项以及跳转路径配置项；其中，标识配置项用于供配置人员配置组件的标识信息，父节点配置项用于供配置人员配置组件之间的从属关系，跳转路径配置项用于供配置人员配置组件对应的跳转路径参数；响应配置人员对针对标识配置项、父节点配置项以及跳转路径配置项的输入操作，获取组件的标识信息、组件从属的上级组件以及跳转路径参数。

在配置完成后，路由配置端102将配置好的组件数据上传至服务端103，由服务端103对组件数据进行持久化存储。在本实施例中，并不限定服务端103对组件数据进行持久化存储的实施方式，例如可以是服务端103将组件数据持久化在本地硬盘中，也可以是服务端103将组件数据永久的保存至相关数据库中，例如基础数据库和核心数据库。

在应用端101开发完成后，可以上线使用。在应用端101使用过程中，可以向用户展示各种页面。例如，应用端101被启动后默认向用户展示首页。在应用端当前显示的页面上，用户可以发起访问请求，该访问请求用于请求访问其他页面或页面内容。其中，当前显示的页面可以是首页面，也可以是其它页面。用户发起访问请求的方式并不限定，例如可以通过点击当前页面上的组件发起访问请求；或者，也可以在当前页面中的地址栏输入要访问的地址信息，点击确认按钮或敲击回车发起访问请求等。对应用端101来说，需要根据访问请求进行页面跳转。在本实施例中，在用户发起访问请求之后，应用端101可以获取组件数据，进而基于组件数据跳转至访问请求对应的页面。

可选地，应用端101在获取组件数据时，可以判断用户是否是首次发起访问请求；若是，从服务端103获取组件数据；若否，从本地缓存中获取组件数据。对于用户首次发起的访问请求，应用端101从服务端103拉取组件数据；服务端103会为用户创建一个会话并将组件数据存储在会话(session)缓存中，直至会话结束。可选地，在会话持续期间，应用端101在需要组件数据时，可以查询本地缓存中是否存在组件数据；如果存在，则从本地缓存中获取组件数据；如果不存在，则向服务端103请求；服务端103首先查询会话缓存中是否存在组件数据；若存在，则将会话缓存中的组件数据提供给应用端101；若不存在，则从持久化存储空间中获取组件数据并提供给应用端101。持久化存储空间可以是本地硬盘，也可以是相关数据库，对此不做限定。

当然，应用端101也可以不用判断用户是否是首次发起访问请求，在接收到访问请求时，可直接从服务端103维护的持久化存储空间中读取组件数据。

在本实施例中，在用户发起访问请求的情况下，应用端101获取组件数据，之后，可根据组件数据中包含的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。其中，跳转路径唯一指向一个待显示页面组件，且该待显示页面组件是预先配置的与该跳转路径对应的页面组件，而待显示页面组件与跳转路径之间的对应关系可由应用端101的应用需求而定。

在本实施例中，一种生成跳转路径的实施方式包括：根据至少部分组件之间的从属关系，对至少部分组件对应的跳转路径参数进行拼接，以得到至少部分组件对应的静态路由数据；根据至少部分组件对应的静态路由数据中与访问请求匹配的目标静态路由数据，生成跳转路径。

其中，组件数据中包含至少部分组件之间的从属关系，基于此，对至少部分组件对应的跳转路径参数进行拼接，可以得到至少部分组件中每个组件对应的静态路由数据。静态路由数据指的是配置人员手工配置的路由信息，在使用过程中不会发生变化的路由信息。例如，可以配置一级组件对应的跳转路径参数为A，配置末级组件对应的跳转路径参数为B；对于一级组件，可以直接根据其跳转路径参数拼接出其静态路由数据；对于末级组件，可以将其所属的父级组件的跳转路径参数和末级组件的跳转路径参数进行拼接，得到末级组件对应的静态路由数据，例如A/B。相应地，用户发起的访问请求中可以包含静态路由数据，另外还可以包含一些参数值，基于此，可以将访问请求中的静态路由数据与至少部分组件对应的静态路由数据进行匹配，得到与访问请求匹配的静态路由数据，为便于描述将与访问请求匹配的静态路由数据称为目标静态路由数据；之后，根据目标静态路由数据，生成跳转路径。可选地，上述组件可以是菜单，则一级组件为一级菜单，末级组件为末级菜单，父级组件为父级菜单。

在本实施例中，并不限定根据目标静态路由数据生成跳转路径的具体实施方式。在一可选实施例中，可以直接将目标静态路由数据作为跳转路径。在又一可选实施例中，可以将访问请求(如URL)中携带的参数值(例如参数值可以是URL中传递的动态页面所需的动态参数值，也可以是URL中传递的静态页面所需的参数值)和目标静态路由数据进行合并，以得到跳转路径。其中，访问请求中的参数值与目标静态路由数据可以唯一指向一个待显示页面组件。进而，根据跳转路径加载待显示页面组件以实现页面跳转。

在本申请一些实施例中，借助微前端技术实现一站式工作台。微前端技术是一种类似于微服务的架构，在本申请实施例中，将微服务的理念应用于应用端，即将应用端由单一的单体应用转变为多个小型应用端聚合为一的应用，或者在一站式工作台中，将不同应用端开发的界面组合在一起。本申请实施例提供的一站式工作台包括多个应用系统100，每个应用系统100都包括应用端101和服务端103，每一应用系统100负责单一的应用领域；在一站式工作台中，可根据用户的工作场景，灵活组合相关应用系统。需要说明的是，这些应用系统100可以共用一个路由配置端102，但不限于此。为了更加符合微服务的思想，本申请实施例中，设计系统和模块的概念，每个应用系统100中的模块，既可以是应用系统自己开发的内部模块，也可以是来自其他应用系统的外部模块。之所以可以灵活组合不同应用系统的模块，得益于前后端彻底的解耦，应用端101对应的页面组件都变成了一个个静态的JS文件，而服务端除了索引该JS文件组成的页面组件之外，不用提供其他页面跳转方式，只提供服务API就可以，这极大地提高了开发效率。

下面结合附图进行说明，如图1d所示，例如财务系统的应用端只开发了单据管理和采购管理等模块，而权限管理是每一个应用系统都需要的，财务系统可以使用其他应用系统开发的权限管理模块，而不用再重复构建模块，从而提高开发效率，节约开发所需的人力或物力资源。具体地，可以在配置组件数据的过程中，将财务系统应用端中的某个组件与其它应用系统(例如员工系统)的权限管理模块进行关联，可以将该组件配置指向其它应用系统的权限管理模块的跳转路径参数，使得财务系统可以使用其他系统开发的权限管理模块。

其中，由于内部模块和外部模块的区别，对内部模块和外部模块进行路由访问的方式会有所不同。鉴于此，本申请实施例还提出了路由访问类型的概念，并且对多种路由访问类型进行了融合，可以支持多种路由访问类型。首先，从页面跳转的类型对路由访问类型进行分类，分为同窗口跳转类型和跨窗口跳转类型；同窗口跳转类型是指路由跳转时，在当前窗口中进行页面跳转，不需要重新创建新窗口的跳转类型。跨窗口跳转类型是指路由跳转时，需要重新创建新窗口进行页面跳转的跳转类型。可选地，同窗口跳转类型至少包括文件夹型、内部模块、外部模块和内嵌类型等；跨窗口跳转类型至少包括链接型。其中，文件夹型是指组件对应的跳转类型是文件夹。内部模块型是指组件对应的跳转类型是应用系统100内部的模块。外部模块类型是指组件对应的跳转类型是与应用系统100位于同域(例如都属于同一一站式工作台)中的其它应用系统发布的模块。内嵌类型指的是组件对应的跳转类型是iframe，iframe会在当前窗口创建另外一个文档的内联框架，作用是显示文档中的文档(嵌套页面)。链接型是指组件对应的跳转类型是链接，跳转类型为链接时，应用端101需要重新创建新窗口进行页面跳转，以显示链接对应的内容。进一步，组件的跳转类型还包括403跳转类型和404跳转类型。403跳转类型，用于在用户没有权限访问组件数据的情况下向用户返回403错误页面。404跳转类型，用于在用户没有为某个组件进行前端路由配置的情况下，即找到对应的组件数据时，向用户返回无法404错误页面。

基于上述，在配置组件数据的过程中，还包括配置至少部分组件对应的跳转类型。其中，一种配置包含组件之间的从属关系、组件的跳转路径参数以及跳转类型的组件数据的过程如下：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系、组件的跳转路径参数以及至少部分组件对应的跳转类型；以及根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数和跳转类型生成组件数据。

进一步可选地，在由配置人员发起为应用端101配置组件数据的实施例中，配置组件数据的一种详细实施方式包括：显示应用端101所支持的多级组件，多级组件包括至少部分组件；针对至少部分组件中的每个组件，响应配置人员针对组件发起的配置操作，展示组件对应的组件配置界面，组件配置界面上包含标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项；响应配置人员对针对标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项的输入操作，获取组件的标识信息、组件从属的上级组件以及组件对应的跳转类型和跳转路径参数。

如图1e所示，为组件配置界面的一种实现方式。该组件配置界面包括：代号配置项、名称配置项、父节点配置项、跳转类型配置项、参数配置项和地址配置项等；其中，代号配置项和名称配置项组合在一起可作为上述标识配置项，用来配置组件在系统内部的代号和名称，组件的代号和名称可唯一标识一个组件；父节点配置项用来配置组件从属的父级组件；参数配置项和地址配置项组合起来可实现为跳转路径配置项，用来配置组件对应的跳转路径参数，其中，参数和地址组合起来可唯一指向一个待显示页面组件；跳转类型配置项用来配置组件对应的跳转类型。进一步，如图1f所示，本实施例提供的跳转类型包括但不限于：文件夹型、内部模块型、外部模块型、iframe(内嵌模块)型和链接型。在图1e和图1f中，以组件是菜单，且以宝贝详情菜单为例对配置过程进行展示，如图1e和图1f所示，宝贝详情菜单的名称为宝贝详情，代号为details，其自上而下依次从属于页面实例菜单/页面模板菜单/列表管理菜单，其对应的跳转类型为内部模块型，其配置了明细界面的信息项；其对应的跳转路径参数包括地址：query-list/detail，参数为：:id；其中，地址：query-list/detail和参数：:id结合起来可跳转至具体的宝贝详情页。

在本实施例中，应用端101使用过程中，可以向用户展示各种页面，例如，应用端101被启动后默认向用户展示首页；随着页面的跳转，应用端101还可向用户展示其他页面。在应用端当前显示的页面上，用户可以发起访问请求，该访问请求用于请求访问其他页面或页面内容。应用端101可以接收并响应用户发起的访问请求，获取组件数据，该组件数据中包含的至少部分组件之间的从属关系、至少部分组件对应的跳转路径参数以及至少部分组件对应的跳转类型。应用端101获取组件数据之后，根据至少部分组件之间的从属关系，对至少部分组件对应的跳转路径参数进行拼接，以得到至少部分组件对应的静态路由数据；从至少部分组件对应的静态路由数据中获取与访问请求匹配的目标静态路由数据；将访问请求中携带的参数值和目标静态路由数据进行合并，以得到跳转路径；然后，根据组件数据中至少部分组件对应的跳转类型，确定目标组件对应的跳转类型，目标组件是至少部分组件中与目标静态路由数据对应的组件；进而，结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转。

其中，不同的跳转类型对应于不同的跳转方式，首先，对同窗口跳转类型和跨窗口跳转类型这两大类跳转类型对应的跳转方式进行说明。应用端结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转的一种实施方式包括：若目标组件对应的跳转类型为同窗口跳转类型，则根据各级组件与视图区域之间的对应关系，确定当前页面中与目标组件对应的目标视图区域；根据跳转路径加载待显示页面组件到目标视图区域中以实现页面跳转；若目标组件对应的跳转类型为跨窗口跳转类型，则根据跳转路径加载与应用端101跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件显示在新窗口中。其中，其它应用指的是与应用系统100彼此之间具有授权关系或合作关系的跨域应用。可选地，跨窗口跳转类型为链接型。其中，待显示页面组件是指需要从目标组件跳转到的页面组件，是跳转路径指向的页面组件。

在本实施例中，目标视图区域可以是任何区域，根据组件级别的不同，目标视图区域也有所不同。例如，在三级路由视图下，若组件是一级组件，则目标视图区域是二级路由视图，若组件是末级组件，则目标视图区域是三级路由视图，对此不作限定。

另外，对于同窗口跳转类型，根据具体跳转类型的不同，应用端101实现页面跳转的方式也有所不同。下面针对文件夹型、内部模块型、外部模块型、iframe(内嵌模块)型分别就页面跳转方式进行说明。

若目标组件对应的跳转类型为文件夹型，则应用端101可根据跳转路径读取文件夹中的待显示页面组件，并将待显示页面组件渲染至目标视图区域中。可选地，应用端在读取文件夹中的待显示页面组件之前，还可以判断目标组件是否配置了直接引用跳转路径的信息项，若是，则根据跳转路径读取文件夹中的待显示页面组件。

若目标组件对应的跳转类型为内部模块型，则应用端101可根据跳转路径读取应用端发布的用户界面(User Interface，UI)组件库中的待显示页面组件，并将该待显示页面组件渲染至目标视图区域中。路由配置端会配置组件的名称和路径，若是内部模块，则会将内部模块作为组件打包到app.js文件中使其成为UI组件库中的一个代码片段。其中，app.js是一个轻量级的JavaScript UI库，用来创建移动的Web应用，所创建的应用外观跟原生的应用相同，性能也近乎一致。其中，JS文件是一种脚本文件，可以控制页面行为，例如控制页面达到一定的动态效果。

若目标组件对应的跳转类型为外部模块型，则应用端101可根据跳转路径读取与应用端同域的其它应用发布的UI组件库中的待显示页面组件，并将该待显示页面组件渲染至目标视图区域中。在本实施例中，其它应用与应用端101同域，即其它应用与应用端101隶属于同一应用管理平台，例如都是一站式工作台中的应用。UI组件库中的页面组件可以是component.js文件。

在此说明，在目标组件对应的跳转类型为文件夹型、内部模块型或外部模块型的情况下，应用端101对待显示页面组件进行渲染时，可以按照应用端101的需求做渲染处理，例如，按照应用端的需求调整页面的宽、高比例等，对此不作限定。

若目标组件对应的跳转类型为内嵌类型，则应用端101可根据跳转路径读取与应用端跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件内嵌至目标视图区域中。在本实施例中，其它应用与应用端101跨域，即其它应用与应用端101分别隶属于不同应用管理平台，例如分别是A服务商提供的应用和B服务商提供的应用。由于在目标视图区域中加载的是跨域应用中的页面组件，应用端101在没有被授权的情况下无法对跨域应用中的页面组件进行重新渲染，可以直接将跨域应用中的页面组件内嵌到目标视图区域中进行展示。

在一可选实施例中，在组件对应的跳转类型为内部模块型或外部模块型的情况下，在组件配置页面中，还可以包括明细信息项，在图1e中明细信息项具体实现为选择是否明细。是否明细：用来说明当前被配置的组件需要跳转至的待显示页面组件是一个功能的首页，还是内部跳转页面。例如，假设日志管理的首页是一个日志列表，点击日志列表中任一条会显示具体的日志详情，那么显示日志详情的页面就是明细页面。相应地，图1g中的参数配置项中需要填写的就是日志ID，因为不同日志详情页面会加载不同日志的详情数据，所以需要配置当前被配置组件需要跳转到的日志详情页面需要加载的是哪个日志的详情数据，即日志ID是谁。相应地，在目标组件对应的跳转类型为内部模块型或外部模块型的情况下，应用端还可以判断目标组件是否配置了明细界面的信息项；若是，则读取明细界面对应的面包屑导航组件，并在面包屑导航组件被触发时将明细界面显示在目标视图区域中。在本实施里中，并不限定面包屑导航组件的实现形式，例如可以是一个按钮、图片或连接等，对此不做限定。面包屑导航组件可以显示当前页面的前一个页面或者目录的链接当被触发时会产生一个面包屑路径，面包屑路径可以使用户了解自己所处的页面位置，可以让用户更快的找到自己想要到达的页面，例如可以快速引导用户定位到上一次目录，也可以快速引导用户进入下一个页面，可以很好的提高用户的友好体验。

在本申请实施例中，通过微前端和微服务端的思想在前后端解耦的基础上进一步实现前端路由配置与应用端之间的解耦，在前端路由配置与应用端解耦的基础上，可以实现功能点的灵活插入，例如可在前端路由过程中增加权限校验、路由访问深度或组件国际化等功能。可以根据用户的使用场景，将多个系统的模块灵活组合，根据不同的场景定制不同的应用系统，达到最大程度的功能复用，减少重复制造模块的机会。例如，每个系统都需要权限管理、日志管理、用户管理、组件管理等功能模块，要是每个应用系统都自己开发，必然极大地影响效率，这时就可以引用其它系统的模块，而不必重复开发，极大地提高了使用效率。

图2为本申请示例性实施例提供的一种基于前端路由的页面跳转方法的流程示意图；适用于应用系统中的应用端，如图2所示，该方法包括：

21、在用户发起访问请求的情况下获取组件数据，组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；

22、根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；

23、根据跳转路径加载待显示页面组件以实现页面跳转。

在本申请实施例中，应用端可响应用户发起的访问请求，借助前端路由技术向用户展示不同页面，即在不同页面之间进行跳转。在应用端开发过程中，前端路由用来设定跳转路径，并将跳转路径与相应的页面组件映射起来；在应用端使用过程中，针对用户发起的访问请求，前端路由可解析该访问请求对应的跳转路径，根据开发过程中建立的映射关系实现不同页面组件间的切换。前端路由技术涉及三个要素，分别是路由映射(RouterMap)、路由视图(RouterView)和路由链接(RouterLink)；路由映射负责跳转路径与页面组件之间的映射关系；路由视图是用来切换前端页面的容器(Panel)，主要负责跳转路径对应的页面组件在前端页面上的渲染位置；路由链接一般用来配置跳转路径，类似Html中的<a>标签，是指可以使地址栏发生变化的导航链接。

在本实施例中，并不限定应用端采用的路由形式，例如路由可以不分级，全部采用一级路由，也可以采用分级路由。在采用分级路由的情况下，应用端可以采用二级路由，也可以采用三级路由，甚至也可以根据应用需求拓展四级路由、五级路由等具有更高深度的路由形式。每一级路由都有相应的路由视图与之对应。详细内容可参见前述实施例，在此不再赘述。

在本实施例中，无论应用端采用何种路由形式，应用端具有组件功能，在其展示的页面上包括多级组件，例如一级组件，二级组件，…，五级组件等。组件的级别与路由的级别是各自定义的，两者之间没有直接关系，例如应用端可以采用三级路由和十级组件，也可以采用二级路由和五级组件，还可以采用三级路由和四级组件等。虽然组件的级别和路由的级别是各自定义的，但组件与路由以及路由视图之间具有一定对应关系。可选地，组件可以是应用端所支持的菜单，则多级组件即为多级菜单，例如一级菜单，二级菜单，…，五级菜单等。菜单的级别与路由的级别是各自定义的，两者之间没有直接关系，例如前端应用可以采用三级路由和十级菜单，也可以采用二级路由和五级菜单，还可以采用三级路由和四级菜单等。虽然菜单的级别和路由的级别是各自定义的，但菜单与路由以及路由视图之间具有一定对应关系。详细内容可参见前述实施例，在此不再赘述。

在应用端开发完成后，可以上线使用。在应用端使用过程中，可以向用户展示各种页面。例如，应用端被启动后默认向用户展示首页。在应用端当前显示的页面上，用户可以发起访问请求，该访问请求用于请求访问其他页面或页面内容。其中，当前显示的页面可以是首页面，也可以是其它页面。用户发起访问请求的方式并不限定，例如可以通过点击当前页面上的组件发起访问请求；或者，也可以在当前页面中的地址栏输入要访问的地址信息，点击确认按钮或敲击回车发起访问请求等。对应用端来说，需要根据访问请求进行页面跳转。在本实施例中，在用户发起访问请求之后，应用端可以获取组件数据，进而基于组件数据跳转至访问请求对应的页面。

可选地，应用端在获取组件数据时，可以判断用户是否是首次发起访问请求；若是，从服务端获取组件数据；若否，从本地缓存中获取组件数据。对于用户首次发起的访问请求，应用端从服务端拉取组件数据；服务端会为用户创建一个会话并将组件数据存储在会话(session)缓存中，直至会话结束。可选地，在会话持续期间，应用端在需要组件数据时，可以查询本地缓存中是否存在组件数据；如果存在，则从本地缓存中获取组件数据；如果不存在，则向服务端请求；服务端首先查询会话缓存中是否存在组件数据；若存在，则将会话缓存中的组件数据提供给应用端；若不存在，则从持久化存储空间中获取组件数据并提供给应用端。持久化存储空间可以是本地硬盘，也可以是相关数据库，对此不做限定。

当然，应用端也可以不用判断用户是否是首次发起访问请求，在接收到访问请求时，可直接从服务端维护的持久化存储空间中读取组件数据。

在本实施例中，在用户发起访问请求的情况下，应用端获取组件数据，之后，可根据组件数据中包含的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。其中，跳转路径唯一指向一个待显示页面组件，且该待显示页面组件是预先配置的与该跳转路径对应的页面组件，而待显示页面组件与跳转路径之间的对应关系可由应用端的应用需求而定。可选地，若组件是菜单，则菜单数据包含前端应用所支持的至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数。

在本实施例中，一种生成跳转路径的实施方式包括：根据至少部分组件之间的从属关系，对至少部分组件对应的跳转路径参数进行拼接，以得到至少部分组件对应的静态路由数据；根据至少部分组件对应的静态路由数据中与访问请求匹配的目标静态路由数据，生成跳转路径。

其中，组件数据中包含至少部分组件之间的从属关系，基于此，对至少部分组件对应的跳转路径参数进行拼接，可以得到至少部分组件中每个组件对应的静态路由数据。静态路由数据指的是配置人员手工配置的路由信息，在使用过程中不会发生变化的路由信息。例如，可以配置一级组件对应的跳转路径参数为A，配置末级组件对应的跳转路径参数为B；对于一级组件，可以直接根据其跳转路径参数拼接出其静态路由数据；对于末级组件，可以将其所属的父级组件的跳转路径参数和末级组件的跳转路径参数进行拼接，得到末级组件对应的静态路由数据，例如A/B。相应地，用户发起的访问请求中可以包含静态路由数据，另外还可以包含一些参数值，基于此，可以将访问请求中的静态路由数据与至少部分组件对应的静态路由数据进行匹配，得到与访问请求匹配的静态路由数据，为便于描述将与访问请求匹配的静态路由数据称为目标静态路由数据；之后，根据目标静态路由数据，生成跳转路径。

在本实施例中，并不限定根据目标静态路由数据生成跳转路径的具体实施方式。在一可选实施例中，可以直接将目标静态路由数据作为跳转路径。在又一可选实施例中，可以将访问请求(如URL)中携带的参数值(例如参数值可以是URL中传递的动态页面所需的动态参数值，也可以是URL中传递的静态页面所需的参数值)和目标静态路由数据进行合并，以得到跳转路径。其中，访问请求中的参数值与目标静态路由数据可以唯一指向一个待显示页面组件。进而，根据跳转路径加载待显示页面组件以实现页面跳转。

在本申请一些实施例中，借助微前端技术实现一站式工作台。微前端技术是一种类似于微服务的架构，在本申请实施例中，将微服务的理念应用于应用端，即将应用端由单一的单体应用转变为多个小型应用端聚合为一的应用，或者在一站式工作台中，将不同应用端开发的界面组合在一起。本申请实施例提供的一站式工作台包括多个应用系统，每个应用系统都包括应用端和服务端，每一应用系统负责单一的应用领域；在一站式工作台中，可根据用户的工作场景，灵活组合相关应用系统。需要说明的是，这些应用系统可以共用一个路由配置端，但不限于此。为了更加符合微服务的思想，本申请实施例中，设计系统和模块的概念，每个应用系统中的模块，既可以是应用系统自己开发的内部模块，也可以是来自其他应用系统的外部模块。之所以可以灵活组合不同应用系统的模块，得益于前后端彻底的解耦，应用端对应的页面组件都变成了一个个静态的JS文件，而服务端除了索引该JS文件组成的页面组件之外，不用提供其他页面跳转方式，只提供服务API就可以，这极大地提高了开发效率。

下面结合附图进行说明，如图1d所示，例如财务系统的应用端只开发了单据管理和采购管理等模块，而权限管理是每一个应用系统都需要的，财务系统可以使用其他应用系统开发的权限管理模块，而不用再重复构建模块，从而提高开发效率，节约开发所需的人力或物力资源。具体地，可以在配置组件数据的过程中，将财务系统应用端中的某个组件与其它应用系统(例如员工系统)的权限管理模块进行关联，可以将该组件配置指向其它应用系统的权限管理模块的跳转路径参数，使得财务系统可以使用其他系统开发的权限管理模块。

其中，由于内部模块和外部模块的区别，对内部模块和外部模块进行路由访问的方式会有所不同。鉴于此，本申请实施例还提出了路由访问类型的概念，并且对多种路由访问类型进行了融合，可以支持多种路由访问类型。首先，从页面跳转的类型对路由访问类型进行分类，分为同窗口跳转类型和跨窗口跳转类型；同窗口跳转类型是指路由跳转时，在当前窗口中进行页面跳转，不需要重新创建新窗口的跳转类型。跨窗口跳转类型是指路由跳转时，需要重新创建新窗口进行页面跳转的跳转类型。可选地，同窗口跳转类型至少包括文件夹型、内部模块、外部模块和内嵌类型等；跨窗口跳转类型至少包括链接型。其中，文件夹型是指组件对应的跳转类型是文件夹。内部模块型是指组件对应的跳转类型是应用系统内部的模块。外部模块类型是指组件对应的跳转类型是与应用系统位于同域(例如都属于同一一站式工作台)中的其它应用系统发布的模块。内嵌类型指的是组件对应的跳转类型是iframe，iframe会在当前窗口创建另外一个文档的内联框架，作用是显示文档中的文档(嵌套页面)。链接型是指组件对应的跳转类型是链接，跳转类型为链接时，应用端需要重新创建新窗口进行页面跳转，以显示链接对应的内容。进一步，组件的跳转类型还包括403跳转类型和404跳转类型。403跳转类型，用于在用户没有权限访问组件数据的情况下向用户返回403错误页面。404跳转类型，用于在用户没有为某个组件进行前端路由配置的情况下，即找到对应的组件数据时，向用户返回无法404错误页面。

在本实施例中，应用端使用过程中，可以向用户展示各种页面，例如，应用端被启动后默认向用户展示首页；随着页面的跳转，应用端还可向用户展示其他页面。在应用端当前显示的页面上，用户可以发起访问请求，该访问请求用于请求访问其他页面或页面内容。应用端可以接收并响应用户发起的访问请求，获取组件数据，该组件数据中包含的至少部分组件之间的从属关系、至少部分组件对应的跳转路径参数以及至少部分组件对应的跳转类型。应用端获取组件数据之后，根据至少部分组件之间的从属关系，对至少部分组件对应的跳转路径参数进行拼接，以得到至少部分组件对应的静态路由数据；从至少部分组件对应的静态路由数据中获取与访问请求匹配的目标静态路由数据；将访问请求中携带的参数值和目标静态路由数据进行合并，以得到跳转路径；然后，根据组件数据中至少部分组件对应的跳转类型，确定目标组件对应的跳转类型，目标组件是至少部分组件中与目标静态路由数据对应的组件；进而，结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转。

其中，不同的跳转类型对应于不同的跳转方式，首先，对同窗口跳转类型和跨窗口跳转类型这两大类跳转类型对应的跳转方式进行说明。应用端结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转的一种实施方式包括：若目标组件对应的跳转类型为同窗口跳转类型，则根据各级组件与视图区域之间的对应关系，确定当前页面中与目标组件对应的目标视图区域；根据跳转路径加载待显示页面组件到目标视图区域中以实现页面跳转；若目标组件对应的跳转类型为跨窗口跳转类型，则根据跳转路径加载与应用端跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件显示在新窗口中。其中，其它应用指的是与应用系统彼此之间具有授权关系或合作关系的跨域应用。可选地，跨窗口跳转类型为链接型。

在本实施例中，目标视图区域可以是任何区域，根据组件级别的不同，目标视图区域也有所不同。例如，在三级路由视图下，若组件是一级组件，则目标视图区域是二级路由视图，若组件是末级组件，则目标视图区域是三级路由视图，对此不作限定。

另外，对于同窗口跳转类型，根据具体跳转类型的不同，应用端实现页面跳转的方式也有所不同。下面针对文件夹型、内部模块型、外部模块型、iframe(内嵌模块)型分别就页面跳转方式进行说明。

若目标组件对应的跳转类型为文件夹型，则应用端可根据跳转路径读取文件夹中的待显示页面组件，并将页面组渲染至目标视图区域中。可选地，应用端在读取文件夹中的待显示页面组件之前，还可以判断目标组件是否配置了直接引用跳转路径的信息项，若是，则根据跳转路径读取文件夹中的待显示页面组件。

若目标组件对应的跳转类型为内部模块型，则应用端可根据跳转路径读取应用端发布的用户界面UI组件库中的待显示页面组件，并将待显示页面组件渲染至目标视图区域中。路由配置端会配置组件的名称和路径，若是内部模块，则会将内部模块作为组件打包到app.js文件中使其成为UI组件库中的一个代码片段。其中，app.js是一个轻量级的JavaScript UI库，用来创建移动的Web应用，所创建的应用外观跟原生的应用相同，性能也近乎一致。其中，JS文件是一种脚本文件，可以控制页面行为，例如控制页面达到一定的动态效果。

若目标组件对应的跳转类型为外部模块型，则应用端可根据跳转路径读取与应用端同域的其它应用发布的UI组件库中的待显示页面组件，并将待显示页面组件渲染至目标视图区域中。在本实施例中，其它应用与应用端同域，即其它应用与应用端隶属于同一应用管理平台，例如都是一站式工作台中的应用。UI组件库中的待显示页面组件可以是component.js文件。

在此说明，在目标组件对应的跳转类型为文件夹型、内部模块型或外部模块型的情况下，应用端对页面组件进行渲染时，可以按照应用端的需求做渲染处理，例如，按照应用端的需求调整页面的宽、高比例等，对此不作限定。

若目标组件对应的跳转类型为内嵌类型，则应用端可根据跳转路径读取与应用端跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件内嵌至目标视图区域中。在本实施例中，其它应用与应用端跨域，即其它应用与应用端分别隶属于不同应用管理平台，例如分别是A服务商提供的应用和B服务商提供的应用。由于在目标视图区域中加载的是跨域应用中的页面组件，应用端在没有被授权的情况下无法对跨域应用中的页面组件进行重新渲染，可以直接将跨域应用中的页面组件内嵌到目标视图区域中进行展示。

在一可选实施例中，在组件对应的跳转类型为内部模块型或外部模块型的情况下，在组件配置页面中，还可以包括明细信息项，在图1e中明细信息项具体实现为选择是否明细。是否明细：用来说明当前被配置的组件需要跳转至的待显示页面组件是一个功能的首页，还是内部跳转页面。例如，假设日志管理的首页是一个日志列表，点击日志列表中任一条会显示具体的日志详情，那么显示日志详情的页面就是明细页面。相应地，图1g中的参数配置项中需要填写的就是日志ID，因为不同日志详情页面会加载不同日志的详情数据，所以需要配置当前被配置组件需要跳转到的日志详情页面需要加载的是哪个日志的详情数据，即日志ID是谁。相应地，在目标组件对应的跳转类型为内部模块型或外部模块型的情况下，应用端还可以判断目标组件是否配置了明细界面的信息项；若是，则读取明细界面对应的面包屑导航组件，并在面包屑导航组件被触发时将明细界面显示在目标视图区域中。在本实施里中，并不限定面包屑导航组件的实现形式，例如可以是一个按钮、图片或连接等，对此不做限定。面包屑导航组件可以显示当前页面的前一个页面或者目录的链接当被触发时会产生一个面包屑路径，面包屑路径可以使用户了解自己所处的页面位置，可以让用户更快的找到自己想要到达的页面，例如可以快速引导用户定位到上一次目录，也可以快速引导用户进入下一个页面，可以很好的提高用户的友好体验。

在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

图3为本申请示例性实施例提供的一种路由配置方法的流程示意图；适用于应用系统中的路由配置端，如图3所示，该方法包括：

31、获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；

32、根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，为应用端生成组件数据。

在本实施例中，路由配置端可以为应用端配置组件数据并保存至服务端；该组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数。可选地，若组件是菜单，则可以为前端应用配置菜单数据并保存至服务端；该菜单数据包含前端应用所支持的至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数。

其中，至少部分组件是指应用端所支持的多级组件中与应用端的路由及路由视图存在对应关系的一个或多个组件。至少部分组件之间的从属关系指的是组件之间的从属依赖关系。例如，以至少部分组件是多级菜单中至少部分菜单为例，则二级菜单的父级菜单是一级菜单，三级菜单的父级菜单是二级菜单，也就是说，二级菜单从属于一级菜单，三级菜单从属于二级菜单。其中，组件数据中每个组件是被配置跳转路径的组件，每个组件对应的跳转路径参数是指从该组件或该组件对应的地址信息(如URL)进行路由跳转时，需要用到的路径参数，该路径参数可唯一指向一个待显示页面组件，是指跳转至该待显示页面组件所需的路径参数，例如可以是待显示页面组件的名称或标识，或者，也可以是待显示页面组件的域名、存储路径等参数，对此不做限定。

可选地，为应用端生成组件数据的操作可由配置人员发起，基于此，一种生成组件数据的实施方式包括：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系以及部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据。当然，除了由配置人员发起配置操作之外，也可以由其它事件或方式触发为应用端配置组件数据的操作。例如，还可以设置定时任务和配置脚本，配置脚本中预先定义好至少部分组件之间的从属关系以及部分组件对应的跳转路径参数，基于此，当定时任务到达时，路由配置端可从配置脚本中获取至少部分组件之间的从属关系以及部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据。

进一步可选地，在为应用端配置组件数据的操作可由配置人员发起实施例中，针对至少部分组件中的每个组件，响应配置人员针对组件发起的配置操作，应用端展示组件对应的组件配置界面，该组件配置界面上包含标识配置项、父节点配置项以及跳转路径配置项；其中，标识配置项用于供配置人员配置组件的标识信息，父节点配置项用于供配置人员配置组件之间的从属关系，跳转路径配置项用于供配置人员配置组件对应的跳转路径参数；响应配置人员对针对标识配置项、父节点配置项以及跳转路径配置项的输入操作，获取组件的标识信息、组件从属的上级组件以及跳转路径参数。

在配置完成后，路由配置端将配置好的组件数据上传至服务端，由服务端对组件数据进行持久化存储。在本实施例中，并不限定服务端对组件数据进行持久化存储的实施方式，例如可以是服务端将组件数据持久化在本地硬盘中，也可以是服务端将组件数据永久的保存至相关数据库中，例如基础数据库和核心数据库。

本申请实施例中，设计系统和模块的概念，每个应用系统中的模块，既可以是应用系统自己开发的内部模块，也可以是来自其他应用系统的外部模块。之所以可以灵活组合不同应用系统的模块，得益于前后端彻底的解耦，应用端对应的页面组件都变成了一个个静态的JS文件，而服务端除了索引该JS文件组成的页面组件之外，不用提供其他页面跳转方式，只提供服务API就可以，这极大地提高了开发效率。

其中，由于内部模块和外部模块的区别，对内部模块和外部模块进行路由访问的方式会有所不同。鉴于此，本申请实施例还提出了路由访问类型的概念，并且对多种路由访问类型进行了融合，可以支持多种路由访问类型。首先，从页面跳转的类型对路由访问类型进行分类，分为同窗口跳转类型和跨窗口跳转类型；同窗口跳转类型是指路由跳转时，在当前窗口中进行页面跳转，不需要重新创建新窗口的跳转类型。跨窗口跳转类型是指路由跳转时，需要重新创建新窗口进行页面跳转的跳转类型。可选地，同窗口跳转类型至少包括文件夹型、内部模块、外部模块和内嵌类型等；跨窗口跳转类型至少包括链接型。其中，文件夹型是指组件对应的跳转类型是文件夹。内部模块型是指组件对应的跳转类型是应用系统内部的模块。外部模块类型是指组件对应的跳转类型是与应用系统位于同域(例如都属于同一一站式工作台)中的其它应用系统发布的模块。内嵌类型指的是组件对应的跳转类型是iframe，iframe会在当前窗口创建另外一个文档的内联框架，作用是显示文档中的文档(嵌套页面)。链接型是指组件对应的跳转类型是链接，跳转类型为链接时，应用端需要重新创建新窗口进行页面跳转，以显示链接对应的内容。进一步，组件的跳转类型还包括403跳转类型和404跳转类型。403跳转类型，用于在用户没有权限访问组件数据的情况下向用户返回403错误页面。404跳转类型，用于在用户没有为某个组件进行前端路由配置的情况下，即找到对应的组件数据时，向用户返回无法404错误页面。

基于上述，在配置组件数据的过程中，还包括配置至少部分组件对应的跳转类型。其中，一种配置包含组件之间的从属关系、组件的跳转路径参数以及跳转类型的组件数据的过程如下：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系、组件的跳转路径参数以及至少部分组件对应的跳转类型；以及根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数和跳转类型生成组件数据。

进一步可选地，在由配置人员发起为应用端配置组件数据的实施例中，配置组件数据的一种详细实施方式包括：显示应用端所支持的多级组件，多级组件包括至少部分组件；针对至少部分组件中的每个组件，响应配置人员针对组件发起的配置操作，展示组件对应的组件配置界面，组件配置界面上包含标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项；响应配置人员对针对标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项的输入操作，获取组件的标识信息、组件从属的上级组件以及组件对应的跳转类型和跳转路径参数。

如图1e所示，为组件配置界面的一种实现方式。该组件配置界面包括：代号配置项、名称配置项、父节点配置项、跳转类型配置项、参数配置项和地址配置项等；其中，代号配置项和名称配置项组合在一起可作为上述标识配置项，用来配置组件在系统内部的代号和名称，组件的代号和名称可唯一标识一个组件；父节点配置项用来配置组件从属的父级组件；参数配置项和地址配置项组合起来可实现为跳转路径配置项，用来配置组件对应的跳转路径参数，其中，参数和地址组合起来可唯一指向一个待显示页面组件；跳转类型配置项用来配置组件对应的跳转类型。进一步，如图1f所示，本实施例提供的跳转类型包括但不限于：文件夹型、内部模块型、外部模块型、iframe(内嵌模块)型和链接型。

在本申请实施例中，提供一种新的应用架构，在该应用架构中除了包括应用端和与应用端对应的服务端之外，还增加了路由配置端，路由配置端通过应用端所支持的组件为应用端进行前端路由的配置，应用端根据组件和路由配置端所配置的前端路由进行页面跳转。在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤21至步骤23的执行主体可以为设备A；又比如，步骤21和22的执行主体可以为设备A，步骤23的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如21、22等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图4为本申请示例性实施例提供的一种终端设备的结构示意图；如图4所示，该终端设备包括：存储器401和处理器402。

存储器401，用于存储应用端对应的计算机程序，并可被配置为存储其它各种数据以支持在终端设备上的操作。这些数据的示例包括用于在终端设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器401可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器402，与存储器401耦合，用于执行应用端对应的计算机程序，以用于：在用户发起访问请求的情况下获取组件数据，组件数据包含应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径；根据跳转路径加载待显示页面组件以实现页面跳转。可选地，若组件是菜单，则菜单数据包含前端应用所支持的至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数。

在一可选实施例中，处理器402在用户发起访问请求的情况下获取组件数据时，具体用于：判断用户是否是首次发起访问请求；若是，从应用系统中的服务端获取组件数据；若否，从本地缓存中获取组件数据。

在一可选实施例中，处理器402在根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，生成与访问请求对应的跳转路径时，具体用于：根据至少部分组件之间的从属关系，对至少部分组件对应的跳转路径参数进行拼接，以得到至少部分组件对应的静态路由数据；根据至少部分组件对应的静态路由数据中与访问请求匹配的目标静态路由数据，生成跳转路径。

在一可选实施例中，处理器402在根据至少部分组件对应的静态路由数据中与访问请求匹配的目标静态路由数据，生成跳转路径时，具体用于：将访问请求中携带的参数值和目标静态路由数据进行合并，以得到跳转路径。

在一可选实施例中，组件数据中还包含至少部分组件对应的跳转类型；处理器402在根据跳转路径加载待显示页面组件以实现页面跳转时，具体用于：结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转；其中，目标组件是至少部分组件中与目标静态路由数据对应的组件。

在一可选实施例中，处理器402在结合目标组件对应的跳转类型，根据跳转路径加载待显示页面组件以实现页面跳转时，具体用于：若目标组件对应的跳转类型为同窗口跳转类型，则根据各级组件与视图区域之间的对应关系，确定当前页面中与目标组件对应的目标视图区域；根据跳转路径加载待显示页面组件到目标视图区域中以实现页面跳转。

在一可选实施例中，同窗口跳转类型包括文件夹型、内部模块型、外部模块型以及内嵌类型；处理器402在根据跳转路径加载待显示页面组件到目标视图区域中以实现页面跳转时，具体用于：若目标组件对应的跳转类型为文件夹型，则根据跳转路径读取文件夹中的待显示页面组件，并将待显示页面组渲染至目标视图区域中；若目标组件对应的跳转类型为内部模块型，则根据跳转路径读取应用端发布的UI组件库中的待显示页面组件，并将待显示页面组件渲染至目标视图区域中；若目标组件对应的跳转类型为外部模块型，则根据跳转路径读取与应用端同域的其它应用发布的UI组件库中的待显示页面组件，并将待显示页面组件渲染至目标视图区域中；若目标组件对应的跳转类型为内嵌类型，则根据跳转路径读取与应用端跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件内嵌至目标视图区域中。

在一可选实施例中，处理器402在读取文件夹中的待显示页面组件之前，还用于：判断目标组件是否配置了直接引用跳转路径的信息项，若是，则根据跳转路径读取文件夹中的待显示页面组件。

在一可选实施例中，处理器402还用于：在目标组件对应的跳转类型为内部模块型或外部模块型的情况下，判断目标组件是否配置了明细界面的信息项；若是，读取明细界面对应的面包屑导航组件，并在面包屑导航组件被触发时将明细界面显示在目标视图区域中。

在一可选实施例中，处理器402还用于：若目标组件对应的跳转类型为跨窗口跳转类型，则根据跳转路径加载与应用端跨域的其它应用已渲染好的待显示页面组件，并将待显示页面组件显示在新窗口中。

在本申请实施例中，将组件、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，更加符合微服务思想中前后端解耦的目的，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

进一步，如图4所示，该终端设备还包括：通信组件406、显示器407、电源组件408、音频组件409等其它组件。图4中仅示意性给出部分组件，并不意味着终端设备只包括图4所示组件。需要说明的是，图4中虚线框内的组件为可选组件，而非必选组件，具体可视终端设备的产品形态而定。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述页面跳转方法实施例中可由终端设备执行的各步骤。

图5为本申请示例性实施例提供的一种配置设备的结构示意图；如图5所示，该配置设备包括：存储器501、处理器502和通信组件503。

存储器501，用于存储计算机程序，并可被配置为存储其它各种数据以支持在配置设备上的操作。这些数据的示例包括用于在配置设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器501可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器502，与存储器501耦合，用于执行计算机程序，以用于：通过通信组件503获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，为应用端生成组件数据。可选地，若组件是菜单，则至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数可以为至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数；相应地，为应用端生成的组件数据具体为菜单数据，该菜单数据包含至少部分菜单之间的从属关系以及至少部分菜单对应的跳转路径参数。

在一可选实施例中，处理器502在根据至少部分组件之间的从属关系以及至少部分组件对应的跳转路径参数，为应用端生成组件数据时，具体用于：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系以及部分组件对应的跳转路径参数；根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据。

在一可选实施例中，处理器502还用于：响应配置人员发起的配置操作，获取配置人员输入的至少部分组件对应的跳转类型；处理器502在根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数生成组件数据时，具体用于：根据至少部分组件之间的从属关系以及部分组件对应的跳转路径参数和跳转类型生成组件数据。

在一可选实施例中，处理器502在响应配置人员发起的配置操作，获取配置人员输入的至少部分组件之间的从属关系以及部分组件对应的跳转路径参数和跳转类型时，具体用于：显示应用端所支持的多级组件，多级组件包括至少部分组件；针对至少部分组件中的每个组件，响应配置人员针对组件发起的配置操作，展示组件对应的组件配置界面，组件配置界面上包含标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项；响应配置人员对针对标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项的输入操作，获取组件的标识信息、组件从属的上级组件以及组件对应的跳转类型和跳转路径参数。

在本申请实施例中，提供一种新的应用架构，在该应用架构中除了包括应用端和与应用端对应的服务端之外，还增加了路由配置端，路由配置端通过应用端所支持的组件为应用端进行前端路由的配置，应用端根据组件和路由配置端所配置的前端路由进行页面跳转。在本申请实施例中，将组件(如菜单)、路由、页面布局整合起来，使得前端路由的配置与应用端进一步解耦，更加符合微服务思想中前后端解耦的目的，可以让前端路由的配置更为灵活，从而更加灵活的控制页面显示和跳转；另外，还可以使应用端更加专注应用内容和应用逻辑的开发，提高应用端的服务质量。

进一步，如图5所示，该配置设备还包括：显示器507、电源组件508、音频组件509等其它组件。图5中仅示意性给出部分组件，并不意味着配置设备只包括图5所示组件。需要说明的是，图5中虚线框内的组件为可选组件，而非必选组件，具体可视配置设备的产品形态而定。本实施例的配置设备可以实现为台式电脑、笔记本电脑或智能手机等终端设备，也可以是常规服务器、云服务器或服务器阵列等服务端设备。若本实施例的配置设备实现为台式电脑、笔记本电脑、智能手机等终端设备，可以包含图5中虚线框内的组件；若本实施例的配置设备实现为常规服务器、云服务器或服务器阵列等服务端设备，则可以不包含图5中虚线框内的组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述路由配置方法实施例中可由配置设备执行的各步骤。

上述图4和图5中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还可以包括近场通信(NFC)模块，射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术等。

上述图4和图5中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述图4和图5中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述图4和图5中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (26)

1.一种应用系统，其特征在于，包括：应用端、路由配置端和服务端；

所述路由配置端，用于为所述应用端配置组件数据并保存至所述服务端；所述组件数据包含所述应用端所支持的至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数；

所述应用端，用于在用户发起访问请求的情况下获取所述组件数据；根据所述组件数据中包含的所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，生成与所述访问请求对应的跳转路径；根据所述跳转路径加载待显示页面组件以实现页面跳转。

2.根据权利要求1所述的应用系统，其特征在于，所述应用端在获取所述组件数据时，用于：

判断用户是否是首次发起访问请求；若是，从所述服务端获取所述组件数据；若否，从本地缓存中获取所述组件数据。

3.根据权利要求1所述的应用系统，其特征在于，所述应用端在生成所述跳转路径时，用于：

根据所述至少部分组件之间的从属关系，对所述至少部分组件对应的跳转路径参数进行拼接，以得到所述至少部分组件对应的静态路由数据；

根据所述至少部分组件对应的静态路由数据中与所述访问请求匹配的目标静态路由数据，生成所述跳转路径。

4.根据权利要求3所述的应用系统，其特征在于，所述应用端在生成所述跳转路径时，用于：

将所述访问请求中携带的参数值和所述目标静态路由数据进行合并，以得到所述跳转路径。

5.根据权利要求3所述的应用系统，其特征在于，所述组件数据中还包含所述至少部分组件对应的跳转类型，所述应用端在根据所述跳转路径加载待显示页面组件以实现页面跳转时，用于：

结合目标组件对应的跳转类型，根据所述跳转路径加载待显示页面组件以实现页面跳转；

其中，所述目标组件是所述至少部分组件中与所述目标静态路由数据对应的组件。

6.根据权利要求5所述的应用系统，其特征在于，所述应用端在结合目标组件对应的跳转类型，根据所述跳转路径加载待显示页面组件以实现页面跳转时，用于：

若所述目标组件对应的跳转类型为同窗口跳转类型，则根据各级组件与视图区域之间的对应关系，确定当前页面中与所述目标组件对应的目标视图区域；根据所述跳转路径加载待显示页面组件到所述目标视图区域中以实现页面跳转。

7.根据权利要求6所述的应用系统，其特征在于，所述应用端还用于：

若所述目标组件对应的跳转类型为跨窗口跳转类型，则根据所述跳转路径加载与所述应用端跨域的其它应用已渲染好的待显示页面组件，并将所述待显示页面组件显示在新窗口中。

8.根据权利要求1-7任一项所述的应用系统，其特征在于，所述应用端采用三级路由视图架构，所述至少部分组件包括所述应用端支持的一级菜单和末级菜单，所述前端应用的首页面对应一级路由视图，所述一级菜单对应二级路由视图，所述末级菜单对应三级路由视图；其中，所述一级路由视图包含二级路由视图，所述二级路由视图包含所述三级路由视图。

9.一种页面跳转方法，适用于应用端，其特征在于，所述方法包括：

在用户发起访问请求的情况下获取组件数据，所述组件数据包含所述应用端所支持的至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数；

根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，生成与所述访问请求对应的跳转路径；

根据所述跳转路径加载待显示页面组件以实现页面跳转。

10.根据权利要求9所述的方法，其特征在于，在用户发起访问请求的情况下获取组件数据，包括：

判断用户是否是首次发起访问请求；若是，从应用系统中的服务端获取所述组件数据；若否，从本地缓存中获取所述组件数据。

11.根据权利要求9所述的方法，其特征在于，根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，生成与所述访问请求对应的跳转路径，包括：

根据所述至少部分组件之间的从属关系，对所述至少部分组件对应的跳转路径参数进行拼接，以得到所述至少部分组件对应的静态路由数据；

根据所述至少部分组件对应的静态路由数据中与所述访问请求匹配的目标静态路由数据，生成所述跳转路径。

12.根据权利要求11所述的方法，其特征在于，根据所述至少部分组件对应的静态路由数据中与所述访问请求匹配的目标静态路由数据，生成所述跳转路径，包括：

将所述访问请求中携带的参数值和所述目标静态路由数据进行合并，以得到所述跳转路径。

13.根据权利要求11所述的方法，其特征在于，所述组件数据中还包含所述至少部分组件对应的跳转类型；根据所述跳转路径加载待显示页面组件以实现页面跳转，包括：

结合目标组件对应的跳转类型，根据所述跳转路径加载待显示页面组件以实现页面跳转；

其中，所述目标组件是所述至少部分组件中与所述目标静态路由数据对应的组件。

14.根据权利要求13所述的方法，其特征在于，结合目标组件对应的跳转类型，根据所述跳转路径加载待显示页面组件以实现页面跳转，包括：

若所述目标组件对应的跳转类型为同窗口跳转类型，则根据各级组件与视图区域之间的对应关系，确定当前页面中与所述目标组件对应的目标视图区域；

根据所述跳转路径加载待显示页面组件到所述目标视图区域中以实现页面跳转。

15.根据权利要求14所述的方法，其特征在于，所述同窗口跳转类型包括文件夹型、内部模块型、外部模块型以及内嵌类型；根据所述跳转路径加载待显示页面组件到所述目标视图区域中以实现页面跳转，包括：

若所述目标组件对应的跳转类型为文件夹型，则根据所述跳转路径读取文件夹中的待显示页面组件，并将所述页面组渲染至所述目标视图区域中；

若所述目标组件对应的跳转类型为内部模块型，则根据所述跳转路径读取所述应用端发布的UI组件库中的待显示页面组件，并将所述待显示页面组件渲染至所述目标视图区域中；

若所述目标组件对应的跳转类型为外部模块型，则根据所述跳转路径读取与所述应用端同域的其它应用发布的UI组件库中的待显示页面组件，并将所述待显示页面组件渲染至所述目标视图区域中；

若所述目标组件对应的跳转类型为内嵌类型，则根据所述跳转路径读取与所述应用端跨域的其它应用已渲染好的待显示页面组件，并将所述待显示页面组件内嵌至所述目标视图区域中。

16.根据权利要求15所述的方法，其特征在于，在读取文件夹中的待显示页面组件之前，还包括：

判断所述目标组件是否配置了直接引用跳转路径的信息项，若是，则根据所述跳转路径读取文件夹中的待显示页面组件。

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

在所述目标组件对应的跳转类型为内部模块型或外部模块型的情况下，判断所述目标组件是否配置了明细界面的信息项；若是，读取所述明细界面对应的面包屑导航组件，并在所述面包屑导航组件被触发时将所述明细界面显示在所述目标视图区域中。

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

若所述目标组件对应的跳转类型为跨窗口跳转类型，则根据所述跳转路径加载与所述应用端跨域的其它应用已渲染好的待显示页面组件，并将所述待显示页面组件显示在新窗口中。

19.根据权利要求18所述的方法，其特征在于，所述至少部分组件为应用端所支持的至少部分菜单，所述组件数据为包含至少部分菜单之间的从属关系以及所述至少部分菜单对应的跳转路径参数的菜单数据。

20.一种路由配置方法，适用于应用系统中的路由配置端，其特征在于，所述方法包括：

获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数；

根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，为所述应用端生成组件数据。

21.根据权利要求20所述的方法，其特征在于，根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，为所述应用端生成组件数据，包括：

响应配置人员发起的配置操作，获取所述配置人员输入的所述至少部分组件之间的从属关系以及所述部分组件对应的跳转路径参数；

根据所述至少部分组件之间的从属关系以及所述部分组件对应的跳转路径参数生成组件数据。

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

响应配置人员发起的配置操作，获取所述配置人员输入的所述至少部分组件对应的跳转类型；

根据所述至少部分组件之间的从属关系以及所述部分组件对应的跳转路径参数生成组件数据，包括：根据所述至少部分组件之间的从属关系以及所述部分组件对应的跳转路径参数和跳转类型生成组件数据。

23.根据权利要求22所述的方法，其特征在于，响应配置人员发起的配置操作，获取所述配置人员输入的所述至少部分组件之间的从属关系以及所述部分组件对应的跳转路径参数和跳转类型，包括：

显示所述应用端所支持的多级组件，所述多级组件包括所述至少部分组件；

针对所述至少部分组件中的每个组件，响应配置人员针对所述组件发起的配置操作，展示所述组件对应的组件配置界面，所述组件配置界面上包含标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项；

响应配置人员针对所述标识配置项、父节点配置项、跳转类型配置项以及跳转路径配置项的输入操作，获取所述组件的标识信息、所述组件从属的上级组件以及所述组件对应的跳转类型和跳转路径参数。

24.一种终端设备，其特征在于，包括：存储器和处理器；

所述存储器，用于存储应用端对应的计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：在用户发起访问请求的情况下获取组件数据，所述组件数据包含所述应用端所支持的至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数；根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，生成与所述访问请求对应的跳转路径；根据所述跳转路径加载待显示页面组件以实现页面跳转。

25.一种配置设备，其特征在于，包括：存储器、处理器和通信组件；

所述存储器，用于存储路由配置端对应的计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：通过通信组件获取应用系统中的应用端所支持的至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数；根据所述至少部分组件之间的从属关系以及所述至少部分组件对应的跳转路径参数，为所述应用端生成组件数据。

26.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使所述处理器实现权利要求9-23任一项所述方法中的步骤。

Images