CN113342340A - 组件渲染方法及装置 - Google Patents

Abstract

本公开关于一种组件渲染方法及装置；所述方法包括：接收目标用户帐户针对目标组件的渲染请求；确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

Description

组件渲染方法及装置

技术领域

本公开涉及计算机应用领域，尤其涉及组件渲染方法及装置。

背景技术

通常，互联网业务系统可以面向业务团队提供多种业务功能，其中，业务团队中的成员可以被分配不同的权限，并依照权限调用该业务系统中的业务功能。随着业务的扩展，上述业务系统中的业务功能也会逐渐增多，团队成员、权限与业务功能之间的逻辑关系也会越来越复杂。

相关技术中，为了实现互联网业务系统终端权限管理，可以在具体实现业务功能的各种组件中，针对不同权限编写不同的渲染方式。客户端从权限管理后台获取当前用户帐户的权限类型，各种组件就可以根据权限类型选择渲染方式，从而向用户帐户展示预期的组件形态。

但是，采用上述方法，上述组件与权限的关系一旦发生变化，就需要重新编写渲染方式执行代码，扩展性和可维护性都较差。

发明内容

有鉴于此，本公开提供了组件渲染方法及装置，以至少解决相关技术中效率偏低的技术问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提出了一种组件渲染方法，所述方法包括：

接收目标用户帐户针对目标组件的渲染请求；

确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

可选的，所述确定目标用户帐户的角色，包括：

从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识；

查询预设的角色表，确定与所述目标用户帐户的用户帐户标识对应的角色。

可选的，所述方法还包括：

接收角色配置请求；

将所述角色配置请求中携带的用户帐户标识与角色的对应关系，写入所述角色表中。

可选的，所述根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件，包括：

查询预设的功能权限表，确定所述目标用户帐户的角色对应的目标功能权限；

查询预设的组件表，确定所述目标用户帐户以所述目标功能权限有权访问的组件。

可选的，所述方法还包括：

接收功能权限配置请求；

将所述功能权限配置请求中携带的角色与功能权限的对应关系写入所述功能权限表中。

可选的，所述方法还包括：

接收组件配置请求；

将所述组件配置请求中携带的功能权限与组件的对应关系写入所述组件表中。

可选的，所述用户界面包括前端路由组件；所述方法还包括：

将所述目标用户帐户请求渲染的目标组件的标识输入所述前端路由组件；

若与所述前端路由组件关联的路由信息中包括与所述目标用户帐户请求渲染的目标组件的标识对应的有效路由信息，则确定所述目标用户帐户请求渲染的目标组件属于所述目标用户帐户有权访问的组件。

可选的，在所述确定所述目标用户帐户有权访问的组件之后，所述方法还包括：

标记所述目标用户帐户有权访问的组件的标识对应的路由信息为有效路由信息。

可选的，所述方法还包括：

对与所述前端路由组件关联的路由信息进行筛选，保留被标记为有效路由信息的路由信息；

加载所述前端路由组件。

可选的，所述方法还包括：

在属于所述目标用户帐户有权访问的组件的目标组件的数量小于或等于预设数量阈值的情况下，在所述目标用户帐户的用户界面上渲染预设的提示组件，所述提示组件用于提示权限不足。

根据本公开实施例的第二方面，提出了另一种组件渲染方法，应用于服务端，包括：

接收目标用户帐户针对目标组件的渲染请求；

确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

根据本公开实施例的第三方面，提出了一种组件渲染装置，所述装置包括：

接收模块，被配置为接收目标用户帐户针对目标组件的渲染请求；

第一确定模块，被配置为确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

渲染模块，被配置为在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

根据本公开实施例的第四方面，提出了另一种组件渲染装置，应用于服务端，其特征在于，包括：

接收模块，被配置为接收目标用户帐户针对目标组件的渲染请求；

第一确定模块，被配置为确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

第一发送模块，被配置为向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

根据本公开实施例的第五方面，提出了一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述任一实施例所述的组件渲染方法。

根据本公开实施例的第六方面，提出一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的组件渲染方法。

根据本公开实施例的第七方面，提出一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现上述任一实施例所述的组件渲染方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

以上技术方案中，一方面，由于根据目标用户帐户的角色确定了目标用户帐户有权访问的组件，因此可以在目标用户帐户请求渲染的目标组件属于该目标用户帐户有权访问的组件的情况下，在目标用户帐户的用户界面上渲染上述目标组件，从而保证目标用户帐户的用户界面上只有目标用户帐户有权访问的组件，也就实现了基于角色的权限管控；

另一方面，由于确定目标用户帐户有权访问的组件等权限管理相关的功能并不依赖组件内部的代码实现，因此实现了权限管理与组件业务的代码解耦合，即使目标用户帐户有权访问的组件发生变化，组件本身的代码也无需进行修改，显著提升了代码的扩展性和可维护性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书文本一同用于解释原理，并不构成对本公开的不当限定。

图1是本公开示出的一种基于角色的访问控制机制的示意图；

图2是一示例性实施例示出的一种组件渲染方法的流程图；

图3是一示例性实施例示出的一种不同角色进入同一页面后的组件渲染示意图；

图4是一示例性实施例示出的另一种组件渲染方法的流程图；

图5是一示例性实施例示出的一种组件渲染装置的示意框图；

图6是一示例性实施例示出的另一组件渲染装置的示意框图；

图7是一示例性实施例示出的一种电子设备的结构图。

具体实施方式

为了使本技术领域的人员更好地理解本公开一个或多个实施例中的技术方案，下面将结合本公开一个或多个实施例中的附图，对本公开一个或多个实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是一部分实施例，而不是全部的实施例。基于本公开一个或多个实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的系统和方法的例子。

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

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

通常，互联网业务系统可以面向业务团队提供多种业务功能，其中，业务团队中的成员可以分配有不同的权限，并依照权限调用该业务系统中的业务功能，完成互联网业务；随着业务的扩展，上述业务系统中的业务功能也会逐渐增多，团队成员、权限与业务功能之间的逻辑关系也会越来越复杂。

