本申请涉及页面搭建处理技术领域，特别是涉及页面搭建处理方法、装置及系统。
背景技术：
在一些大型的网络销售平台中，业务标识经常会开展一些大型的促销活动等，每次开展活动都需要开发对应的活动会场页面，例如，“双11”活动的活动会场页面，等等。为了便于生成这种活动页面，有的销售平台为运营人员提供了用于搭建页面的系统，这种页面搭建系统可以为用户(页面开发者)提供多个不同的模块，用户可以从模块池中选择模块来组装成页面框架，组装的过程像积木一样，使得一个页面可以由N个模块组成，如图1左侧所示，其中的每个小方框代表一个模块。选择好模块后，再向具体的模块中投放数据内容，以此生成完整的页面。例如，如图1右侧所示，页面中显示出了5个模块，其中包括版头(banner)模块，楼层(楼层内可以包括一排4或者其他排列方式的商品坑位)模块，等等，并且显示出分别向各个模块投放数据之后的展示效果。
上述页面搭建系统可以使得页面搭建过程变得高效，但是，在现有技术中，这种页面搭建系统的通用性不强，应用范围受到限制。因此，如何提高页面搭建系统的通用性，使其能够提供支持更多页面的创建，成为需要本领域技术人员解决的技术问题。
技术实现要素：
本申请提供了页面搭建处理方法、装置及系统，能够使得页面搭建系统的通用性得到提高。
本申请提供了如下方案：
一种页面搭建处理系统，所述系统用于进行页面搭建操作，所述页面按照所属业务标识的不同分为多个页面类别，其中，每个业务标识具有内部自定义的页面规范，所述系统包括：
模块规范维护单元，用于根据各业务标识自定义的页面规范，提供各个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识的模块；
模块分组保存单元，用于将各模块按照所对应的业务标识的不同，进行分组保存，生成多个模块池；
数据投放系统接入单元，用于将数据投放系统接入到所述页面搭建处理系统中，其中，所述数据投放系统为多个，不同的数据投放系统对应不同的业务标识，且各数据投放系统分别符合对应业务标识的自定义页面规范；
交互单元，用于提供系统功能界面，并通过所述系统功能界面接收到关于目标页面在目标系统功能方面的处理请求时，确定所述页面所属的目标业务标识，以便利用所述目标业务标识关联的模块池或数据投放系统实现所述目标系统功能。
一种页面搭建信息处理方法，包括：
页面搭建平台服务器按照多个业务标识各自对应的自定义页面规范，提供分别与多个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识下的模块，所述模块用于进行对应业务标识下页面的搭建操作；
接收到新建的模块时，根据所述新建的模块带有的模块规范标识，确定所述新建的模块对应的目标业务标识；
保存所述目标模块与所述目标业务标识之间的对应关系，以便在搭建所述目标业务标识下的页面时，将提供与所述目标业务标识对应的各目标模块作为候选模块。
一种页面搭建方法，包括：
页面搭建平台服务器分别为多个业务标识保存各自对应的模块集合，其中，每个业务标识对应的模块集合中的模块按照所述服务器为该业务标识提供的模块规范创建，各模块规范与各业务标识内部的自定义页面规范相对应；
接收页面搭建请求，根据请求方的用户身份信息，从所述多个业务标识中确定所述页面所属的目标业务标识；
根据所述目标业务标识对应的模块集合提供候选模块；
根据从所述候选模块中选择的目标模块进行页面搭建，保存搭建完成的页面框架。
一种页面数据投放方法，包括：
页面搭建平台服务器提供对多个数据投放系统的接入处理，所述多个数据投放系统分别与不同的业务标识相对应，且各数据投放系统分别符合对应业务标识的自定义页面规范；
接收到针对目标页面中目标模块的数据投放处理请求时，确定页面所属的目标业务标识；
确定所述目标业务标识对应的目标数据投放系统，并提供所述目标数据投放系统的投放界面，以便通过所述投放界面接收投放条件信息，并提供给所述目标数据投放系统，由所述目标数据投放系统进行相应的处理，并返回用于向所述目标模块进行投放的目标数据。
一种页面搭建信息处理装置，应用于页面搭建平台服务器，包括：
模块规范提供单元，用于页面搭建平台服务器按照多个业务标识各自对应的自定义页面规范，提供分别与多个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识下的模块，所述模块用于进行对应业务标识下页面的搭建操作；
业务标识确定单元，用于接收到新建的模块时，根据所述新建的模块带有的模块规范标识，确定所述新建的模块对应的目标业务标识；
保存单元，用于保存所述目标模块与所述目标业务标识之间的对应关系，以便在搭建所述目标业务标识下的页面时，将提供与所述目标业务标识对应的各目标模块作为候选模块。
一种页面搭建装置，应用于页面搭建平台服务器，包括：
模块集合保存单元，用于分别为多个业务标识保存各自对应的模块集合，其中，每个业务标识对应的模块集合中的模块按照所述服务器为该业务标识提供的模块规范创建，各模块规范与各业务标识内部的自定义页面规范相对应；
业务标识确定单元，用于接收页面搭建请求，根据请求方的用户身份信息，从所述多个业务标识中确定所述页面所属的目标业务标识；
候选模块提供单元，用于根据所述目标业务标识对应的模块集合提供候选模块；
页面框架保存单元，用于根据从所述候选模块中选择的目标模块进行页面搭建，保存搭建完成的页面框架。
一种页面数据投放装置，应用于页面搭建平台服务器，包括：
接入单元，用于提供对多个数据投放系统的接入处理，所述多个数据投放系统分别与不同的业务标识相对应，且各数据投放系统分别符合对应业务标识的自定义页面规范；
业务标识确定单元，用于接收到针对目标页面中目标模块的数据投放处理请求时，确定页面所属的目标业务标识；
投放系统确定单元，用于确定所述目标业务标识对应的目标数据投放系统，并提供所述目标数据投放系统的投放界面，以便通过所述投放界面接收投放条件信息，并提供给所述目标数据投放系统，由所述目标数据投放系统进行相应的处理，并返回用于向所述目标模块进行投放的目标数据。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，为了能够使得同一个页面搭建平台能够承载多个不同的业务标识，可以为不同的业务标识提供不同的模块规范，平台中的模块可以按照遵循的模块规范的不同进行隔离保存，也即，形成不同的模块池，这样，不同业务标识在搭建页面时，可以使用对应模块池中的模块进行页面搭建。另外，还可以针对不同的业务标识提供不同的数据投放系统，具体在进行数据投放时，也可以根据关联的业务标识的不同，使用不同的数据投放系统进行数据投放。这样，可以实现不同业务标识之间的用户隔离、内容隔离以及功能隔离，从而实现在保持现有本地开发模式不变，减少迁移成本的情况下，使得页面搭建平台能够承载多个不同业务标识中的活动页面搭建，从而可以大为提升页面搭建系统的兼容性，使得多个业务标识都可以利用同一页面搭建平台，实现高效的页面搭建以及数据投放等相关操作，提高页面生成的效率，因此，页面搭建系统的通用性得到提高。
另外，在一些优选的实施例中，还对平台的功能调用方式进行了优化，对于在实现所述系统功能时，不同的业务标识之间具有不同业务逻辑的第二类系统功能，可以提供“两层”接口，通过第一层统一的功能类接口，实现在不同的业务标识之间对同一功能的统一调用，通过第二层的具体业务类，调用真正对接业务标识系统的接口或者处理特定的逻辑。
再者，本申请的优选实施例中，还提供了统一的通知消息机制，各个业务标识的数据投放系统都可以对各个通知消息进行订阅，当页面生命周期内发生页面状态变化等事件时，页面搭建平台可以生成相应的通知消息，并通知给订阅该通知消息的各个数据投放系统，由对应的数据投放系统识别后进行相应的处理。并且，通知消息的类型可以细化为多种，从而可以提高数据投放系统收到通知消息后的处理效率。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是页面搭建模块示意图；
图2是本申请实施例提供的系统的示意图；
图3是本申请实施例提供的接口信息示意图；
图4是本申请实施例提供的第一方法的流程图；
图5是本申请实施例提供的第二方法的流程图；
图6是本申请实施例提供的第三方法的流程图；
图7是本申请实施例提供的第一装置的示意图；
图8是本申请实施例提供的第二装置的示意图；
图9是本申请实施例提供的第三装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
首先需要说明的是，本申请发明人在实现本申请的过程中发现，现有的页面搭建系统之所以通用性不强，其原因在于，对于各种业务需求方而言，其往往已经具备完善的自定义页面规范，包括前端规范、页面渲染规范、本地开发、云构建等等。而页面搭建系统通常需要与具体业务标识的页面规范相配合。例如，对于“天猫”平台中的页面搭建系统，在现有技术中，该页面搭建系统只能为“天猫”业务提供页面搭建方面的支持，因为系统内的模块都是与“天猫”系统中的前端规范、页面渲染机制等绑定的。如果存在其他的业务需求方，在前端规范、页面渲染机制等方面与“天猫”系统中存在差异，则无法通过该页面搭建系统进行页面搭建。例如，对于“淘宝”系统，其与“天猫”系统属于不同的业务需求方，并且，“淘宝”系统已经具有其独立的前端规范(基于KISSY，RX的前端方案)和独立的页面渲染控制(PI)能力，“淘宝”前端团队已有一套完备的前端本地开发(DEF)+云构建(UPX)解决方案。也就是说，“淘宝”营销活动的招商、数据投放链路已成体系，并且与“天猫”业务差异大，因此，就无法利用现有的页面搭建系统为“淘宝”的活动页面搭建提供支持。
然而，虽然不同的业务需求方之间在数据链路的业务模式中存在差异，但是页面搭建的需求却是基本相同的，并且营销活动的玩法等也是趋同的，因此，如果在保持现有本地开发模式不变，减少迁移成本的情况下，使得页面搭建系统能够承载多个不同业务需求方中的活动页面搭建，则可以大为提升页面搭建系统的通用性，并提升系统存在的价值。
基于上述考虑，在本申请实施例中，试图通过一些方式，使得页面搭建平台能够对接多个业务标识(例如，既能够对接“天猫”，又能够对接“淘宝”，还可以对接其他业务标识)，这样，使得多个业务标识在需要创建具体的页面时，都可以通过同一套页面搭建系统来执行。为了达到上述目的，本申请实施例首先可以根据不同的业务需求方各自的自定义页面规范(主要可以是自定义的本地开发规范、前端规范等)，为不同的业务标识提供不同的模块规范，平台中的模块可以按照遵循的模块规范的不同进行隔离保存，也即，形成不同的模块池。这样，不同业务需求方在搭建页面时，可以使用对应模块池中的模块进行页面搭建。另外，还可以针对不同的业务标识，还可以提供不同的数据投放系统，具体在进行数据投放时，也可以根据关联的业务标识的不同，使用不同的数据投放系统进行数据投放，并且，各业务标识对应的数据投放系统，也可以是根据与对应业务标识的自定义页面规范(主要是数据投放方面的页面规范)提供的。另外，为了能够在页面搭建平台内部实现对页面的预览等功能，还可以在平台中提供多套页面渲染框架，不同的页面渲染框架对应不同的业务标识，同样可以是根据对应业务标识的自定义页面规范(主要是页面渲染方面的自定义规范)来提供各自的渲染框架。
另外，为了便于业务标识使用页面搭建平台提供的各项功能，可包括页面搭建、数据投放、页面预览、页面发布等等。此外，还可以提供统一的访问接口，使得业务标识运营人员在使用具有的功能时，可以以统一的接口进行调用，而无需区分具有的业务标识，如果各个业务标识对应的具体处理实现方式不同，再在统一接口内部进行识别，并路由到具体业务标识的处理逻辑进行处理。再者，本申请实施例还可以提供统一的消息通知机制，在一个页面的整个生命周期内，当页面状态发生变化时，页面搭建平台都可以产生相应的通知消息，并通知给订阅该通知消息的具体业务标识对应的数据投放系统，等等。总之，本申请实施例可以在多个方面实现对页面搭建平台的改造，以使得其能够承载多个业务标识的页面搭建以及数据投放需求。
需要说明的是，在本申请实施例中，具体的业务标识可以有多种，并且在具体实现时，不同的业务标识不仅仅可以包括同一公司内部的不同部门(例如，“天猫”、“淘宝”等)，还可以包括一些其他具有类似需求的业务标识。也就是说，本申请实施例中的页面搭建系统可以以平台的形式存在，平台的用户可以是各种类型的业务标识，只要某业务需求方具有创建页面的需求，就可以将其前端规范、页面渲染控制规范、本地开发规范等自定义页面规范提交给页面搭建平台，这样，平台就可以根据这些业务标识自身已有的自定义页面规范，确定出相应的模块规范，并根据这种模块规范，为该业务标识提供符合该模块规范的模块，这样，该业务标识就可以利用这种模块，进行页面的搭建。同时，还可以在平台中为业务标识接入对应的数据投放系统，使得业务标识可以通过该平台进行具体的数据投放等操作，等等。
另外需要说明的是，通过本申请实施例生成的页面，遵循了两重规范，一个是业务标识自身的自定义页面规范，包括业务方内部自定义的前端规范、页面渲染控制规范、本地开发规范，等等。另外，还遵循了页面搭建系统中与该业务标识对应的模块规范等。因此，在整个页面招商(圈定数据对象集合等)、搭建、渲染、展示等各链路节点上，都能够实现相应的适配。
下面对具体的实现方式进行详细介绍。
实施例一
首先，该实施例一提供了一种页面搭建处理系统，参见图2，所述系统用于进行页面搭建操作，所述页面按照所属业务标识的不同分为多个页面类别，其中，每个业务标识具有内部自定义的页面规范，所述系统包括：
模块规范维护单元201，用于根据各业务标识自定义的页面规范，提供各个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识的模块；
具体在提供某业务标识对应的模块规范时，可以根据业务标识自身已有的页面规范来进行，例如，前端规范、页面渲染控制规范、本地开发规范，等等，等等。页面搭建平台需要承载多少个业务标识，就可以分别提供多少个模块规范，这样，在为运营人员提供模块时，就可以分别依据不同的模块规范，提供不同的模块，以用于在各个业务标识场景下进行页面的搭建。
模块分组保存单元202，用于将各模块按照所对应的业务标识的不同，进行分组保存，生成多个模块池；
对于平台中创建的各个模块，在进行保存时，可以根据其各自遵循的模块规范的不同，进行分组保存，也即，可以得到多个不同的模块池，每个模块池与一个具体的业务标识相对应，分别用于支持各业务标识中具体页面的搭建。
数据投放系统接入单元203，用于将数据投放系统接入到所述页面搭建处理系统中，其中，所述数据投放系统为多个，不同的数据投放系统对应不同的业务标识，且各数据投放系统分别符合对应业务标识的自定义页面规范；
由于不同的业务标识中，具有不同的数据投放方面的页面规范，因此，在本申请实施例中，还可以分别为各个不同的业务标识提供不同的数据投放系统。其中，数据投放系统属于后台的数据处理系统，对于前台的运营人员而言，其可以不必关心数据投放系统的具体数据处理逻辑，只要按照数据投放系统的前台界面中提供的参数等设定具体的选品规则等信息即可，数据投放系统就可以根据选品规则等信息进行计算，最终得到符合条件的数据集，用于对页面中的具体模块进行数据投放。当然，数据投放系统的作用可能也不是全都是用于根据选品规则提供数据集，例如，还可以提供页面的版头合图，等等。在本申请实施例中，各个不同业务标识对应的数据投放系统都可以接入到页面搭建平台中来，在需要使用页面搭建平台在数据投放相关的功能时，可以根据具体的业务标识确定出具体的数据投放系统中进行相应的处理。
其中，在实际应用中，各个数据投放系统可以是以插件的形式接入到页面搭建系统中。在这种情况下，页面搭建系统中还可以包括：
插件规范维护单元，用于根据各业务标识自定义的数据投放规范，提供插件制作规范，以及数据通信规范，以便数据投放系统接入方按照所述插件生成规范以及数据通信规范制作插件。此时，所述数据投放系统接入单元具体可以用于，将所述数据投放系统以插件的形式接入到所述页面搭建处理系统中；而交互单元具体可以用于，根据所述目标业务类确定对应的目标插件，并通过插件描述信息唤起所述目标插件，利用所述目标插件返回的数据对所述目标页面进行数据投放。其中，插件描述信息可以包括插件的地址、初始化参数，等等。关于插件的描述信息可以预先进行配置。
交互单元204，用于提供系统功能界面，并通过所述系统功能界面接收到关于目标页面在目标系统功能方面的处理请求时，确定所述页面所属的目标业务标识，以便利用所述目标业务标识关联的模块池或数据投放系统实现所述目标系统功能。
所谓的系统功能就可以是指页面搭建平台提供的所有功能，包括页面搭建功能、数据投放功能、页面预览功能，等等。具体实现时，所述系统功能可以有多种，其中包括：在实现所述系统功能时，不同的业务标识之间具有相同业务逻辑的第一类系统功能。例如，所述第一类系统功能包括页面搭建功能，由于对于不同的业务标识，具体在收到页面搭建请求后，具体的处理方式是相同的，因此，此时的所述交互单元204具体可以用于：
提供页面搭建界面，并通过所述页面搭建界面接收到搭建目标页面的请求时，根据请求方的用户身份信息确定所属的目标业务标识，并利用所述目标业务标识关联的模块池，提供候选模块，以便从所述候选模块中选择目标模块，并添加到页面框架中。
也就是说，对于上述第一类系统功能，只需要“一层”接口即可实现，在这种接口内，直接对业务标识进行识别，在识别出目标业务标识后，直接从该目标业务标识对应的模块池中选择出候选模块，这样，运营人员就可以利用这些候选模块进行页面搭建，例如，将一些目标模块“拖拽”到页面框架内的编辑区，等等。
其中，在接收到页面搭建时，由于属于新创建一个页面，因此，平台中没有关于该页面的相关信息，此时，可以根据页面搭建请求的请求者用户身份信息，来识别具体属于哪个业务标识，进而就可以将该页面确定为与该业务标识关联的页面。
另外，该系统还可以包括：页面信息记录单元，用于在接收到所述搭建目标页面的请求，并确定出所述目标业务标识后，记录所述目标页面与所述目标业务标识之间的对应关系，以便在所述目标页面的生命周期内，通过所述对应关系，确定所述目标页面对应的所述目标业务标识。
也就是说，在页面搭建过程中，根据用户身份标识识别出页面所属的业务标识后，就可以在页面中记录与该目标业务标识之间的对应关系，相当于给页面打上一个标签，用于标记其对应的目标业务标识。这样，在该页面的整个生命周期内的后续各个节点，如果需要对页面的业务标识进行识别，都可以利用此时记录的页面标识来进行确定，而不必再依据请求者用户的身份信息进行确定。
另外，所述系统功能也可以包括：在实现所述系统功能时，不同的业务标识之间具有不同业务逻辑的第二类系统功能，也就是说，虽然在运营人员(也即页面搭建平台的用户)看来，是属于相同的系统功能，但是在具体的业务标识中，有着各自不同的业务实现逻辑。也就是说，同一个功能在不同业务标识下的实现方案可能是不一样的，比如，数据投放能力，在“天猫”下需要对接RMC系统，在“淘宝”下需要对接TCE系统，等等，但是统一对接需要的API接口是一致的，所以，本申请实施例抽象设计了一套结构：功能类+业务类，其中，功能类统一对外提供接口服务，在该接口内部，可以根据不同的业务标识配置路由到不同的业务类，业务类负责调用真正的对接系统接口或者处理特定的逻辑。也就是说，在本申请实施例中，页面搭建平台服务器还可以包括：
接口提供单元，用于针对所述第二类系统功能提供统一的功能类接口，同一功能类接口下还提供多个业务类，每个业务类分别与一个业务标识对应。如图3所示，其中，功能类包括数据源类、活动源类、“淘客”功能类，当然，在实际应用中，该功能类还可以包括其他功能类。在各个功能类下，还分别定义了多个业务类，分别与不同的业务标识相对应。此时，所述交互单元具体可以用于：在通过所述系统功能界面接收到关于目标页面在目标系统功能方面的处理请求时，通过所述功能类接口，确定所述目标页面对应目标业务标识的确定，并路由到该功能类下所述目标业务标识对应的目标业务类，由所述目标业务类，通过调用对应目标业务标识中实际对应的功能接口或者实现预置的处理逻辑，对所述请求进行处理，并实现所述目标系统功能。
也即，对于上述第二类系统功能，可以提供“两层”接口，通过第一层统一的功能类接口，实现对同一功能的统一调用，再通过第二层的具体业务类调用实际业务标识系统中的具体接口，再实现在具体业务标识中具体的功能实现。
其中，所述功能类接口包括数据投放类接口，此时，所述交互单元具体可以用于：通过所述系统功能界面接收针对目标页面的数据投放请求时，通过所述数据投放类接口确定所述目标页面对应的目标业务标识，并路由到该功能类下所述目标业务标识对应的目标业务类，并根据所述目标业务类提供数据投放条件信息编辑界面，通过该投放条件信息编辑界面接收到投放条件信息后，由该目标业务标识对应的数据投放系统进行数据投放处理。
或者，所述功能类接口包括数据源类接口；此时，所述交互单元具体可以用于：通过所述系统功能界面接收到对目标页面进行预览的处理请求时，通过所述数据源类接口确定所述目标页面对应目标业务标识，并路由到该功能类下所述目标业务标识对应的目标业务类，并根据所述目标业务类从对应的数据源获得页面数据，并利用所述页面数据提供页面预览结果。
例如，在页面投放过程中，运营人员想要对页面展示情况进行预览，此时就可以向平台发出相应的请求。平台为了提供页面的预览结果，需要首先确定该页面关联的数据，并且，需要从相应的数据源进行获取。此时，就可以首先利用统一的数据源接口进行调用，在该数据源接口内部判断出当前页面所属的具体的业务标识，例如，假设为“天猫”的页面，之后，就可以将该数据获取请求路由到“天猫”对应的数据源相关的业务类中进行处理，由“天猫”对应的数据源相关的业务类返回当前页面的相关数据。然后，平台方再根据数据源返回的具体页面数据，对页面进行渲染，之后就可以供具体的页面预览结果。
在实际应用中，不同的业务标识可能还对应着不同的页面渲染框架，在本申请实施例中，所述页面搭建处理系统还可以包括：
页面渲染框架提供单元，用于提供各个业务标识对应的多个不同的页面渲染框架；此时，所述交互单元在利用数据源类接口返回的页面数据提供页面预览结果时，具体可以用于：利用所述目标业务标识对应的页面渲染框架，对所述目标页面进行渲染，以提供所述页面预览结果。
另外，在实际应用中，由于数据投放系统相对于页面搭建平台而言属于外部系统，这种数据投放系统可以以插件的形式接入到页面搭建平台中，由页面搭建平台向运营人员提供投放系统的界面，但是具体的数据编辑、任务调度等操作是由后台的数据投放系统来完成。为此，在本申请实施例中，还可以由页面搭建平台向各个数据投放系统来提供一种统一的消息通知机制。具体的，各个业务标识的数据投放系统都可以订阅这种通知消息，页面搭建平台在页面生命周期内检测到某事件后，可以产生相应的通知消息，并统一推送给各个订阅该消息的数据投放系统。也就是说，虽然具体页面与业务标识之间具有对应关系，而数据投放系统与业务标识也具有关联关系，但是，平台在提供通知消息时，并不会进行区分，而是向订阅该通知消息的全部数据投放系统都进行发送。数据投放系统在收到通知消息后，再对对应的页面进行识别，如果是无效消息(也即，页面对应的业务标识与投放系统对应的业务标识不一致)，则可以将该通知消息丢弃，如果是有效消息(也即，页面对应的业务标识与投放系统对应的业务标识一致)，再对该消息进行具体的处理操作，包括从页面搭建平台拉取页面的详情信息，等等。
具体的，所述页面搭建处理系统还可以包括：
统一通知消息控制单元，用于接受各数据投放系统对通知消息的订阅，在所述目标页面的生命周期内，根据所述目标页面的状态变化事件，生成通知消息，并发送给订阅所述通知消息的数据投放系统，由各数据投放系统在接收到所述通知消息后，对所述目标页面对应的目标业务标识进行识别，并由与所述目标业务标识对应的数据投放系统对所述通知消息进行处理。
需要说明的是，具体在发送上述通知消息时，可以有多种方式，例如，可以是将各种状态/事件信息，使用相同的通知消息接口进行发送，例如，对于页面的创建、复制、修改负责人等等事件，全部通过相同的接口向投放系统进行通知。在这种情况下，投放系统在收到通知消息后，还需要首先进行多种具体的比对等操作，才能够获知页面具体关联的事件或状态，进而再进行具体的处理操作。因此，在本申请的优选实施例中，通知消息的类型可以细化为多种，例如，可以根据页面相关的具体事件、状态等，提供多种通知消息的类型，这样，数据投放系统在接收到通知消息后，就可以根据消息的类型，确定出页面对应的事件或者状态信息，因此，能够快速的响应。例如，具体的通知消息类型可以包括：页面创建/复制通知消息、增加/删除/修改页面模块的通知消息、修改页面负责人的通知消息、修改PC/无线同步状态的通知消息、修改页面所有者用户的通知消息、预览页面的通知消息、发布/定时发布页面的通知消息，等等。
相应的数据投放系统在接收到各类通知消息后，可以分别执行对应的处理。例如，对于页面创建/复制通知消息，数据投放系统在收到该通知消息后，可以初始化页面信息，确定页面中包含哪些模块，确定页面负责人是谁，还可以生成页面权限逻辑，用于指定哪些人可以维护该页面中的数据，等等。又如，在接收到修改页面负责人的通知消息时，数据投放系统可以执行数据权限转移等相关操作。在收到修改PC/无线同步状态的通知消息时，数据投放系统可以根据修改后的状态执行相关处理，其中，如果为断开PC/无线的同步状态，则数据投放系统可以将页面数据分为两份，分别对应PC端以及无线端；如果是设置为PC/无线同步，则将页面数据合并成一份，等等。
关于通知消息的通知机制，针对对同步性要求不高的通知消息，所述统一通知消息控制单元可以采用异步消息通知机制，向订阅所述通知消息的数据投放系统进行通知。这种方式可以降低系统间耦合，减少重复开发工作量，提高接入效率。
而当所述通知消息为对所述目标页面执行预览、复制或发布操作的通知消息时，所述统一通知消息控制单元可以采用同步消息通知机制，向订阅所述通知消息的数据投放系统进行通知。这是因为，对于其中的预览消通知消息，由于属于强依赖的接口，因此，需要使用同步方式进行调用。而关于复制或发布等操作，如果走异步通知，生效的时间是无法保障的，会出现复制后的页面没办法立马去编辑数据，发布后的页面持续一段时间内找不到数据源造成空窗等问题。因此，针对上述一些特殊类型的通知消息，可以采用同步通知的机制进行发送。
总之，通过本申请实施例，为了能够使得同一个页面搭建平台能够承载多个不同的业务标识，可以为不同的业务标识提供不同的模块规范，平台中的模块可以按照遵循的模块规范的不同进行隔离保存，也即，形成不同的模块池，这样，不同业务标识在搭建页面时，可以使用对应模块池中的模块进行页面搭建。另外，还可以针对不同的业务标识提供不同的数据投放系统，具体在进行数据投放时，也可以根据关联的业务标识的不同，使用不同的数据投放系统进行数据投放。这样，可以实现不同业务标识之间的用户隔离、内容隔离以及功能隔离，从而实现在保持现有本地开发模式不变，减少迁移成本的情况下，使得页面搭建平台能够承载多个不同业务标识中的活动页面搭建，从而可以大为提升页面搭建系统的兼容性，使得多个业务标识都可以利用同一页面搭建平台，实现高效的页面搭建以及数据投放等相关操作，提高页面生成的效率。
另外，在一些优选的实施例中，还对平台的功能调用方式进行了优化，对于在实现所述系统功能时，不同的业务标识之间具有不同业务逻辑的第二类系统功能，可以提供“两层”接口，通过第一层统一的功能类接口，实现在不同的业务标识之间对同一功能的统一调用，通过第二层的具体业务类，调用真正对接业务标识系统的接口或者处理特定的逻辑。
再者，本申请的优选实施例中，还提供了统一的通知消息机制，各个业务标识的数据投放系统都可以对各个通知消息进行订阅，当页面生命周期内发生页面状态变化等事件时，页面搭建平台可以生成相应的通知消息，并通知给订阅该通知消息的各个数据投放系统，由对应的数据投放系统识别后进行相应的处理。并且，通知消息的类型可以细化为多种，从而可以提高数据投放系统收到通知消息后的处理效率。
实施例二
该实施例二是与实施例一相对应的，对模块分组的实现方式进行介绍。具体的，参见图4，该实施例二提供了一种页面搭建信息处理方法，该方法具体可以包括以下步骤：
S401：页面搭建平台服务器按照多个业务标识各自对应的自定义页面规范，提供分别与多个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识下的模块，所述模块用于进行对应业务标识下页面的搭建操作；
S402：接收到新建的模块时，根据所述新建的模块带有的模块规范标识，确定所述新建的模块对应的目标业务标识；
S403：保存所述目标模块与所述目标业务标识之间的对应关系，以便在搭建所述目标业务标识下的页面时，将提供与所述目标业务标识对应的各目标模块作为候选模块。
实施例三
该实施例三也是与实施例一相对应的，对页面搭建过程进行介绍。具体的，该实施例三提供了一种页面搭建方法，参见图5，该方法具体可以包括以下步骤：
S501：页面搭建平台服务器分别为多个业务标识保存各自对应的模块集合，其中，每个业务标识对应的模块集合中的模块按照所述服务器为该业务标识提供的模块规范创建，各模块规范与各业务标识内部的自定义页面规范相对应；
S502：接收页面搭建请求，根据请求方的用户身份信息，从所述多个业务标识中确定所述页面所属的目标业务标识；
S503：根据所述目标业务标识对应的模块集合提供候选模块；
S504：根据从所述候选模块中选择的目标模块进行页面搭建，保存搭建完成的页面框架。
具体实现时，还可以在接收到所述搭建目标页面的请求，并确定出所述目标业务标识后，记录所述目标页面与所述目标业务标识之间的对应关系，以便在所述目标页面的生命周期内，通过所述对应关系，确定所述目标页面对应的所述目标业务标识。
实施例四
该实施例四也是与实施例一相对应的，对数据投放的过程进行介绍，具体的，本申请实施例四提供了一种页面数据投放方法，参见图6，该方法可以包括以下步骤：
S601：页面搭建平台服务器提供对多个数据投放系统的接入处理，所述多个数据投放系统分别与不同的业务标识相对应，且各数据投放系统分别符合对应业务标识的自定义页面规范；
S602：接收到针对目标页面中目标模块的数据投放处理请求时，确定页面所属的目标业务标识；
S603：确定所述目标业务标识对应的目标数据投放系统，并提供所述目标数据投放系统的投放界面，以便通过所述投放界面接收投放条件信息，并提供给所述目标数据投放系统，由所述目标数据投放系统进行相应的处理，并返回用于向所述目标模块进行投放的目标数据。
其中，具体实现时，还可以预先提供统一的数据投放功能类应用程序编程接口API，每个数据投放功能类API关联有多个业务类，每个业务类分别与一个业务标识对应。这样，可以在接收到对所述数据投放功能类API的调用请求时，由所述功能类API内部定义的处理逻辑确定所述目标页面所属的目标业务标识，并路由到所述目标业务标识对应的目标业务类。然后，再由所述目标业务类调用所述目标业务标识的数据投放功能接口，获得目标数据投放系统的投放界面并提供该投放界面。
在一种具体的实现方式下，所述数据投放系统还可以以插件的形式接入到所述页面搭建处理系统中，其中，所述插件按照插件制作规范制作，所述插件制作规范由所述页面搭建处理系统根据各业务标识对应的自定义页面规范提供。在这种情况下，可以根据所述目标业务类确定对应的目标插件，并通过插件描述信息唤起所述目标插件，利用所述目标插件返回的数据对所述目标页面进行数据投放。
另外，页面搭建平台服务器还可以接收各数据投放系统对通知消息的订阅；在所述目标页面的生命周期内，根据所述目标页面的状态变化事件，生成通知消息，并发送给订阅所述通知消息的数据投放系统，以便由各数据投放系统在接收到所述通知消息后，对所述目标页面对应的目标业务标识进行识别，并由与所述目标业务标识对应的数据投放系统对所述通知消息进行处理。
再者，页面搭建平台服务器还可以提供各个业务标识对应的多个不同的页面渲染框架；接收到对所述目标页面的预览请求时，获取所述目标页面的相关数据，并利用对应业务标识的目标渲染框架对所述目标页面进行渲染，以提供预览结果。
关于上述实施例二至实施例四，具体的实现方式可以参见前述实施例一中的介绍，这里不再一一赘述。
与实施例二相对应，本申请实施例还提供了一种页面搭建信息处理装置，参见图7，该装置应用于页面搭建平台服务器，包括：
模块规范提供单元701，用于按照多个业务标识各自对应的自定义页面规范，提供分别与多个业务标识对应的多个不同的模块规范，以便分别按照各自的模块规范创建对应业务标识下的模块，所述模块用于进行对应业务标识下页面的搭建操作；
业务标识确定单元702，用于接收到新建的模块时，根据所述新建的模块带有的模块规范标识，确定所述新建的模块对应的目标业务标识；
保存单元702，用于保存所述目标模块与所述目标业务标识之间的对应关系，以便在搭建所述目标业务标识下的页面时，将提供与所述目标业务标识对应的各目标模块作为候选模块。
与实施例三相对应，本申请实施例还提供了一种页面搭建装置，参见图8，该装置应用于页面搭建平台服务器，包括：
模块集合保存单元801，用于分别为多个业务标识保存各自对应的模块集合，其中，每个业务标识对应的模块集合中的模块按照所述服务器为该业务标识提供的模块规范创建，各模块规范与各业务标识内部的自定义页面规范相对应；
业务标识确定单元802，用于接收页面搭建请求，根据请求方的用户身份信息，从所述多个业务标识中确定所述页面所属的目标业务标识；
候选模块提供单元803，用于根据所述目标业务标识对应的模块集合提供候选模块；
页面框架保存单元804，用于根据从所述候选模块中选择的目标模块进行页面搭建，保存搭建完成的页面框架。
具体实现时，该装置还可以包括：
业务标识记录单元，用于在接收到所述搭建目标页面的请求，并确定出所述目标业务标识后，记录所述目标页面与所述目标业务标识之间的对应关系，以便在所述目标页面的生命周期内，通过所述对应关系，确定所述目标页面对应的所述目标业务标识。
与实施例四相对应，本申请实施例还提供了一种页面数据投放装置，参见图9，该装置应用于页面搭建平台服务器，包括：
接入单元901，用于提供对多个数据投放系统的接入处理，所述多个数据投放系统分别与不同的业务标识相对应，且各数据投放系统分别符合对应业务标识的自定义页面规范；
业务标识确定单元902，用于接收到针对目标页面中目标模块的数据投放处理请求时，确定页面所属的目标业务标识；
投放系统确定单元903，用于确定所述目标业务标识对应的目标数据投放系统，并提供所述目标数据投放系统的投放界面，以便通过所述投放界面接收投放条件信息，并提供给所述目标数据投放系统，由所述目标数据投放系统进行相应的处理，并返回用于向所述目标模块进行投放的目标数据。
具体实现时，该装置还可以包括：
接口提供单元，用于预先提供统一的数据投放功能类应用程序编程接口API，每个数据投放功能类API关联有多个业务类，每个业务类分别与一个业务标识对应；
所述业务标识确定单元具体可以用于：
接收到对所述数据投放功能类API的调用请求时，由所述功能类API内部定义的处理逻辑确定所述目标页面所属的目标业务标识，并确定所述目标业务标识对应的目标业务类；
所述投放系统确定单元具体可以用于：
由所述目标业务类调用所述目标业务标识的数据投放功能接口，获得目标数据投放系统的投放界面并提供该投放界面。
其中，所述数据投放系统以插件的形式接入到所述页面搭建处理系统中，其中，所述插件按照插件制作规范制作，所述插件制作规范由所述页面搭建处理系统根据各业务标识对应的自定义页面规范提供；
所述投放系统确定单元具体可以用于具体可以用于：
根据所述目标业务类确定对应的目标插件，并通过插件描述信息唤起所述目标插件，利用所述目标插件返回的数据对所述目标页面进行数据投放。
另外，该装置还可以包括：
订阅接收单元，用于接收各数据投放系统对通知消息的订阅；
通知单元，用于在所述目标页面的生命周期内，根据所述目标页面的状态变化事件，生成通知消息，并发送给订阅所述通知消息的数据投放系统，以便由各数据投放系统在接收到所述通知消息后，对所述目标页面对应的目标业务标识进行识别，并由与所述目标业务标识对应的数据投放系统对所述通知消息进行处理。
再者，该装置还可以包括：
渲染框架提供单元，用于提供各个业务标识对应的多个不同的页面渲染框架；
预览单元，用于接收到对所述目标页面的预览请求时，获取所述目标页面的相关数据，并利用对应业务标识的目标渲染框架对所述目标页面进行渲染，以提供预览结果。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的页面搭建处理方法及、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。