CN112433723A - 个性化列表开发方法及装置 - Google Patents

Abstract

本申请适用于终端设备显示技术领域，提供了一种个性化列表开发方法及装置，其中该方法包括：获取针对初始列表的列表开发请求；确定所述初始列表所对应的数据模型和视觉模型；确定所述列表开发请求的开发类型；当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块；以及在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。由此，视图与数据是分离配置的，使得代码具有较强的扩展性，易于开发者针对列表配置个性化需求。

Description

个性化列表开发方法及装置

技术领域

本申请属于终端设备显示技术领域，尤其涉及一种个性化列表开发方法及装置。

背景技术

随着互联网技术的不断发展，厂商和用户对于终端的显示功能和效果的要求也在日益提升。在很多互联网应用产品中，针对不同业务(例如，主菜单、短信、ERP等)一般配置有相应的显示列表，丰富人机交互体验。

然而，市面上的列表基本上都是按照通用的特性开发的，其代码扩展性不是很好，无法满足列表显示的个性化需求，例如列表内置行按钮、刷新按钮等，导致个性化的列表开发操作繁杂且困难。

针对上述问题，目前业界仍无较佳的解决方案。

发明内容

有鉴于此，本申请实施例提供了一种个性化列表开发方法及装置，以至少解决现有技术中列表在定制化开发过程中操作繁杂的问题。

本申请实施例的第一方面提供了一种个性化列表开发方法，所述方法包括：获取针对初始列表的列表开发请求；确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于对相应的所述业务数据模型模块进行渲染；确定所述列表开发请求的开发类型；当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块；以及在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

本申请实施例的第二方面提供了个性化列表开发装置，所述装置包括：开发请求获取单元，用于获取针对初始列表的列表开发请求；模型确定单元，用于为确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于对相应的所述业务数据模型模块进行渲染；开发类型确定单元，用于确定所述列表开发请求的类型；增添模型模块确定单元，用于当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块；以及模型模块配置单元，用于在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

本申请实施例的第三方面提供了一种移动终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述方法的步骤。

本申请实施例的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述方法的步骤。

本申请实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端实现如上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果是：

通过本申请实施例，列表组件的结构被模块化为相应的负责处理数据的数据模型模块和相应的针对数据模型模块渲染相应视图的业务视觉模型，在需要对列表组件开发或配置个性化业务时，可以直接将对应个性化业务的第一目标业务数据模型模块和第一目标业务视觉模型模块来完善对应的数据模型和视觉模型，代码具有较强的扩展性，易于在列表配置个性化需求。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本申请实施例的个性化列表开发方法的一示例的流程图；

图2示出了根据本申请实施例的列表组件的一示例的架构示意图；

图3示出了根据本申请实施例的在业务删除场景下的个性化列表开发方法的一示例的流程图；

图4示出了根据本申请实施例的列表编辑模式配置方法的一示例的流程图；

图5示出了根据本申请实施例的个性化列表开发方法的一示例的流程图；

图6示出了根据本申请实施例的基于虚拟组件进行渲染的一示例的流程图；

图7示出了根据本申请实施例的客户端显示个性化列表的一示例的流程图；

图8示出了根据本申请实施例的客户端显示个性化列表的一示例的流程图；

图9示出了根据本申请实施例的个性化列表开发装置的一示例的结构框图；

图10是本申请实施例的移动终端的一示例的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

具体实现中，本申请实施例中描述的移动终端包括但不限于诸如具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的移动电话、膝上型计算机或平板计算机之类的其它便携式设备。还应当理解的是，在某些实施例中，上述设备并非便携式通信设备，而是具有触摸敏感表面(例如，触摸屏显示器)的计算机。

在接下来的讨论中，描述了包括显示器和触摸敏感表面的移动终端。然而，应当理解的是，移动终端可以包括诸如物理键盘、鼠标和/或控制杆的一个或多个其它物理用户接口设备。