以电商平台为例，随着电商团队的扩张和业务的发展，一套“电商业务系统”可能会提供订单发货、商品详情页更新、订单模板管理、店铺信息修改等等复杂功能，而其中店铺信息修改功能可能只允许店铺的管理层人员使用，订单发货功能可能仅允许流程人员使用，而商品详情页更新内容可能只允许店铺的内容工作组成员使用，等等。

相关技术中，为了实现互联网业务系统终端权限管理，可以在具体实现业务功能的各种组件中，针对不同权限开发不同的渲染方式。客户端从权限管理后台获取当前用户帐户的权限类型，各种组件就可以根据权限类型选择渲染方式，从而向用户帐户展示预期的组件形态。继续以前述电商平台情景为例，同样一个订单发货页面，员工甲和员工乙分别在进行访问时，就有可能由于两者的权限类型不同，导致同样的组件选择了不同的渲染方式，最终呈现出不同的组件形态，也就提供了基于权限的不同功能。

但是，采用上述方法，上述组件与权限的关系一旦发生变化，就需要重新编写具体渲染方式的执行代码。例如，假设原先商品详情页编辑功能对应的组件中已经通过逻辑代码的方式实现了“针对具有A类权限的用户帐户，以X分支对本组件进行渲染”的功能，一旦新增了需求，需要补充一条“针对具有B类权限的用户帐户，以Y分支对本组件进行渲染”，那么就只能对该组件中的逻辑代码进行重构，并在重构完成之后更新软件版本。

显然，相关技术方案的扩展性和可维护性都较差。

基于此，本公开提出一种将权限的控制与实现业务功能的组件解耦合，并根据目标用户帐户有权访问的组件来决定是否对目标用户帐户所请求渲染的目标组件进行渲染的技术方案。

在实现时，可以通过目标用户帐户的角色来确定目标用户帐户有权访问的组件，再根据目标组件是否属于上述目标用户帐户有权访问的组件，确定是否在目标用户帐户的用户界面上渲染上述目标组件。

本公开实施例提供的方案可以视为一种基于角色的访问控制机制的方案。请参见图1，图1为本公开示出的一种基于角色的访问控制机制的示意图；在该例中，每一个用户帐户在业务系统中都可以对应若干个角色，而每一种角色又可以对应若干种具体的权限，而每一种权限又可以对应到若干实现具体业务功能的所需的资源。举例而言，如果某用户帐户在业务系统中对应仓库管理员角色，而仓库管理员角色则具备访问库存流水的权限，该访问库存流水的权限则进一步意味着其有权调用查询按钮、流水列表、库存缩略图等等软件资源。因此，确定一个用户帐户的角色，就能够通过上述机制确定出该用户帐户有权调用的资源。类似的，本方案中确定目标用户帐户的角色，就可以确定出该目标用户帐户有权访问的组件。

以上技术方案中，一方面，由于根据目标用户帐户的角色确定了目标用户帐户有权访问的组件，因此可以在目标用户帐户请求渲染的目标组件属于该目标用户帐户有权访问的组件的情况下，在目标用户帐户的用户界面上渲染上述目标组件，从而保证目标用户帐户的用户界面上只有目标用户帐户有权访问的组件，也就实现了基于角色的权限管控；

另一方面，由于确定目标用户帐户有权访问的组件等权限管理相关的功能并不依赖组件内部的代码实现，实现了权限管理与组件业务的代码解耦合，因此即使目标用户帐户有权访问的组件发生变化，组件本身的代码也无需进行修改，显著提升了代码的扩展性和可维护性。

下面通过具体实施例并结合具体的应用场景对技术方案进行描述。

请参考图2，图2是一示例性实施例示出的一种组件渲染方法的流程图；本示例中，该方法可以应用于交互系统，包括下列S201、S202、S203步骤。

上述交互系统，可以包括任意由客户端和服务端，服务端可以包括任意形式的、用于控制客户端进行用户界面渲染的服务器，例如单台服务器、服务器集群、云服务器等等；而客户端则可以包括任意的具有界面渲染能力的电子设备，例如可以渲染网页界面的手机、平板电脑，以及可以渲染界面的台式计算机、专用柜台机、圈存机等等。在一些情况下，上述交互系统中的服务端和客户端亦可以集成在同一台物理设备上，例如，在服务器上直接运行可以相互通信的服务端和客户端。

上述目标组件，可以是任意需要在业务系统中的用户界面上完成渲染，以提供对应的业务功能的组件；例如，对于电商管理系统而言，上述目标组件可以是用于上传新的商品详情页的图片上传控件，也可以是用于输入新的店铺信息的文本输入框，还可以是发起订单发货流程的发货按钮等等。

可以理解的是，上述电商管理是一便于描述的可行实施场景，本领域技术人员亦可以根据具体需求将上述方案适配到其他的业务场景、业务系统中，例如公司内部的办公自动化系统、视频网站的内容管理系统等等，本公开无需进行全部列举。

亦可以理解的是，上述业务系统的具体软件架构，既可以采用浏览器/服务端架构，也可以采用客户端/服务端架构；对于具体的软件实现方式，本领域技术人员可以根据具体需求自行选择，本公开无需列举全部可行方案。

上述角色，可以是上述业务系统中用于确定用户帐户对于各个组件的访问权限的分类标签。属于同一角色的用户帐户，对于该角色对应的组件有相同的访问权限。例如，假设用户帐户张三与用户帐户李四均属于“物流登记员”的角色，那么“物流登记员”这一角色对应的“发货单号登记”、“发货提醒”等功能组件，用户帐户张三与用户帐户李四均有权访问。

可以理解的是，在本公开中，对于多种角色而言，其对应的组件亦可以存在重叠；例如，无论是“物流登记员”，还是“网络管理员”，都可以有权访问“修改个人密码”这一功能组件。

亦可以理解的是，在本公开中，同一个用户帐户，也可以具有多个角色；例如，用户帐户张三在该系统中兼职物流登记和售后接待，因此用户帐户张三的角色可以包括“物流登记员”和“售后接待员”。

S201，接收目标用户帐户针对目标组件的渲染请求。

