本发明涉及计算机技术领域，尤其涉及一种实现页面功能复用的方法及装置。
背景技术：
随着互联网的迅速发展，互联网应用为用户提供的功能越来越丰富，相应地，互联网应用所包含的页面随之增加，以为用户实现丰富的功能。
对于互联网应用而言，各页面可能存在相同的页面功能，也可能存在不同的页面功能。
传统的设计方案是在互联网应用的各页面中部署各自的页面功能，各页面之间不存在页面功能复用，这就导致互联网应用开发过于复杂，不利于提高开发效率，进而浪费过多的开发成本。
技术实现要素：
为了解决上述技术问题，本发明的一个目的在于提供一种实现页面功能复用的方法及装置。
其中，本发明所采用的技术方案为：
一方面，一种实现页面功能复用的方法，包括：根据互联网应用所提供页面功能进行组件封装，得到多个系统组件，每一个系统组件对应所述互联网应用提供的一种页面功能；通过触发进行的互联网应用登录操作为所述互联网应用进行页面加载，并为加载的页面构建浮动框架；根据所加载页面所具有的页面功能，在所述浮动框架中动态嵌入对应于页面功能的系统组件。
另一方面，一种实现页面功能复用的装置，包括：组件封装模块，用于根据互联网应用所提供页面功能进行组件封装，得到多个系统组件，每一个系统组件对应所述互联网应用提供的一种页面功能；页面加载模块，用于通过触发进行的互联网应用登录操作为所述互联网应用进行页面加载，并为加载的页面构建浮动框架；组件嵌入模块，用于根据所加载页面所具有的页面功能，在所述浮动框架中动态嵌入对应于页面功能的系统组件。
在一示例性实施例中，所述装置还包括：框架构建模块，用于针对所述互联网应用所加载的多个页面，进行多个浮动框架的树形结构连接，构建主浮动框架；数据传输模块，用于通过构建的主浮动框架为动态嵌入在各浮动框架中的系统组件提供数据传输功能。
在一示例性实施例中，所述主浮动框架为common路由层；相应地，所述数据传输模块包括：数据发送单元，用于为发送系统组件向所述common路由层发起数据传输请求；位置获取单元，用于按照所述数据传输请求指示的接收系统组件，获取所述接收系统组件在所述common路由层中的路由位置；数据接收单元，用于根据获取到的路由位置向所述接收系统组件发送所述数据传输请求。
在一示例性实施例中，所述数据发送单元包括：数据封装子单元，用于按照指定格式对所述发送系统组件待传输数据进行封装，得到封装数据；指定接口发送子单元，用于根据所述封装数据由指定send接口发送所述数据传输请求至所述common路由层。
在一示例性实施例中，所述数据接收单元包括：确定接收系统组件子单元，用于根据所述路由位置确定所述common路由层中接收所述数据传输请求的接收系统组件；指定接口接收子单元，用于控制所述接收系统组件通过指定receive接口由所述common路由层接收所述数据传输请求；数据解封装子单元，用于从所述数据传输请求中提取得到所述封装数据，并按照所述指定格式对所述封装数据进行解封装处理。
在一示例性实施例中，所述位置获取单元包括：标识提取子单元，用于从所述数据传输请求中提取用于标识所述接收系统组件的id；位置关联查找子单元，用于根据用于标识所述接收系统组件的id在所述common路由层的注册表中进行路由位置关联查找，所述注册表存储了id与路由位置的关联关系；位置定义子单元，用于以关联查找到的路由位置作为所述id所标识的接收系统组件在所述common路由层中的路由位置。
另一方面，一种实现页面功能复用的装置，包括处理器及存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上所述的实现页面功能复用的方法。
另一方面，一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的实现页面功能复用的方法。
在上述技术方案中，通过对互联网应用所提供的页面功能进行组件封装，进而得到多个系统组件，并通过触发进行的互联网应用登录操作为互联网应用进行页面加载，为加载的页面构建浮动框架，进而使得浮动框架中根据所加载页面所具有的页面功能进行对应系统组件的动态嵌入，也就是说，不同页面如果存在相同的页面功能，由于每一种页面功能对应一个系统组件，故而被动态嵌入至为不同页面所构建浮动框架中的系统组件是相同的，由此实现了页面功能复用，进而降低了互联网应用的开发复杂度，有利于提高开发效率，从而节省了开发成本。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。
图1是根据一示例性实施例示出的一种实现页面功能复用的装置的硬件结构框图。
图2是根据一示例性实施例示出的一种实现页面功能复用的方法的流程图。
图3是根据一示例性实施例示出的另一种实现页面功能复用的方法的流程图。
图4是图3对应实施例中步骤430在一个实施例的流程图。
图5是图4对应实施例中步骤431在一个实施例的流程图。
图6是图4对应实施例中步骤435在一个实施例的流程图。
图7是图4对应实施例中步骤433在一个实施例的流程图。
图8是一应用场景中一种实现页面功能复用的方法所涉及的common路由层的具体实现示意图。
图9是根据一示例性实施例示出的一种实现页面功能复用的装置的框图。
通过上述附图，已示出本发明明确的实施例，后文中将有更详细的描述，这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。
具体实施方式
这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
图1是根据一示例性实施例示出的一种实现页面功能复用的装置的硬件结构框图。需要说明的是，该装置只是一个适配于本发明的示例，不能认为是提供了对本发明的使用范围的任何限制。该装置也不能解释为需要依赖于或者必须具有图1中示出的示例性的装置200中的一个或者多个组件。
该装置200的硬件结构可因配置或者性能的不同而产生较大的差异，如图1所示，装置200包括：电源210、接口230、至少一存储器250、以及至少一中央处理器(cpu,centralprocessingunits)270。
其中，电源210用于为装置200上的各硬件设备提供工作电压。
接口230包括至少一有线或无线网络接口231、至少一串并转换接口233、至少一输入输出接口235以及至少一usb接口237等，用于与外部设备通信。
存储器250作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统251、应用程序253及数据255等，存储方式可以是短暂存储或者永久存储。其中，操作系统251用于管理与控制装置200上的各硬件设备以及应用程序253，以实现中央处理器270对海量数据255的计算与处理，其可以是windowsservertm、macosxtm、unixtm、linuxtm、freebsdtm等。应用程序253是基于操作系统251之上完成至少一项特定工作的计算机程序，其可以包括至少一模块(图1中未示出)，每个模块都可以分别包含有对装置200的一系列计算机可读指令。数据255可以是存储于磁盘中的照片、图片等。
中央处理器270可以包括一个或多个以上的处理器，并设置为通过总线与存储器250通信，用于运算与处理存储器250中的海量数据255。
如上面所详细描述的，适用本发明的装置200将通过中央处理器270读取存储器250中存储的一系列计算机可读指令的形式来完成实现页面功能复用的方法。
此外，通过硬件电路或者硬件电路结合软件也能同样实现本发明，因此，实现本发明并不限于任何特定硬件电路、软件以及两者的组合。
请参阅图2，在一示例性实施例中，一种实现页面功能复用的方法适用于实现页面功能复用的装置，该装置的结构可以如图1所示。
该种实现页面功能复用的方法可以由实现页面功能复用的装置执行，可以包括以下步骤：
步骤310，根据互联网应用所提供页面功能进行组件封装，得到多个系统组件。
如前所述，对于互联网应用而言，各页面可能存在相同的页面功能，也可能存在不同的页面功能。
以保险营销应用为例，至少包含保单销售页面和保单售后页面，保单销售页面包括软电话拨打、保单录入、保单校验、保单销售结果提交等页面功能，保单售后页面包括软电话拨打、保单跟踪、保单缴费、保单维护结果提交等页面功能。其中，软电话拨打功能即属于保单销售页面和保单售后页面共同存在的相同页面功能。
为了后续页面功能复用得以实现，本实施例中，首先通过组件封装获得多个系统组件，使得每一个系统组件对应互联网应用提供的一种页面功能。
具体而言，根据互联网应用所提供的页面功能将该页面功能所涉及的数据进行封装，由此得到多个系统组件，也可以理解为，系统组件是页面功能所涉及数据的集合。
由上可知，对于同一个页面所具有的多种页面功能而言，将封装得到多个不同的系统组件，而针对不同页面之间存在的相同页面功能，仅封装得到一个共同的系统组件。
步骤330，通过触发进行的互联网应用登录操作为互联网应用进行页面加载，并为加载的页面构建浮动框架。
也就是说，不同的互联网登录操作将使得互联网应用加载不同的页面，并最终在互联网应用中显示出不同的页面。
仍以保险营销应用为例，销售人员登录时，为保险营销应用加载保单销售页面，即保险营销应用的显示页面中显示保单销售页面；或者，售后人员登录时，为保险营销应用加载保单售后页面，即保险营销应用的显示页面中显示保单售后页面。
具体地，互联网应用为用户提供一个登录入口，当用户希望登录互联网应用时，便能够在该登录入口触发相应的互联网登录操作。
随着互联网登录操作的触发进行，互联网应用将获取到用户相关的登录信息，该登录信息包括但不限于用户登录账号、登录密码、登录组别等等，进而根据用户相关的登录信息进行相应页面的加载。例如，如果用户的登录组别为销售人员，则为保险营销应用加载保单销售页面。
进一步地，本实施例中，互联网应用进行页面显示是通过浮动框架(iframe框架)实现的，为此，针对互联网应用所加载的页面，将进行浮动框架的构建，使得所加载页面可基于该浮动框架在互联网应用中进行浮动显示。
步骤350，根据所加载页面所具有的页面功能，在浮动框架中动态嵌入对应于页面功能的系统组件。
在完成浮动框架构建之后，便能够基于该浮动框架在互联网应用中进行页面的浮动显示。
具体地，根据所加载页面所具有的页面功能确定对应的系统组件，将对应的系统组件嵌入为该页面构建的浮动框架中，由于系统组件视为页面功能所涉及数据的集合，因此，系统组件嵌入浮动框架，实质上是根据对应页面功能所涉及的数据进行页面基于浮动框架的浮动显示，进而使得用户通过在线访问浮动显示的页面而享受到互联网应用所提供的功能。
进一步地，动态嵌入，是指系统组件的嵌入将随着页面功能的变化而相应地变化，例如，页面的某一个页面功能被删减，则该某一个页面功能所对应的系统组件将相应地由为该页面所构建的浮动框架中删除，以此增强页面功能设置的灵活性。
通过如上所述的过程，实现了页面功能的复用，进而降低了互联网应用的开发复杂度，有利于提高开发效率，从而节省了开发成本。
在一应用场景中，针对保险营销应用所提供的软电话拨打功能、保单校验功能分别获得软电话拨打组件、保单校验组件。
由此，假设保单销售页面包括软电话拨打功能和保单校验功能，则为保单销售页面所构建的浮动框架中将嵌入软电话拨打组件和保单校验组件。
假设保单售后页面包括软电话拨打功能，则为保单售后页面所构建的浮动框架中嵌入软电话拨打组件。
由上可知，软电话拨打组件可以分别嵌入在为保单销售页面和保单售后页面所构建的浮动框架中，进而实现了软电话拨打功能的复用。
请参阅图3，在一示例性实施例中，如上所述的方法还可以包括以下步骤：
步骤410，针对互联网应用所加载的多个页面，进行多个浮动框架的树形结构连接，构建主浮动框架。
可以理解，对于同一页面来说，动态嵌入在为同一页面所构建的浮动框架中的各系统组件之间可以相互通信，即实现相同域通信，而对于不同页面而言，由于存在跨域问题，则动态嵌入在为各页面所分别构建的浮动框架中的各系统组件不能彼此访问，即存在无法跨域通信的问题。
为此，本实施例中，针对为互联网应用所加载多个页面而分别构建的多个浮动框架，将为该多个浮动框架构建公共的主浮动框架。
具体地，主浮动框架，由多个浮动框架通过树形结构连接形成。换而言之，树形结构中，主浮动框架视为父节点，而多个浮动框架分别为子节点。而对于页面显示过程来说，通过主浮动框架进行主页面显示的同时，还可以通过浮动框架将构建其的页面浮动于主页面之外显示。
步骤430，通过构建的主浮动框架为动态嵌入在各浮动框架中的系统组件提供数据传输功能。
如上所述，主浮动框架和各浮动框架存在父节点与子节点的树形结构关系，由此，各浮动框架中的系统组件之间便能够基于该树形结构关系进行数据传输。
也就是说，即使各系统组件之间并不知道对方在树形结构中的具体位置，但是各系统组件所在的浮动框架均与主浮动框架之间连接，即各系统组件知道主浮动框架在树形结构中的具体位置，进而便能够以主浮动框架作为中间节点，将不知道对方具体位置的系统组件之间相互连接在一起，由此实现跨域通信。
在一实施例的具体实现中，主浮动框架为common路由层。
相应地，如图4所示，步骤430可以包括以下步骤：
步骤431，为发送系统组件向common路由层发起数据传输请求。
发送系统组件，是指需要发送数据的系统组件。相应地，接收系统组件，是指进行数据接收的系统组件。
如前所述，由于发送系统组件和接收系统组件可能并不属于为同一个页面所构建的浮动框架，进而不能彼此访问，存在跨域通信问题，即发送系统组件虽然知道需要向接收系统组件发送数据，但是并不清楚怎么将数据传输至接收系统组件。
为此，发送系统组件将向common路由层发起数据传输请求，以请求common路由层为其进行数据转发。其中，数据传输请求指示了发送系统组件需要进行数据传输的接收系统组件。
需要说明的是，无论是发送系统组件，还是接收系统组件，都是通过id进行唯一标识的，例如，ida唯一地标识系统组件a。
步骤433，按照数据传输请求指示的接收系统组件，获取接收系统组件在common路由层中的路由位置。
如前所述，数据传输请求用于指示接收系统组件，则对于common路由层而言，在接收到数据传输请求之后，便能够获知发送系统组件需要将数据传输至哪一个接收系统组件。
为了将数据传输至数据传输请求指示的接收系统组件，common路由层还需要获知该接收系统组件在common路由层中的路由位置。
common路由层是由各浮动框架进行树形结构连接形成的，而系统组件被动态嵌入在浮动框架中，因此，在形成common路由层时，各系统组件都会在common路由层中注册自身相对于common路由层的路由位置，以此形成common路由层的注册表。
简言之，common路由层通过注册表存储了动态嵌入浮动框架的系统组件在common路由层中的路由位置。
相应地，common路由层所在的路由位置也将存储于各系统组件中，以便于各系统组件能够根据该路由位置向common路由层发起数据传输请求。
由上可知，在获知接收系统组件之后，common路由层将通过注册表进一步地获知该接收系统组件在common路由层中的路由位置。
如图7所示，在一实施例的具体实现中，步骤433可以包括以下步骤：
步骤4331，从数据传输请求中提取用于标识接收系统组件的id。
步骤4333，根据用于标识接收系统组件的id在common路由层的注册表中进行路由位置关联查找，注册表存储了id与路由位置的关联关系。
步骤4335，以关联查找到的路由位置作为id所标识的接收系统组件在common路由层中的路由位置。
也就是说，注册表的形成，实质上是在用于标识接收系统组件的id与路由位置之间建立了关联关系。可以理解，id不同，其所标识的系统组件将有所区别，进而使得此系统组件在common路由层中的路由位置也各不相同。
由此，在获取到用于标识接收系统组件的id之后，便可以通过注册表查找到与此id具有关联关系的路由位置，即可实现id所标识接收系统组件在common路由层中路由位置的确定。
步骤435，根据获取到的路由位置向接收系统组件发送数据传输请求。
在获得接收系统组件在common路由层中的路由位置之后，便能够在发送系统组件与接收系统组件之间建立传输路由，以通过该传输路由将数据传输请求由发送系统组件传输至接收系统组件，进而实现彼此的数据传输。
通过上述过程，利用common路由层中的注册表，实现了系统组件之间传输路由的建立，进而为系统组件之间的彼此访问提供了依据，使得系统组件之间的跨域通信得以实现。
请参阅图5，在一示例性实施例中，步骤431可以包括以下步骤：
步骤4311，按照指定格式对发送系统组件待传输数据进行封装，得到封装数据。
步骤4313，根据封装数据由指定send接口发送数据传输请求至common路由层。
具体而言，数据传输请求是根据封装数据生成的，即数据传输请求中携带了封装数据。其中，封装数据是按照指定格式对待传输数据进行封装得到的。
在生成数据传输请求之后，发送系统组件将通过指定send接口将携带了封装数据的数据传输请求发送至common路由层。
相应地，如图6所示，步骤435可以包括以下步骤：
步骤4351，根据路由位置确定common路由层中接收数据传输请求的接收系统组件。
步骤4353，控制接收系统组件通过指定receive接口由common路由层接收数据传输请求。
步骤4355，从数据传输请求中提取得到封装数据，并按照指定格式对封装数据进行解封装处理。
其中，指定send接口和指定receive接口是为各系统组件配置的统一标准接口，也可以理解为，所有系统组件之间的数据传输，均是通过指定send接口和指定receive接口进行的。
相应地，指定格式，作为待传输数据封装的载体，是根据统一标准接口进行配置的，即如果统一标准接口不同，则为待传输数据配置的指定格式也有所区别，在此不进行限定。
对于接收系统组件而言，在通过指定receive接口接收到common路由层转发的数据传输请求时，即接收到其中携带的封装数据，进而便能够按照指定格式对封装数据进行解封装处理。
解封装处理，实质是封装的逆过程，都是遵循指定格式进行的。
通过上述实施例的配合，通过统一标准接口的配置，使得系统组件之间的数据传输得以实现，并且有利于降低数据传输的复杂度，从而实现高效的数据传输。
图8是一应用场景中一种实现页面功能复用的方法所涉及的common路由层的具体实现示意图。
该应用场景中，互联网应用为保险营销应用，该保险营销应用包括保单销售页面、信息提醒页面和保单售后页面。其中，保单销售页面包括保单校验功能和软电话拨打功能，信息提醒页面包括保单校验功能和信息展示功能，保单售后页面包括保单催费功能。
基于上述，common路由层701作为父节点，分别与三个浮动框架702、703、704所定义的子节点相互连接，该三个浮动框架702～704分别为保单销售页面、信息提醒页面和保单售后页面所构建。
同时，根据保单销售页面、信息提醒页面和保单售后页面所分别具有的页面功能，将不同的系统组件705～708嵌入相应的浮动框架。
具体而言，将保单校验组件705和软电话拨打组件706嵌入浮动框架702，将软电话拨打组件706和信息展示组件707嵌入浮动框架703，将保单催费组件708嵌入浮动框架704。
就软电话拨打组件706来说，同时嵌入至浮动框架702和浮动框架703，以此实现了保单销售页面和信息提醒页面的页面功能复用。
对于保单校验组件705和软电话拨打组件706，由于属于同一浮动框架702，彼此之间可以直接访问，即属于相同域通信。
对于软电话拨打组件706和保单催费组件708，因属于不同浮动框架，彼此之间属于跨域通信，将通过common路由层701实现相互访问，即软电话拨打组件706借由common路由层701查找到保单催费组件708，进而将待传输数据传输至保单催费组件708。
在本应用场景中，各页面所具有的页面功能被拆分，进而封装形成系统组件被动态嵌入为页面所构建的浮动框架中，并借助主浮动框架实现各系统组件之间的无差别通信，实现了页面功能的复用，降低了互联网应用开发的复杂度，进而有利于提高开发效率，以此有效地节省开发成本。
下述为本发明装置实施例，可以用于执行本发明所涉及的实现页面功能复用的方法。对于本发明装置实施例中未披露的细节，请参照本发明所涉及的实现页面功能复用的方法的实施例。
请参阅图9，在一示例性实施例中，一种实现页面功能复用的装置900包括但不限于：组件封装模块910、页面加载模块930和组件嵌入模块950。
其中，组件封装模块910用于根据互联网应用所提供页面功能进行组件封装，得到多个系统组件，每一个系统组件对应互联网应用提供的一种页面功能。
页面加载模块930用于通过触发进行的互联网应用登录操作为互联网应用进行页面加载，并为加载的页面构建浮动框架。
组件嵌入模块950用于根据所加载页面所具有的页面功能，在浮动框架中动态嵌入对应于页面功能的系统组件。
需要说明的是，上述实施例所提供的实现页面功能复用的装置在进行实现页面功能复用的处理时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即实现页面功能复用的装置的内部结构将划分为不同的功能模块，以完成以上描述的全部或者部分功能。
另外，上述实施例所提供的实现页面功能复用的装置与实现页面功能复用的方法的实施例属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。
在一示例性实施例中，一种实现页面功能复用的装置，包括处理器及存储器。
其中，存储器上存储有计算机可读指令，该计算机可读指令被处理器执行时实现上述各实施例中的实现页面功能复用的方法。
在一示例性实施例中，一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各实施例中的实现页面功能复用的方法。
上述内容，仅为本发明的较佳示例性实施例，并非用于限制本发明的实施方案，本领域普通技术人员根据本发明的主要构思和精神，可以十分方便地进行相应的变通或修改，故本发明的保护范围应以权利要求书所要求的保护范围为准。