可以在移动终端上执行的各种应用程序可以使用诸如触摸敏感表面的至少一个公共物理用户接口设备。可以在应用程序之间和/或相应应用程序内调整和/或改变触摸敏感表面的一个或多个功能以及终端上显示的相应信息。这样，终端的公共物理架构(例如，触摸敏感表面)可以支持具有对用户而言直观且透明的用户界面的各种应用程序。

图1示出了根据本申请实施例的个性化列表开发方法的一示例的流程图。关于本申请实施例方法的执行主体，其可以是客户端，例如安装有对列表组件进行开发的软件的移动终端设备。

如图1所示，在步骤110中，获取针对初始列表的列表开发请求。这里，初始列表可以表示待进行配置个性化需求的列表组件。具体地，客户端可以接收来自用户的输入操作(例如，键盘输入等)，从而生成相应的列表开发请求。

在步骤120中，确定初始列表所对应的数据模型和视觉模型。这里，数据模型包括至少一个业务数据模型模块，视觉模型包括至少一个业务视觉模型模块，并且每一业务视觉模型模块分别用于基于相应的业务数据模型模块进行渲染。应理解的是，非常多的业务组件都可以是使用列表组件进行封装扩展的。

这样，列表组件的目录结构使用了数据和视图分离的思想进行设计，每一个业务相关的数据模型模块都会有对应的视图模型模块进行渲染输出，这样的结构设计思路便于后续其它开发参与能够快速理解和学习。

在步骤130中，确定列表开发请求的开发类型。

在步骤140中，当列表开发请求为业务增添请求时，确定列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块。

在步骤150中，在数据模型中配置第一目标业务数据模型模块，并在视觉模型中配置第一目标业务视觉模型模块。

在本申请实施例中，在需要在列表中增加新的业务或特性时，只需要在所属的模型上绑定新的特性模型模块即可，操作便捷，且列表组件具有较强的代码扩展性。示例性地，当需要在列表中内置行按钮时，可以直接将针对行按钮的特性视觉模型模块绑定至视觉模型，以及如果存在针对行按钮的特性数据模型模块，则可以将其绑定至数据模型。

通过本申请实施例，在初始列表中配置各种对应相应业务需求的数据模型模块和相应的视觉模型模块，可以有效解决初始列表的特性不够丰富(例如，不支持行按钮、批量操作按钮配置，等)的问题。尤其是，在一些ERP软件中，存在长期持续的针对列表特性的扩展的需求，可以满足ERP软件的持续性维护和扩展。

图2示出了根据本申请实施例的列表组件的一示例的架构示意图。

如图2所示，在列表组件的架构中存在数据模型210和视图模型220，并且在数据模型210中可以设有多个业务数据模型模块(例如，211、213…21n)，在视图模型220中存在多个业务视图模型模块(例如，221、22n…22n)。这里，每一个业务视图模型模块分别用于基于相应的业务数据模型模块进行渲染，例如211与221，213和223相对应等。

具体地，各个业务视图模型模块可以与列表所呈现出的一个或多个显示控件相对应，因此通过业务视图模型模块可以触发与用户之间的交互操作，例如接收用户输入信息，并以此来更新数据模型中相应的业务数据模型模块。进一步地，在业务数据模型模块更新数据状态之后，可以对相应的业务视觉模型模块进行渲染处理。

具体地，列表组件在模型上做了更多细粒度的区分，数据模型主要是用来负责描述整个组件的状态以及处理复杂的业务，如计算列表宽度、行数据的合计计算，同时当外部调用数据模型接口更改某个状态的时候，会自动同步刷新视图模型。此外，视图模型主要负责渲染呈现给用户使用的交互界面，并收集用户的操作反馈给数据模型，同时它依托于数据模型提供的状态，根据状态来处理DOM的表现以及交互。