在本公开中，上述服务端可以首先获取目标用户帐户的渲染请求，其中，该渲染请求中可以携带所针对的目标组件的标识。获取该渲染请求的具体方式，可以是接收到来自客户端的交互指令，也可以是从计划任务等服务端内部调用机制中获取；例如，用户王五希望每天早上8:00的时候使用该业务系统拍摄自己的工作状态，则王五既可以在每天早上8:00通过客户端向服务端发起针对摄像组件的渲染请求，也可以通过在服务端中设置计划任务的方式，在每天早上8:00定时触发一个针对摄像组件的渲染请求。本公开并不限制渲染请求的传入方式。

可以理解的是，上述组件的标识的结构以及生成机制，既可以是按照逻辑架构进行编码，例如，使用8位整型数形式的标识，其中前4位代表组件所属的业务环节，后4位代表业务环节内组件的编号，等等；还可以是根据组件的部分或全部代码生成的散列值等等。不同的标识结构以及生成机制，可以产生不同的技术效果，例如按照逻辑架构进行编码可以显著增强标识的可读性，而采用生成散列值的方式生成标识，则可以减少新增组件时可能需要额外付出的软件开发工作。

因此，对于本领域技术人员而言，可以根据具体的实践需求，自行设计上述业务系统中各个组件的标识生成机制，对此本公开亦无需进行进一步限定。

S202，确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件。

在本公开中，上述服务端可以确定上述目标用户帐户的角色，并根据上述目标用户帐户的角色确定上述目标用户帐户有权访问的组件。具体而言，目标用户帐户的角色，可以根据目标用户帐户的标识进行查表得到。或者，目标用户帐户的角色也可以通过对上述渲染请求或者该目标用户帐户的登录信息中解析得到，例如，上述渲染请求中可以预设一个标识位，该标识位中可以存储指示该目标用户帐户的角色的标识，对该渲染请求进行解析，可获知该目标用户帐户的角色。

因此，本申请无需对确定目标用户帐户的角色的具体方式进行全部列举，本领域技术人员可以根据具体需求自行选择。

可以理解的是，上述确定目标用户帐户的角色的步骤，与上述接收目标用户帐户针对目标组件的渲染请求的步骤，两者的可以先后执行，也可并行执行，在先后执行时两者的间隔时间亦无需进行限定，两者之间既可以存在条件触发关系，也可以不存在。本公开并不限制上述S201步骤与S202步骤的具体执行时序。

在一实施例中，上述服务端确定目标用户帐户的角色的方式，具体可以是查表的方式。具体而言，可以首先从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识，再查询预设的角色表，确定与该目标用户帐户的用户帐户标识对应的角色。例如，该目标用户帐户是已经登录到上述业务系统中的用户帐户，那么在该目标用户帐户发起上述渲染请求之前，上述业务系统就可以预先从该目标用户帐户的登录信息中，获取到该目标用户帐户的用户帐户标识；之后，再查询存储有用户帐户标识与角色的对应关系的角色表，确定该目标用户帐户的角色。

可以理解的是，如果采用从上述渲染请求中获取用户帐户标识的方式为从目标用户帐户的渲染请求中获取，则上述步骤S201则可以在步骤S202之前完成。

在一实施例中，上述方法中还可以包括对于上述角色表的配置步骤。具体而言，上述服务端可以首先接收角色配置请求；再将该角色配置请求中携带的用户帐户标识与角色的对应关系，写入到该角色表中。举例来说，如果希望用户帐户张三暂时兼职X工作岗，那么只需要响应于携带有X工作岗和用户帐户张三的用户帐户标识的对应关系的角色配置请求，将X工作岗添加到用户帐户张三对应的角色字段中即可。

采用上述方式，系统中可以通过维护上述角色表的方式，更加灵活地配置用户权限。

在一实施例中，上述根据目标用户帐户的角色确定目标用户帐户有权访问的组件的方式，也可以通过查表的方式完成。具体而言，查询的表可以包含功能权限表和组件表共两张表，上述服务端可以首先查询预设的功能权限表，确定该目标用户帐户的角色对应的目标功能权限，再查询预设的组件表，确定该目标用户帐户以该目标功能权限有权访问的组件。

如前述图1中示例，在基于角色的访问控制机制下，在角色层(相当于本公开中的角色)与资源(相当于本公开中的组件)层之间，还可以包括一层权限层。举例而言，对于“超级管理员”和“普通用户帐户”两者角色而言，两者虽然在角色层存在差异，但在权限层中可以具有相同的、修改自身登录密码的功能权限，而修改自身登录密码的功能权限又可能进一步对应到诸如文本输入框、字符串规则校验器等等多个组件；如果不采用上述三层机制，例如仅采用角色层和资源层两层配置，则用户帐户的角色将直接关联到有权使用的资源，难以维护；因此，在本公开中通过功能权限表以及组件表来实现从用户帐户的角色-到对应的目标功能权限-再到对应的有权访问的组件的映射关系，能够更好地适应角色与权限之间存在交叉的实际应用情景，也能通过对权限层的复用，降低权限维护的难度。

在一实施例中，上述方法中还可以包括对于上述功能权限表的配置步骤。具体而言，上述服务端接收功能权限配置请求；再将该功能权限配置请求中携带的角色与功能权限的对应关系写入到该功能权限表中。举例来说，如果希望X工作岗的员工具有Y功能权限，那么响应于携带有X工作岗和Y功能权限的对应关系的功能权限配置请求，将Y功能权限添加到X工作岗对应的功能权限字段中即可。

在一实施例中，上述方法中还可以包括对于上述组件表的配置步骤。具体而言，上述服务端接收组件配置请求；再将该组件配置请求中携带的功能权限与组件的对应关系写入到该组件表中。举例来说，如果更新后的Y功能权限需要使用Z组件，那么需要响应于携带有Y功能权限和Z组件的对应关系的组件配置请求，将Z组件添加到Y功能权限对应的组件字段中即可。

S203，在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

在本示例中，在上述目标组件属于上述目标用户帐户有权访问的组件的情况下，可以在上述目标用户帐户的用户界面中渲染上述目标组件。请参见图3，图3是一示例性实施例示出的不同角色进入同一页面后的组件渲染示意图；在该示例中，图3(a)展示了店主角色进入页面后的组件渲染示意图，由于店主账号拥有运费模板编辑的功能权限，因此店主账号登录后的页面会显示其有权访问的新增运费模板按钮、复制按钮、编辑按钮、删除按钮；图3(b)展示了普通管理员角色进入页面后的组件渲染示意图，由于普通管理员不具有运费模板编辑的功能权限，因此普通管理员登录后的页面中，其无权访问的新增运费模板按钮、复制按钮、编辑按钮、删除按钮都不会展示。

可以理解的是，上述目标组件是否属于上述目标用户帐户有权访问的组件，客户端可以通过预设的判断逻辑完成判断，其中该判断逻辑可以基于前述确定出的目标用户帐户有权访问的组件构建得到；例如，客户端可以从服务端接收到目标用户帐户有权访问的组件的标识组成的集合，并以此构建用于判断输入的标识是否属于上述集合的判断逻辑；客户端将上述目标用户帐户请求渲染的目标组件的标识输入上述判断逻辑，即可根据判断逻辑的输出结果，确定上述目标用户帐户请求渲染的目标组件是否属于上述目标用户帐户有权访问的组件。

以JavaScript环境为例，为了方便封装，可以使用高阶组件(Higher-Order-Component)实现上述判断逻辑；高阶组件通常指将现有组件作为输入参数，用于返回新组件的逻辑，并且可以在高阶组件内部预设可供复用的数据处理逻辑；在实现上述判断逻辑时，可以使用高阶组件包裹上述目标用户帐户有权访问的组件，则该高阶组件中的数据处理逻辑可以获取并使用上述目标用户帐户有权访问的组件的标识，进而判断请求渲染的目标组件是否属于上述目标用户帐户有权访问的组件，也就实现了上述判断逻辑。假设已经确定上述目标用户帐户有权访问的组件的标识分别为key_1，key_2，key_3，…key_n，那么向高阶组件输入请求渲染的目标组件的标识，上述数据处理逻辑即可返回指示输入的标识是否为上述高阶组件中key_1，key_2，key_3，…key_n中之一的布尔值，该高阶组件即可根据该布尔值确定返回请求渲染的目标组件，还是指示无权访问的空白组件。

采用此方法，高阶组件可以包裹其他组件的特性，将权限的判断逻辑集中到高阶组件中，以便与上述目标用户帐户有权访问的组件解耦。

在一实施例中，上述用户界面可以包括前端路由组件；前端路由组件，用于在动态网页中解析URL并匹配路由信息，以实现在不进行跳转和刷新的情况下，对匹配到的路由信息中的组件进行渲染，进而触发预期功能；因此，前端路由组件可以对组件的渲染起到指导作用。在接收到渲染请求并查询渲染请求对应的前端路由信息时，可以将上述目标用户帐户请求渲染的目标组件的标识输入上述前端路由组件，如果上述前端路由组件关联的路由信息中包括与上述目标用户帐户请求渲染的目标组件的标识对应的有效路由信息，则可以确定上述目标用户帐户请求渲染的目标组件属于上述目标用户帐户有权访问的组件。

可以理解的是，若请求渲染的目标组件属于上述目标用户帐户有权访问的组件，则上述前端路由组件可以返回有效路由信息，进而指导渲染目标组件；若请求渲染的目标组件不属于上述目标用户帐户有权访问的组件，则上述前端路由组件则可能查询不到对应的路由信息，或者查询到的路由信息未被标记为有效路由信息，前端路由组件可以返回预设的查询失败信息，也可以返回指向预设的空白组件的路由信息，在此种情况下，页面就无法对目标组件进行渲染。

可见，使用前端路由组件实现上述判断逻辑，可以充分利用网页界面渲染中现有的前端路由机制，提高本方案对现有技术的兼容性。

在另一实施例中，在确定上述目标用户帐户有权访问的组件之后，上述服务端可以对上述网页界面的前端路由组件进行配置，具体而言，可以将与该前端路由组件关联的路由信息中，与上述目标用户帐户有权访问的组件的标识对应的路由信息标记为有效路由信息；由于同一个目标用户帐户可能发起多次渲染请求，因此服务端在确定上述目标用户帐户有权访问的组件之后对上述网页界面的前端路由组件进行配置，可以使后续该目标用户帐户发起其他渲染请求时，实现对前端路由组件的复用，可以提高业务系统运行的效率。

在一实施例中，上述客户端还可以对上述前端路由组件关联的路由信息进行筛选，从而实现选择性加载路由信息；具体而言，可以在加载上述前端路由组件之前，对该前端路由组件关联的路由信息进行筛选，保留其中被标记为有效路由信息的路由信息。例如，假设当前系统中有1000个组件，其中当前目标用户帐户有权访问的组件有200个，可以预知，对于除上述目标用户帐户有权访问的200个组件以外的其他800个组件对应的路由信息而言，即使完成了加载、并且用户界面收到了对应的渲染请求，也会被权限控制机制拦截，最终不会被渲染；因而可以认为，类似上述其他800个组件的路由信息即使不被加载，也不会影响用户界面的正常运行。

因此，通过预先筛选的方式，保留被标记为有效路由信息的、实际对应目标用户帐户有权访问的组件对应的路由信息，不加载目标用户帐户无权访问的组件对应的路由信息，不仅可以保证前述权限管理的严格，还能够一定程度上加快前端路由的加载速度。

在一实施例中，针对目标用户帐户请求渲染、但被判定为目标用户帐户无权访问的组件，可以使用其他的组件进行替换渲染或展示。例如，可以将原组件直接以空白填补，或者提示组件；还可以确定属于所述目标用户帐户有权访问的组件的目标组件的数量是否小于或等于预设数量阈值，如果是，则可以在所述目标用户帐户的用户界面上渲染展示“出错”、“无权限”等用于提示权限不足的提示组件。

可以理解的是，除此之外，还可以设计404页面丢失等提示信息，本公开并不限制提示信息和/或提示组件的具体形式。

应用上述方案，可以在属于所述目标用户帐户有权访问的组件的目标组件的数量过少的情况下，通过上述用户界面向目标用户帐户发出对应的提示，改善用户帐户体验。