基于如图2所示的数据模型设计结构，可以衍生一些其它的功能性模型，比如数据模型下的业务数据模型模块211(例如，GridHeaderStore)可以是被用来处理表头相关的一些状态，比如表头中的标题，操作栏的显示隐藏等，对应的它也会在视图模型中有业务视图模型模块221(例如，GridHeaderView)负责对其进行渲染到界面。这样，后续其它开发者再参与开发过程时，能够很快学习并复用这种结构模式，快速开发一些其它的功能需求。

需说明的是，目前市面上的列表组件功能特性不多，主要表现为没有工具栏，不提供视图的切换，对树行列表支持不够友好等。

相应地，基于图2中的列表架构，可以对列表组件的相关交互功能进行优化。示例性地，可以增加视图选择的组件，其目的主要是用来解决当用户切换不同的视图时，可以动态地去切换相应的列进行显示。这里，视图指的是一个预先按照设定呈现给用户的列表，比如已审核的视图、未审核的视图。由此，列表通过内置视图选择功能，能够提高程序开发效率。

此外，还可以增加批量操作工具栏、全局操作工具栏和行操作工具栏等，每个工具栏的应用场景也可以存在不同。具体地，批量操作工具栏的使用场景是当列表是多选的时候，如果选中了大于1行的数据，那么就会显示批量操作工具栏，否则不会显示，其好处是明确了只有选择了行用户才能进行相关的操作按钮交互，同时也简化了对操作按钮可见性控制的程序逻辑。

另一方面，还可以对树行结构的列表增加更多的使用特性，例如树行结构的列表所代表的是显示的数据是具有层级关系的，例如，可以对树形列表增加了层级图标，每一个层级都可以定义不同的图标显示。在一些实施方式中，可以在对应的组件标签上配置level-icons并且值为类似icon-folder，这样软件程序会按照当前渲染行的层级深度，进行图标的渲染。同时，还可以增加快速展开到指定层级的指示器，方便用户快速的进行数据的浏览。

在本申请实施例中，分离列表组件中的数据和视图，属性配置独立且简单，简化了开发产品的使用方式，，便于开发者理解，降低了学习成本。此外，可以通过数据模型模块和视图模型模块的配置过程，增加市面上列表没有的功能特性，不仅能够提升用户的使用体验，也能提高开发者的程序开发效率。另外，可以结合ERP的特性，内置常用的一些交互特性，如刷新按钮、层级列表、树行列表、视图切换等，同时产品开发通过简单的使用也能接入这些特性。进一步地，在代码扩展性上，在后续列表开发特性时，其它的开发者能够很快地复用现有的产品模式，进行功能开发。

图3示出了根据本申请实施例的在业务删除场景下的个性化列表开发方法的一示例的流程图。

如图3所示，在步骤310中，确定列表开发请求的开发类型。

在步骤320中，当列表开发请求为业务删除请求时，在视觉模型下的各个业务视觉模型模块中，确定与业务删除请求相对应的第二目标业务视觉模型模块。示例性地，开发者可以选中列表中的显示控件进行删除，从而生成针对该显示控件所对应的业务视觉模型模块的业务删除请求。

在步骤330中，在数据模型下的各个业务数据模型模块中，确定与第二目标业务视觉模型模块相对应的第二目标业务数据模型模块。

在步骤340中，删除数据模型中的第二目标业务数据模型模块。

通过本申请实施例，在业务数据模型模块和业务视觉模型模块是关联对应的，可以在收到针对业务视觉模型模块的删除操作时，自动将与该业务视觉模型模块相对应的业务数据模型一并删除，而不需要开发者针对对应数据方面的代码进行删除处理，无需了解深层次的代码逻辑，有助于提高列表的开发效率并降低了开发门槛。

图4示出了根据本申请实施例的列表编辑模式配置方法的一示例的流程图。具体地，每一业务视觉模型模块分别与初始列表的一个或多个显示控件相对应。