上述内容即为本公开针对所述组件渲染方法的全部实施例。基于上述实施例可知，应用本公开提出的组件渲染方法，由于可以根据目标用户帐户的角色确定其有权访问的组件集合，再进一步根据目标用户帐户所请求渲染的目标组件是否属于上述集合，确定是否进行渲染，因此，上述组件渲染方法能够实现基于角色的组件渲染控制；而且，上述方案中由于权限控制逻辑与组件的业务逻辑解耦，可以根据具体需求分别进行维护和更新，因此还能够提升实现上述功能的代码的扩展性和可维护性。

本公开还提供了应用于服务端的一种组件渲染方法；请参见图4，图4是本公开示出的另一种组件渲染方法的流程示例图；该例中，该方法可以应用于服务端，包括如下S401至S403步骤。

S401，接收目标用户帐户针对目标组件的渲染请求。

在本示例中，上述服务端可以首先获取目标用户帐户的渲染请求，其中，该渲染请求中可以携带所针对的目标组件的标识。获取该渲染请求的具体方式，可以是接收到来自客户端的交互指令，也可以是从计划任务等服务端内部调用机制中获取，本公开并不限制渲染请求的传入方式。

S402，确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件。

在本公开中，上述服务端可以确定上述目标用户帐户的角色，并根据上述目标用户帐户的角色确定上述目标用户帐户有权访问的组件。具体而言，目标用户帐户的角色，既可以根据目标用户帐户的标识进行查表得到，也可以通过对上述渲染请求或者该目标用户帐户的登录信息中解析得到。可以理解的是，上述确定目标用户帐户的角色的步骤，与上述接收目标用户帐户针对目标组件的渲染请求的步骤，两者的可以先后执行，也可并行执行，在先后执行时两者的间隔时间亦无需进行限定，两者之间既可以存在条件触发关系，也可以不存在。本公开并不限制上述S401步骤与S402步骤的具体执行时序。

在一实施例中，上述服务端确定目标用户帐户的角色的方式，具体可以是查表的方式。具体而言，可以首先从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识，再查询预设的角色表，确定与该目标用户帐户的用户帐户标识对应的角色。

在一实施例中，上述方法中还可以包括对于上述角色表的配置步骤。具体而言，上述服务端可以首先接收角色配置请求；再将该角色配置请求中携带的用户帐户标识与角色的对应关系，写入到该角色表中。

采用上述方式，系统中可以通过维护上述角色表的方式，更加灵活地配置用户权限。

在一实施例中，上述根据目标用户帐户的角色确定目标用户帐户有权访问的组件的方式，也可以通过查表的方式完成。具体而言，查询的表可以包含功能权限表和组件表共两张表，上述服务端可以首先查询预设的功能权限表，确定该目标用户帐户的角色对应的目标功能权限，再查询预设的组件表，确定该目标用户帐户以该目标功能权限有权访问的组件。

在一实施例中，上述方法中还可以包括对于上述功能权限表的配置步骤。具体而言，上述服务端接收功能权限配置请求；再将该功能权限配置请求中携带的角色与功能权限的对应关系写入到该功能权限表中。

在一实施例中，上述方法中还可以包括对于上述组件表的配置步骤。具体而言，上述服务端接收组件配置请求；再将该组件配置请求中携带的功能权限与组件的对应关系写入到该组件表中。

S403，向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

在本示例中，服务端可以在确定上述目标用户帐户有权访问的组件之后，向目标用户帐户对应的客户端发送指示目标用户帐户有权访问的组件的第一信息，从而使得该客户端可以根据该第一信息的指示，确定请求渲染的目标组件是否为目标用户帐户有权访问的组件，并在确认是的情况下在该目标用户帐户的用户界面上渲染该目标组件。在实际应用中，上述第一信息可以是直接包含所有目标用户帐户有权访问的组件的标识的列表，也可以是指向存储有目标用户帐户有权访问的组件的标识列表的存储地址等等，本公开无需具体限定上述第一信息的具体形式。

在一实施例中，上述第一信息可以是与上述用户界面中的前端路由组件关联的路由信息，而该路由信息中可以包括与上述目标用户帐户有权访问的组件的标识对应的路由信息。可以理解的是，上述客户端加载上述前端路由组件后，若请求渲染的目标组件属于上述目标用户帐户有权访问的组件，则该前端路由组件可以返回有效路由信息，进而指导页面完成目标组件的渲染；若请求渲染的目标组件不属于上述目标用户帐户有权访问的组件，则上述前端路由组件则可能查询不到对应的路由信息，或者查询到的路由信息未被标记为有效路由信息，前端路由组件可以返回预设的查询失败信息，也可以返回指向预设的空白组件的路由信息，在此种情况下，客户端就无法对目标组件进行渲染。

可见，使用前端路由组件实现对于请求渲染的目标组件是否属于上述目标用户帐户有权访问的组件的判断，可以充分利用网页界面渲染中现有的前端路由机制，提高本方案对现有技术的兼容性；服务端通过下发前端路由组件对应的路由信息的方式，实现了对于客户端是否渲染目标组件的间接控制。

在另一实施例中，在确定上述目标用户帐户有权访问的组件之后，可以对上述网页界面的前端路由组件进行配置，具体而言，可以将与该前端路由组件关联的路由信息中，与上述目标用户帐户有权访问的组件的标识对应的路由信息标记为有效路由信息；应用该方案，可以使后续该目标用户帐户发起其他渲染请求时，实现对前端路由组件的复用，可以提高业务系统运行的效率。

在一实施例中，上述服务端可以在将上述与上述网页界面中的前端路由组件关联的路由信息发送至上述目标用户帐户对应的客户端之前，对与上述前端路由组件相关联的路由信息进行筛选，保留被标记为有效路由信息的路由信息。与前述在客户端上执行的筛选过程类似，保留被标记为有效路由信息的、实际对应目标用户帐户有权访问的组件对应的路由信息，不加载目标用户帐户无权访问的组件对应的路由信息，不仅可以保证前述权限管理的严格，还能够一定程度上加快前端路由的加载速度。

可以理解的是，上述筛选过程如果在客户端完成，则服务端没有额外的数据处理环节，可以降低服务端的处理压力；若在服务端完成，则发送到客户端的路由信息即为筛选后的路由信息，可以减少对于网络带宽资源的需求。本领域技术人员可以根据具体的业务场景需求自行选择具体实现方案。

在一实施例中，上述服务端还可以在属于上述目标用户帐户有权访问的组件的目标组件的数量小于或等于预设数量阈值的情况下，向上述目标用户帐户对应的客户端发送第二信息，该第二信息用于指示上述客户端在上述目标用户帐户的用户界面上渲染“出错”、“无权限”等用于提示权限不足的提示组件。

应用上述方案，可以在属于所述目标用户帐户有权访问的组件的目标组件的数量过少的情况下，通过上述客户端的用户界面向目标用户帐户发出对应的提示，改善用户帐户体验。

本领域技术人员应知，上述应用于服务端的组件渲染方法中未进一步示出的示例，可以参见前述应用于整个交互系统的组件渲染方法的实施例完成。

本公开还提供了对应的组件渲染装置的实施例如下：

请参见图5，图5是一示例性实施例示出的一种组件渲染装置的示意框图；本示例中，该装置可以应用于交互系统，包括接收模块501、第一确定模块502和渲染模块503；具体而言，上述

接收模块501，可以被配置为接收目标用户帐户针对目标组件的渲染请求。

第一确定模块502，可以被配置为确定目标用户帐户的用户帐户角色，根据所述目标用户帐户的用户帐户角色确定所述目标用户帐户有权访问的组件。

渲染模块503，可以被配置为在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

在一实施例中，上述第一确定模块502确定目标用户帐户的用户帐户角色的方式，具体可以是查表的方式；具体而言，第一确定模块502可以首先从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识，再查询预设的用户帐户角色表，确定与该目标用户帐户的用户帐户标识对应的用户帐户角色。例如，该目标用户帐户是已经登录到上述业务系统中的用户帐户，那么在该目标用户帐户发起上述渲染请求之前，上述第一确定模块602就可以预先从该目标用户帐户的登录信息中，获取到该目标用户帐户的用户帐户标识；之后，再查询存储有用户帐户标识与用户帐户角色的对应关系的用户帐户角色表，确定该目标用户帐户的用户帐户角色。

可以理解的是，如果采用从上述渲染请求中获取用户帐户标识的方式为从目标用户帐户的渲染请求中获取，则上述接收模块501则可以先于第一确定模块502调用。

在一实施例中，上述装置中还可以包括用于对于上述用户帐户角色表进行配置的第一写入模块。具体而言，上述第一写入模块可以首先接收用户帐户角色配置请求；再将该用户帐户角色配置请求中携带的用户帐户标识与用户帐户角色的对应关系，写入到该用户帐户角色表中。举例来说，如果希望用户帐户张三暂时兼职X工作岗，那么只需要响应于携带有X工作岗和用户帐户张三的用户帐户标识的对应关系的用户帐户角色配置请求，将X工作岗添加到用户帐户张三对应的用户帐户角色字段中即可。

采用上述方式，系统中可以通过维护上述用户帐户角色表的方式，更加灵活地配置用户权限。

在一实施例中，上述第一确定模块502根据目标用户帐户的用户帐户角色确定目标用户帐户有权访问的组件的方式，也可以通过查表的方式完成。具体而言，查询的表可以是包含功能权限表和组件表共两张表，上述第一确定模块502可以首先查询预设的功能权限表，确定该目标用户帐户的用户帐户角色对应的目标功能权限，再查询预设的组件表，确定该目标用户帐户以该目标功能权限有权访问的组件。

如前所述，在基于角色的访问控制机制下，在角色层(相当于本公开中的用户帐户角色)与资源(相当于本公开中的组件)层之间，还可以包括一层权限层；举例而言，对于“超级管理员”和“普通用户帐户”两者用户帐户角色而言，虽然两者角色不同，但都可以具有通用的修改自身登录密码的功能权限，而修改自身登录密码的功能权限又可能进一步对应到诸如文本输入框、字符串规则校验器等等多个组件；因此，在本公开中，可以通过功能权限表以及组件表来实现从用户帐户的用户帐户角色，到对应的目标功能权限，再到对应的有权访问的组件这一映射关系，能够更好地适应角色与权限之间存在交叉的实际应用情景，也能通过对权限层的复用，降低权限维护的难度。

在一实施例中，上述装置中还可以包括用于对于上述功能权限表进行配置的第二写入模块。具体而言，上述第二写入模块接收功能权限配置请求；再将该功能权限配置请求中携带的用户帐户角色与功能权限的对应关系写入到该功能权限表中。举例来说，如果希望X工作岗的员工具有Y功能权限，那么响应于携带有X工作岗和Y功能权限的对应关系的功能权限配置请求，将Y功能权限添加到X工作岗对应的功能权限字段中即可。

在一实施例中，上述装置中还可以包括用于对于上述组件表进行配置的第三写入模块。具体而言，上述第三写入模块接收组件配置请求；再将该组件配置请求中携带的功能权限与组件的对应关系，写入到该组件表中。举例来说，如果更新后的Y功能权限需要使用Z组件，那么只需要响应于携带有Y功能权限和Z组件的对应关系的组件配置请求，将Z组件添加到Y功能权限对应的组件字段中即可。

在一实施例中，上述用户界面中可以包括前端路由组件；上述装置还可以包括第二确定模块，该模块可以将上述目标用户帐户请求渲染的目标组件的标识输入上述前端路由组件，如果上述前端路由组件关联的路由信息中包括与上述目标用户帐户请求渲染的目标组件的标识对应的有效路由信息，则可以确定上述目标用户帐户请求渲染的目标组件属于上述目标用户帐户有权访问的组件。

可以理解的是，若请求渲染的目标组件属于上述目标用户帐户有权访问的组件，则上述前端路由组件可以返回有效路由信息，进而指导页面渲染目标组件；若请求渲染的目标组件不属于上述目标用户帐户有权访问的组件，则上述前端路由组件则可能查询不到对应的路由信息，或者查询到的路由信息未被标记为有效路由信息，前端路由组件可以返回预设的查询失败信息，也可以返回指向预设的空白组件的路由信息，在此种情况下，页面就无法对目标组件进行渲染。