如图4所示，在步骤410中，确定列表开发请求的开发类型。

在步骤420中，当列表开发请求为列表编辑开发请求时，确定列表编辑开发请求所对应的列表编辑模式。

在步骤430中，基于列表编辑模式配置初始列表的视觉模型所对应的各个可编辑控件。

这里，在行编辑模式下的列表用于响应用户操作而激活聚焦行中的各个可编辑控件，例如在用户对列表进行交互操作之后，可以突出显示用户所选行中的各个可编辑控件。另外，在模拟全列表编辑模式下的列表用于响应用户操作而激活列表中的各个可编辑控件，例如在用户对列表进行交互操作之后，可以突出显示当前列表中的各个可编辑控件。

通过本申请实施例，可以为列表配置多样化的编辑模式，满足列表开发的个性化需求。此外，由于视觉模型与数据模型是关联的，在列表实现个性化的编辑模式的同时，还能使得列表显示能够与列表数据联动，无需对数据相关的代码进行维护，降低了程序开发成本和难度，有利于后续的可持续性的维护和扩展。

此外，可以针对开发产品增加一些符合ERP特性的特性，例如视图切换、树行列表、分页、合计等特性，能够极大地覆盖产品的使用场景，而不需要产品再继续开发类似功能。

需说明的是，目前相关技术中的列表组件并不能根据属性配置去控制列表的编辑以及查看的启用，例如当编辑控件在值发生改变时候，也并不会去处理编辑控件所属列的合计值。

此外，目前市面上使用父子级组件时，子级组件都会通过手动指定一个名称标识，告诉父级组件需要将子级组件挂载到父级组件的具体哪个位置上，此时对于使用人员来说是不太便利的。

鉴于此，图5示出了根据本申请实施例的个性化列表开发方法的一示例的流程图。

如图5所示，在步骤510中，基于列表编辑模式配置初始列表的视觉模型所对应的各个可编辑控件。

在步骤520中，获取数据输入同步显示开发请求。示例性地，开发者可以对客户端进行操作，以激活数据输入同步显示开发功能。

在步骤530中，确定与数据输入同步显示开发请求对应的目标可编辑控件。

在步骤540中，确定与目标可编辑控件对应的第三业务视觉模型模块和相应的第三业务数据模型模块。

在步骤550中，在目标可编辑控件和第三业务数据模型模块之间配置虚拟组件，使得基于所配置的虚拟组件，将目标可编辑控件所接收到的输入数据同步至第三业务数据模型模块，并联动第三业务视觉模型模块进行渲染。

通过本申请实施例，在可编辑控件与业务数据模型之间配置虚拟组件，使得基于可编辑控件所收到的输入数据可以被同步至相应的业务数据模型模块，联动渲染相应的视觉模型模块。

在本申请实施例中，使用了虚拟组件机制，使得用户在使用虚拟组件的时候不需要传递具体的名称标识，就像使用普通的HTML标签一样。

示例性地，

<hc-grid>

<hc-grid-view-select slot＝"view-select"></hc-grid-view-select>

</hc-grid>

上面代码片段为目前相关技术中的代码编写方式，此时是需要用户在hc-grid-view-select中通过配置slot为view-select之后才能正确渲染组件，下面为优化后的代码片段：

<hc-grid>

<hc-grid-view-select></hc-grid-view-select>

</hc-grid>

通过对比可知，不再需要开发者手动传递slot＝"view-select"的标识了。

图6示出了根据本申请实施例的基于虚拟组件进行渲染的一示例的流程图。

虚拟组件610是指不会输出DOM元素的组件，其可以仅仅是在内存中创建了一个对象。应理解的是，DOM元素可以表示网页呈现的基本单元。

显示控件620(或显示子组件)是指真实的会输出DOM元素的控件，同时可以将这个组件放到列表组件中对应的位置，即控件在界面上呈现时的具体位置。

如图6所示，用户可以通过列表更新外部数据源，并将外部的数据源传递给虚拟组件610，虚拟组件610接收到外部的数据时内部会做一个差异对比。如果有改变，会将改变的值同步更新到相应的业务数据模型模块630中，同时基于业务数据模型模块630也会更新对应的界面上的显示控件的呈现效果。由此，优化了列表使用方式，相关的组件配置都是根据相匹配的特性来设置的，比如只有在开启树列表特性的时候才会有层级列的配置，通过将特性具化为实际的子组件，然后子组件自身去分摊自己的配置，这样就能做到按需使用特性以及配置，产品使用过程也会更加简单、清晰。

图7示出了根据本申请实施例的客户端显示个性化列表的一示例的流程图。

如图7所示，在步骤710中，检测列表的编辑状态。具体地，当列表开始进入渲染时，会根据当前上下文中的单元格信息进行单元格的渲染，首先会检查当前列表的编辑状态。

如果列表处于非编辑状态，则跳转至步骤720。如果列表处于可编辑状态，则跳转至步骤730。

在步骤720中，直接将单元格的值渲染到客户端界面。需要说明的是，单元格是由行+列的方式产生的，它的值为行上的数据和列属性字段得出来的，如Row[Column.Field]。

在步骤730中，检查当前列表的编辑模式是行编辑模式还是模拟全列表编辑模式。

如果是行编辑模式，则跳转至步骤740。如果是模拟全列表编辑模式，则跳转至步骤750。

在步骤740中，将列表当前行中的单元格内编辑控件激活并渲染到单元格中。需要说明的是，具体渲染哪种编辑控件可以是根据用户在使用的时候使用的那种编辑控件模板标签决定的，如：

<hc-grid>

<hc-grid-columns>

<hc-grid-column>

<hc-grid-column-spinner></hc-grid-column-spinner>

</hc-grid-column>

</hc-grid-columns>

</hc-grid>

在上述示例代码中，“hc-grid-column-spinner”可以用来表示单元格中的编辑控件是数值输入的编辑控件。

在步骤750中，渲染列表当前行中的单元格编辑控件，同时还会将非当前行中的具有编辑控件的单元格渲染一个实线框。需说明的是，此时单元格仅仅渲染了一个边框，并没有渲染可编辑控件，这种模式的优势是可以提前让开发用户感知列表中的哪些单元格是可以编辑的，同时也解决了大量渲染可编辑控件产生的性能损耗。

在一些实施方式中，当可编辑控件的值发生改变的时，可以在内部会调用列表数据模型中更新数据的接口，同时如果当前更新的数据是数字类型，那么程序会自动检查当前更新数据所属的列下面所有的行对应的数据进行加法运算得出最终的合计值。需要说明的是，非数字类型是无法参与合计计算的。

通过这种方式，解决了列表编辑场景时的控件渲染到控件更新数据整个流程。

在目前相关技术中，当列表处于编辑模式并且开启了“列表左右区域冻结功能”时，用户可以通过按住键盘tab键来切换编辑控件焦点，而并不能自动的切换到下一行的场景。需要说明的是，“列表左右区域冻结功能”可以是指对列表内容区域的左边和右边做了固定，也就是当拖动底部的滚动条时，左右区域始终固定位在列表容器的左右两边，并不会跟随滚动条一起滚动，通过这种方式将重要的列放到冻结区域中，可以极大提升用户的体验。

然而，浏览器默认的焦点行为是从上到下，从左到右依次将编辑元素获取焦点，此时因为左右冻结区域和中间内容区域是分离开的，导致不能很好的利用浏览器默认的行为获取焦点，例如无法实现跨区域的焦点定位功能。

在本申请实施例的一些示例中，在对列表配置相应的列表编辑模式时，可以针对初始列表的视觉模型所对应的各个可编辑控件，分别配置相应的抽象焦点节点。这里，抽象焦点节点可以用于检测用户操作和列表编辑模式并依据检测结果来激活或不激活相应的可编辑控件。