可见，使用前端路由组件实现上述判断逻辑，可以充分利用网页界面渲染中现有的前端路由机制，提高本方案对现有技术的兼容性。

在另一实施例中，上述装置还可以包括标记模块，该模块可以被配置为，在确定上述目标用户帐户有权访问的组件之后，对上述网页界面的前端路由组件进行配置，具体而言，可以将与该前端路由组件关联的路由信息中，与上述目标用户帐户有权访问的组件的标识对应的路由信息标记为有效路由信息；应用该方案，可以使后续该目标用户帐户发起其他渲染请求时，实现对前端路由组件的复用，可以提高业务系统运行的效率。

在一实施例中，上述装置中还可以包括筛选模块和加载模块，用于选择性加载上述前端路由相关联的路由信息；具体而言，上述筛选模块可以被配置为，对前端路由组件相关联的路由信息进行筛选，保留其中被标记为有效路由信息的路由信息，上述加载模块则可以被配置为加载上述路由信息进行筛选后的前端路由组件用户帐户。例如，假设当前系统中有1000个组件，其中当前目标用户帐户有权访问的组件有200个，虽然理论上可加载路由信息的组件有1000个，然而除上述目标用户帐户有权访问的200个组件以外的其他800个组件的路由信息，即使完成了加载、并且收到了对应的渲染请求，也会被权限控制机制拦截，最终不会被渲染，因此类似上述其他800个组件的路由信息即使不被加载，也不会影响用户界面的正常运行。

因此，通过预先筛选的方式，保留被标记为有效路由信息的、实际对应目标用户帐户有权访问的组件对应的路由信息，不加载目标用户帐户无权访问的组件对应的路由信息，不仅可以保证前述权限管理的严格，还能够一定程度上加快前端路由的加载速度。

在一实施例中，上述装置中还可以包括提示模块，该模块可以被配置为针对目标用户帐户请求渲染、但被判定为目标用户帐户无权访问的组件，使用其他的组件进行替换渲染或展示。例如，可以将原组件直接以空白填补，或者提示组件；还可以确定属于所述目标用户帐户有权访问的组件的目标组件的数量是否小于或等于预设数量阈值，如果是，则可以在所述目标用户帐户的用户界面上渲染展示“出错”、“无权限”等用于提示权限不足的提示组件。

可以理解的是，除此之外，还可以设计404页面丢失等提示信息，本公开并不限制提示信息和/或提示组件的具体形式。

请参见图6，图6是一示例性实施例示出的另一种组件渲染装置的示意框图；本示例中，该装置可以应用于服务端，包括接收模块601、第一确定模块602和第一发送模块603；具体而言，上述

接收模块601，可以被配置为接收目标用户帐户针对目标组件的渲染请求。

第一确定模块602，可以被配置为确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件。

第一发送模块603，可以被被配置为向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

在一实施例中，上述第一确定模块602确定目标用户帐户的角色的方式，具体可以是查表的方式；具体而言，第一确定模块602可以首先从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识，再查询预设的角色表，确定与该目标用户帐户的用户帐户标识对应的角色。例如，该目标用户帐户是已经登录到上述业务系统中的用户帐户，那么在该目标用户帐户发起上述渲染请求之前，上述第一确定模块602就可以预先从该目标用户帐户的登录信息中，获取到该目标用户帐户的用户帐户标识；之后，再查询存储有用户帐户标识与角色的对应关系的角色表，确定该目标用户帐户的角色。

可以理解的是，如果采用从上述渲染请求中获取用户帐户标识的方式为从目标用户帐户的渲染请求中获取，则上述接收模块601则可以先于第一确定模块602调用。

在一实施例中，上述装置中还可以包括用于对于上述角色表进行配置的第一写入模块。具体而言，上述第一写入模块可以首先接收角色配置请求；再将该角色配置请求中携带的用户帐户标识与角色的对应关系，写入到该角色表中。采用上述方式，系统中可以通过维护上述角色表的方式，更加灵活地配置用户权限。

在一实施例中，上述第一确定模块602根据目标用户帐户的角色确定目标用户帐户有权访问的组件的方式，也可以通过查表的方式完成。具体而言，查询的表可以是包含功能权限表和组件表共两张表，上述第一确定模块602可以首先查询预设的功能权限表，确定该目标用户帐户的角色对应的目标功能权限，再查询预设的组件表，确定该目标用户帐户以该目标功能权限有权访问的组件。通过功能权限表以及组件表来实现从用户帐户的角色，到对应的目标功能权限，再到对应的有权访问的组件这一映射关系，能够更好地适应角色与权限之间存在交叉的实际应用情景，也能通过对权限层的复用，降低权限维护的难度。

在一实施例中，上述装置中还可以包括用于对于上述功能权限表进行配置的第二写入模块。具体而言，上述第二写入模块接收功能权限配置请求；再将该功能权限配置请求中携带的角色与功能权限的对应关系写入到该功能权限表中。

在一实施例中，上述装置中还可以包括用于对于上述组件表进行配置的第三写入模块。具体而言，上述第三写入模块接收组件配置请求；再将该组件配置请求中携带的功能权限与组件的对应关系，写入到该组件表中。

在一实施例中，上述用户界面是包括前端路由组件的网页界面上述第一发送模块被进一步配置为：将上述与上述网页界面中的前端路由组件关联的路由信息发送至上述目标用户帐户对应的客户端；其中，上述路由信息中包括与上述目标用户帐户有权访问的组件的标识对应的路由信息。在此情况下，上述客户端将上述目标用户帐户请求渲染的目标组件的标识输入上述前端路由组件，如果上述前端路由组件关联的路由信息中，包括与上述目标用户帐户请求渲染的目标组件的标识对应的有效路由信息，则可以确定上述目标用户帐户请求渲染的目标组件属于上述目标用户帐户有权访问的组件。

可以理解的是，若请求渲染的目标组件属于上述目标用户帐户有权访问的组件，则上述前端路由组件可以返回有效路由信息，进而指导页面完成目标组件的渲染；若请求渲染的目标组件不属于上述目标用户帐户有权访问的组件，则上述前端路由组件则可能查询不到对应的路由信息，或者查询到的路由信息未被标记为有效路由信息，前端路由组件可以返回预设的查询失败信息，也可以返回指向预设的空白组件的路由信息，在此种情况下，客户端就无法对目标组件进行渲染。