通过本申请实施例，可以对可编辑控件配置相应的抽象焦点节点，并利用抽象焦点节点来监测在相应列表编辑模式下的用户操作，可以实现个性化的列表编辑模式，例如在检测到行编辑模式下的针对控件的操作时，可以突出显示该控件所在行中所有的可编辑控件。另外，在检测到模拟全列表编辑模式下的针对控件的操作时，可以突出显示列表中所有可编辑控件。因此，即使客户端开启了“列表左右区域冻结功能”，基于抽象焦点节点的聚焦监听功能，也依然可以保证编辑控件在界面上能正确地被聚焦。

图8示出了根据本申请实施例的客户端显示个性化列表的一示例的流程图。

在步骤810中，当列进入渲染时，在渲染每个单元格前检测是否存在对应的抽象焦点节点。

如果在步骤810中检测到相应的抽象焦点节点，则跳转至步骤820。如果在步骤步骤820中没有检测到相应的抽象焦点节点，则跳转至步骤830。

在步骤820中，销毁掉所检测到的抽象焦点节点。由此，保证浏览器内存正确释放，并且不会产生垃圾数据。

在步骤830中，渲染列表单元格。

在步骤840中，检测列表单元格是否是允许编辑的。需要说明的是，单元格是否可以编辑取决于当前列表是否开启了允许编辑的属性，同时单元格对应的列中使用了列表编辑控件。

如果列表单元格不允许编辑，则跳转至步骤850。如果列表单元格允许编辑，则跳转至步骤860。

在步骤850中，针对列表单元格，直接渲染出相应的显示控件。

在步骤860中，基于与列表单元格对应的抽象焦点节点，监听抽象焦点节点被聚焦时的事件回调。

在一些实施方式中，如果抽象焦点节点被聚焦，则通知可编辑控件调用自己内部实现的聚焦接口，使编辑控件在界面上也能正确被聚焦。

通过以上步骤，完成了列表单元格和抽象焦点的绑定。结合应用场景来说，客户端可以监听用户的键盘事件(例如，用户按下Tab键)，列表内部可以根据当前聚焦的抽象节点所属的行，找到下一个抽象节点。如果没有找到，则继续往下一行进行查找，直到找到抽象节点，并且使抽象节点聚焦，从而触发编辑控件也能正确聚焦。

通过在列表渲染单元格阶段根据当前列表的编辑状态，以及单元格所属列中的编辑控件类型信息，渲染对应的编辑控件，同时也通过虚拟焦点机制，解决了编辑控件焦点切换问题，目前已经内置常用的列表编辑控件，如文本输入框、数值输入框、下拉选择、自动完成等，实现了录入列表数据。

在本申请实施例中，列表的聚焦行为既没有依赖浏览器的默认行为，也不依赖界面DOM的排列方式，可以以行的维度进行单元格抽象焦点的查找，进而进行聚焦，达到和浏览器默认行为一致的体验效果。

基于本申请实施例的列表组件，能够快速地实现如渲染树形列表、控制视图切换、绑定操作按钮、动态更改编辑查看模式等功能，提高了产品的开发效率也保证了交互的一致性。此外，由于产品都是使用的同一个列表组件，后续列表组件有新的特性更新或者问题修复都能很快的将产品所有用到列表的地方全部应用上。

图9示出了根据本申请实施例的个性化列表开发装置的一示例的结构框图。

如图9所示，个性化列表开发装置900包括开发请求获取单元910、模型确定单元920、开发类型确定单元930、增添模型模块确定单元940和模型模块配置单元950。

开发请求获取单元910用于获取针对初始列表的列表开发请求。

模型确定单元920用于为确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于基于相应的所述业务数据模型模块进行渲染。

开发类型确定单元930用于确定所述列表开发请求的类型。

增添模型模块确定单元940用于当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块。

模型模块配置单元950用于在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

在本申请实施例的一些示例中，所述装置900还包括模型业务删除单元960，其用于：当所述列表开发请求为业务删除请求时，在所述视觉模型下的各个业务视觉模型模块中，确定与所述业务删除请求相对应的第二目标业务视觉模型模块；在所述数据模型下的各个业务数据模型模块中，确定与所述第二目标业务视觉模型模块相对应的第二目标业务数据模型模块；删除所述数据模型中的所述第二目标业务数据模型模块。

在本申请实施例的一些示例中，每一所述业务视觉模型模块分别与所述初始列表的一个或多个显示控件相对应，所述装置900还包括列表编辑模式配置单元970，其用于：当所述列表开发请求为列表编辑开发请求时，确定所述列表编辑开发请求所对应的列表编辑模式；基于所述列表编辑模式配置所述初始列表的视觉模型所对应的各个可编辑控件，其中在行编辑模式下的列表用于响应用户操作而激活聚焦行中的各个可编辑控件，在模拟全列表编辑模式下的列表用于响应用户操作而激活列表中的各个可编辑控件。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

图10是本申请实施例的移动终端的一示例的示意图。如图10所示，该实施例的移动终端1000包括：处理器1010、存储器1020以及存储在所述存储器1020中并可在所述处理器1010上运行的计算机程序1030。所述处理器1010执行所述计算机程序1030时实现上述个性化列表开发方法实施例中的步骤，例如图1所示的步骤110至150。或者，所述处理器1010执行所述计算机程序1030时实现上述各装置实施例中各模块/单元的功能，例如图9所示单元910至950的功能。

示例性的，所述计算机程序1030可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器1020中，并由所述处理器1010执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序1030在所述移动终端1000中的执行过程。例如，所述计算机程序1030可以被分割成开发请求获取程序模块、模型确定程序模块、开发类型确定程序模块、增添模型模块确定程序模块和模型模块配置程序模块，各模块具体功能如下：

开发请求获取程序模块用于获取针对初始列表的列表开发请求。

模型确定程序模块用于为确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于基于相应的所述业务数据模型模块进行渲染。

开发类型确定程序模块用于确定所述列表开发请求的类型。

增添模型模块确定程序模块用于当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块。

模型模块配置程序模块用于在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

所述移动终端1000可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述移动终端可包括，但不仅限于，处理器1010、存储器1020。本领域技术人员可以理解，图10仅是移动终端1000的示例，并不构成对移动终端1000的限定，可以包括比图示更多或少的部件，或组合某些部件，或不同的部件，例如所述移动终端还可以包括输入输出设备、网络接入设备、总线等。

所称处理器1010可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器1020可以是所述移动终端1000的内部存储单元，例如移动终端1000的硬盘或内存。所述存储器1020也可以是所述移动终端1000的外部存储设备，例如所述移动终端1000上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器1020还可以既包括所述移动终端1000的内部存储单元也包括外部存储设备。所述存储器1020用于存储所述计算机程序以及所述移动终端所需的其他程序和数据。所述存储器1020还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程。

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

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/移动终端和方法，可以通过其它的方式实现。例如，以上所描述的装置/移动终端实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述单元既可以采用硬件的形式实现，也可以采用软件的形式实现。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种个性化列表开发方法，其特征在于，所述方法包括：

获取针对初始列表的列表开发请求；

确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于基于相应的所述业务数据模型模块进行渲染；

确定所述列表开发请求的开发类型；

当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块；以及

在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

2.如权利要求1所述的方法，其特征在于，当所述列表开发请求为业务删除请求时，所述方法还包括：

在所述视觉模型下的各个业务视觉模型模块中，确定与所述业务删除请求相对应的第二目标业务视觉模型模块；

在所述数据模型下的各个业务数据模型模块中，确定与所述第二目标业务视觉模型模块相对应的第二目标业务数据模型模块；