可见，使用前端路由组件实现对于请求渲染的目标组件是否属于上述目标用户帐户有权访问的组件的判断，可以充分利用网页界面渲染中现有的前端路由机制，提高本方案对现有技术的兼容性。

在另一实施例中，上述装置还可以包括标记模块，该模块可以被配置为，在将上述与上述网页界面中的前端路由组件关联的路由信息发送至上述目标用户帐户对应的客户端之前，将与上述网页界面中的前端路由组件关联的路由信息中，与上述目标用户帐户有权访问的组件的标识对应的路由信息，标记为有效路由信息；应用该方案，可以使后续该目标用户帐户发起其他渲染请求时，实现对前端路由组件的复用，可以提高业务系统运行的效率。

在一实施例中，上述装置中还可以包括筛选模块，可以被配置为，在将所述与所述网页界面中的前端路由组件关联的路由信息发送至所述目标用户帐户对应的客户端之前，对与所述前端路由组件相关联的路由信息进行筛选，保留被标记为有效路由信息的路由信息。通过预先筛选的方式，保留被标记为有效路由信息的、实际对应目标用户帐户有权访问的组件对应的路由信息，不加载目标用户帐户无权访问的组件对应的路由信息，不仅可以保证前述权限管理的严格，还能够一定程度上加快前端路由的加载速度。

在一实施例中，上述装置中还可以包括第二发送模块，该模块可以被配置为在属于所述目标用户帐户有权访问的组件的目标组件的数量小于或等于预设数量阈值的情况下，向所述目标用户帐户对应的客户端发送第二信息，该第二信息用于指示客户端针对目标用户帐户请求渲染、但被判定为目标用户帐户无权访问的组件，使用其他的组件进行替换渲染或展示。例如，可以将原组件直接以空白填补，或者提示组件；还可以确定属于所述目标用户帐户有权访问的组件的目标组件的数量是否小于或等于预设数量阈值，如果是，则可以在所述目标用户帐户的用户界面上渲染展示“出错”、“无权限”等用于提示权限不足的提示组件。

可以理解的是，除此之外，还可以设计404页面丢失等提示信息，本领域技术人员可以根据具体需求进行补充设计，本公开无需进行进一步补充。

关于上述实施例中的装置，其中各模块的具体实现方式，已经在描述对应方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本公开的实施例还提出一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的组件渲染方法。

本公开的实施例还提出一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的组件渲染方法。

本公开的实施例还提出一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现上述任一实施例所述的组件渲染方法。

图7是根据本公开的实施例示出的一种电子设备的示意框图。参照图7，电子设备700可以包括以下一个或多个组件：处理组件702，存储器704，电源组件706，多媒体组件708，音频组件710，输入/输出(I/O)的接口712，传感器组件714，以及通信组件718。上述电子设备/服务器可以采用类似的硬件架构。

处理组件702通常控制电子设备700的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述组件渲染方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在电子设备700的操作。这些数据的示例包括用于在电子设备700上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件706为电子设备700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为电子设备700生成、管理和分配电力相关联的组件。

多媒体组件708包括在电子设备700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件708包括一个前置摄像头和/或后置摄像头。当电子设备700处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的或具有焦距和光学变焦能力的光学透镜系统。

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

I/O接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为电子设备700提供各个方面的状态评估。例如，传感器组件714可以检测到电子设备700的打开/关闭状态，组件的相对定位，例如所述组件为电子设备700的显示器和小键盘，传感器组件714还可以检测电子设备700或电子设备700一个组件的位置改变，用户帐户与电子设备700接触的存在或不存在，电子设备700方位或加速/减速和电子设备700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

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

在本公开一实施例中，电子设备700可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述组件渲染方法。

在本公开一实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器704，上述指令可由电子设备700的处理器720执行以完成上述组件渲染方法。例如，所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

需要说明的是，在本公开中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。

Claims (10)

1.一种组件渲染方法，其特征在于，所述方法包括：

接收目标用户帐户针对目标组件的渲染请求；

确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

2.根据权利要求1所述的方法，其特征在于，所述确定目标用户帐户的角色，包括：

从目标用户帐户的渲染请求或登录信息中，获取目标用户帐户的用户帐户标识；

查询预设的角色表，确定与所述目标用户帐户的用户帐户标识对应的角色。

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

接收角色配置请求；

将所述角色配置请求中携带的用户帐户标识与角色的对应关系，写入所述角色表中。

4.根据权利要求1所述的方法，其特征在于，所述根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件，包括：

查询预设的功能权限表，确定所述目标用户帐户的角色对应的目标功能权限；

查询预设的组件表，确定所述目标用户帐户以所述目标功能权限有权访问的组件。

5.一种组件渲染方法，应用于服务端，其特征在于，包括：

接收目标用户帐户针对目标组件的渲染请求；

确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

6.一种组件渲染装置，其特征在于，所述装置包括：

接收模块，被配置为接收目标用户帐户针对目标组件的渲染请求；

第一确定模块，被配置为确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

渲染模块，被配置为在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

7.一种组件渲染装置，应用于服务端，其特征在于，包括：

接收模块，被配置为接收目标用户帐户针对目标组件的渲染请求；

第一确定模块，被配置为确定目标用户帐户的角色，根据所述目标用户帐户的角色确定所述目标用户帐户有权访问的组件；

第一发送模块，被配置为向所述目标用户帐户对应的客户端发送指示所述目标用户帐户有权访问的组件的第一信息，所述第一信息用于指示所述客户端在所述目标组件属于所述目标用户帐户有权访问的组件的情况下，在所述目标用户帐户的用户界面上渲染所述目标组件。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至5中任一项所述的组件渲染方法。

9.一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至5中任一项所述的组件渲染方法。

10.一种计算机程序产品，包括计算机程序/指令，其特征在于，所述计算机程序/指令被处理器执行时实现权利要求1至5中任一项所述的组件渲染方法。

Images