删除所述数据模型中的所述第二目标业务数据模型模块。

3.如权利要求1所述的方法，其特征在于，每一所述业务视觉模型模块分别与所述初始列表的一个或多个显示控件相对应，其中在确定所述列表开发请求的开发类型之后，所述方法还包括：

当所述列表开发请求为列表编辑开发请求时，确定所述列表编辑开发请求所对应的列表编辑模式；

基于所述列表编辑模式配置所述初始列表的视觉模型所对应的各个可编辑控件，其中在行编辑模式下的列表用于响应用户操作而激活聚焦行中的各个可编辑控件，在模拟全列表编辑模式下的列表用于响应用户操作而激活列表中的各个可编辑控件。

4.如权利要求3所述的方法，其特征在于，当所述列表开发请求为列表编辑开发请求时，所述方法还包括：

针对所述初始列表的视觉模型所对应的各个可编辑控件，分别配置相应的抽象焦点节点，其中所述抽象焦点节点用于检测用户操作和列表编辑模式并依据检测结果来激活或不激活相应的可编辑控件。

5.如权利要求3所述的方法，其特征在于，在基于所述列表编辑模式配置所述初始列表的视觉模型所对应的各个可编辑控件之后，所述方法还包括：

获取数据输入同步显示开发请求；

确定与所述数据输入同步显示开发请求对应的目标可编辑控件；

确定与所述目标可编辑控件对应的第三业务视觉模型模块和相应的第三业务数据模型模块；

在所述目标可编辑控件和所述第三业务数据模型模块之间配置虚拟组件，使得基于所配置的虚拟组件，将目标可编辑控件所接收到的输入数据同步至所述第三业务数据模型模块，并联动所述第三业务视觉模型模块进行渲染。

6.一种个性化列表开发装置，其特征在于，所述装置包括：

开发请求获取单元，用于获取针对初始列表的列表开发请求；

模型确定单元，用于为确定所述初始列表所对应的数据模型和视觉模型，其中所述数据模型包括至少一个业务数据模型模块，所述视觉模型包括至少一个业务视觉模型模块，并且每一所述业务视觉模型模块分别用于基于相应的所述业务数据模型模块进行渲染；

开发类型确定单元，用于确定所述列表开发请求的类型；

增添模型模块确定单元，用于当所述列表开发请求为业务增添请求时，确定所述列表开发请求所对应的第一目标业务数据模型模块和第一目标业务视觉模型模块；以及

模型模块配置单元，用于在所述数据模型中配置所述第一目标业务数据模型模块，并在所述视觉模型中配置所述第一目标业务视觉模型模块。

7.如权利要求6所述的装置，其特征在于，所述装置还包括模型业务删除单元，其用于：

当所述列表开发请求为业务删除请求时，在所述视觉模型下的各个业务视觉模型模块中，确定与所述业务删除请求相对应的第二目标业务视觉模型模块；

在所述数据模型下的各个业务数据模型模块中，确定与所述第二目标业务视觉模型模块相对应的第二目标业务数据模型模块；

删除所述数据模型中的所述第二目标业务数据模型模块。

8.如权利要求6所述的装置，其特征在于，每一所述业务视觉模型模块分别与所述初始列表的一个或多个显示控件相对应，所述装置还包括列表编辑模式配置单元，其用于：

当所述列表开发请求为列表编辑开发请求时，确定所述列表编辑开发请求所对应的列表编辑模式；

基于所述列表编辑模式配置所述初始列表的视觉模型所对应的各个可编辑控件，其中在行编辑模式下的列表用于响应用户操作而激活聚焦行中的各个可编辑控件，在模拟全列表编辑模式下的列表用于响应用户操作而激活列表中的各个可编辑控件。

9.一种移动终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-5中任一项所述的列表开发方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-5中任一项所述的列表开发方法的步骤。

Images