本发明涉及计算机技术领域，特别涉及一种ExtJS界面的生成方法和装置。
背景技术：
船舶是能航行或停泊于水域进行运输或作业的交通工具，不同型号的船舶具有不同的技术性能、装备或结构型式，并且使用不同的数据通信系统和网络管理软件，以满足不同的使用要求。数据通信系统可以实现船舶的通信，网络管理软件可以对数据通信系统进行监测，并将监测结果通过显示界面呈现给用户。
不同网络管理软件的显示界面一方面会有很多相同之处，比如设定用户权限、显示监控结果等，另一方面也存在一些不同之处，比如用户和权限之间的对应关系、监控结果的呈现方式等。如果对所有船舶的网络管理软件的显示界面进行统一开发，将无法满足各个船舶不同的使用要求，比如有的船舶需要以图形的方式显示监控结果，有的船舶需要以表格的形式显示监控结果。如果对各个船舶的网络管理软件的显示界面分别独立进行开发，又会造成人力物力资源的浪费，比如所有船舶可能都需要显示相同的内容，只是显示的方式不同，显示内容部分会被重复开发，而且很难保证所有船舶的网络管理软件的显示界面的开发质量。
在实现本发明的过程中，发明人发现现有技术至少存在以下问题：
目前显示界面采用ExtJS(用来开发富客户端(英文：Rich Internet Applications，简称：RIA)的异步直译式脚本语言和可扩展标记语言(英文：Asynchronous JavaScript and Extensible Markup Language，简称：AJAX)应用，采用JavaScript编写代码，主要用于创建前端用户界面)生成，由于ExtJS不支持控制反转(英文：Inversion of Control，简称：IoC)，因此无法缺乏复用相同组件的有效手段，因此大量内容重复开发，浪费人力物力资源。
技术实现要素：
为了解决现有技术重复开发、浪费人力物力资源的问题，本发明实施例提供了一种ExtJS界面的生成方法和装置。所述技术方案如下：
一方面，本发明实施例提供了一种ExtJS界面的生成方法，所述生成方法包括：
在配置文件列表中获取ExtJS界面的配置文件的名称；
查找所述配置文件的名称对应的配置文件，所述配置文件包括至少一个类的全名；
从组件库中载入所述配置文件中各个类的全名对应的组件，得到组件的类定义；
根据得到的类定义将界面框架的组件实例化，生成所述ExtJS界面。
可选地，所述组件库包括多个组件，且所述多个组件中，至少两个所述组件的类的别名相同；
所述根据得到的类定义将界面框架的组件实例化，生成所述ExtJS界面，包括：
利用界面框架的组件获取生成所述ExtJS界面需要的类的别名；
在得到的类定义中查找与获取的类的别名对应的类定义；
根据找到的类定义将界面框架的组件实例化，生成所述ExtJS界面。
优选地，所述界面框架的组件包括界面框架的子组件的类的别名，所述界面框架的子组件包括生成所述ExtJS界面需要的类的别名；
所述利用界面框架的组件获取生成所述ExtJS界面需要的类的别名，包括：
在界面框架的组件中，获取界面框架的子组件的类的别名；
在获取的类的别名对应的子组件中，获取生成所述ExtJS界面需要的类的别名。
可选地，所述组件的类和另一个所述组件的类为父子类。
可选地，所述配置文件包括用于判断终端类型的适配判断函数，所述适配判断函数的返回值为真。
另一方面，本发明实施例提供了一种ExtJS界面的生成装置，所述生成装置包括：
获取单元，用于在配置文件列表中获取ExtJS界面的配置文件的名称；
查找单元，用于查找所述配置文件的名称对应的配置文件，所述配置文件包括至少一个类的全名；
载入单元，用于从组件库中载入所述配置文件中各个类的全名对应的组件，得到组件的类定义；
生成单元，用于根据得到的类定义将界面框架的组件实例化，生成所述ExtJS界面。
可选地，所述组件库包括多个组件，且所述多个组件中，至少两个所述组件的类的别名相同；
所述生成单元包括：
获取子单元，用于利用界面框架的组件获取生成所述ExtJS界面需要的类的别名；
查找子单元，用于在得到的类定义中查找与获取的类的别名对应的类定义；
实例化子单元，用于根据找到的类定义将界面框架的组件实例化，生成所述ExtJS界面。
可选地，所述界面框架的组件包括界面框架的子组件的类的别名，所述界面框架的子组件包括生成所述ExtJS界面需要的类的别名；
所述获取子单元用于，
在界面框架的组件中，获取界面框架的子组件的类的别名；
在获取的类的别名对应的子组件中，获取生成所述ExtJS界面需要的类的别名。
可选地，所述组件的类和另一个所述组件的类为父子类。
可选地，所述配置文件包括用于判断终端类型的适配判断函数，所述适配判断函数的返回值为真。
本发明实施例提供的技术方案带来的有益效果是：
通过在配置文件列表中获取到ExtJS界面的配置文件的名称，再查找配置文件的名称对应的配置文件，配置文件包括至少一个类的全名，可以载入配置文件中各个类的全名对应的组件，得到组件的类定义，然后根据得到的类定义将界面框架的组件实例化，即可生成ExtJS界面。由于ExtJS界面是根据得到的类定义生成的，而得到的类定义可以根据配置文件中指定的类的全名确定，同时依据的配置文件可以在配置文件列表中指定，因此在生成不同的ExtJS界面时，只需要根据需要的类选择并在配置文件列表中指定可得到相应类定义的配置文件，即可通过本发明提供的方法生成相应的ExtJS界面，避免在生成不同ExtJS界面时重复开发，节省人力物力资源，显著降低研发和后期维护的成本。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例一提供的一种ExtJS界面的生成方法的流程图；
图2是本发明实施例二提供的一种ExtJS界面的生成装置的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
下面先简单介绍一下本发明实施例提供的ExtJS界面的生成方法的应用场景。
假设当前需要设计A、B、C三种交通工具的ExtJS界面，交通工具A为船舶，交通工具B为飞机，交通工具C为军舰。
以在ExtJS界面上呈现通信状态为例，交通工具A、交通工具B和交通工具C都需要呈现通信链路的通断状态，同时交通工具A不需要呈现通信设备的运行状态；交通工具B和交通工具C还需要呈现通信设备的运行状态。其中，交通工具B以表格的形式显示通信设备的运行状态；交通工具C以图形的形式显示通信设备的运行状态。
综合上述情况，在生成交通工具A、交通工具B和交通工具C的ExtJS界面时，一方面需要对呈现通信链路的通断状态的区域进行统一开发，另一方面需要对呈现通信设备的运行状态的区域分别进行开发。
为此，本发明实施例提供了一种ExtJS界面的生成方法，图1为本实施例提供的ExtJS界面的生成方法的流程图，参见图1，该生成方法包括：
步骤101：在配置文件列表中获取ExtJS界面的配置文件的名称。
在具体实现时，ExtJS具有Ext.app.Profile(简称Profile)特性，可以适配不同系统类型的终端访问ExtJS界面。具体地，在配置文件列表Profile中指定配置文件的名称，即可在获取到配置文件的名称之后，配置文件的名称对应的配置文件利用适配判断函数isActive，自动检测访问ExtJS界面的终端的系统类型。针对一个配置文件来说，当检测到的系统类型与配置文件适用的系统类型相同时(返回真值ture)，根据这个配置文件生成ExtJS界面，从而向终端呈现适配其系统类型的ExtJS界面；反之，当检测到的系统类型与配置文件适用的系统类型不同时，不使用这个配置文件。
本实施例在Profile特性的基础上进行扩展，利用ExtJS的Profile特性，在配置文件列表Profile中指定ExtJS界面的配置文件的名称，根据配置文件的名称即可查找到对应的配置文件，配置文件包括ExtJS界面需要的各个类的全名，根据各个类的全名即可确定对应的组件，也就是说，只要在配置文件列表中获取到配置文件的名称，即可最终确定对应的组件(详见下文)，有效实现相同组件的复用。
具体地，可以在程序的入口Application.js中编写如下代码：
profiles：[‘Profile*’]
其中，Profile*表示具体选择的配置文件的名称。
以本实施例提供的应用场景为例，如果交通工具A、交通工具B和交通工具C分别采用不同的配置文件，则可供选择的配置文件可以包括交通工具A的配置文件ProfileA、交通工具B的配置文件ProfileB和交通工具C的配置文件ProfileC，即Profile*可以为ProfileA、ProfileB或者ProfileC。进一步地，如果是交通工具A的ExtJS界面，则Profile*为ProfileA；如果是交通工具B的ExtJS界面，则Profile*为ProfileB；如果是交通工具C的ExtJS界面，则Profile*为ProfileC。
步骤102：查找配置文件的名称对应的配置文件，配置文件包括至少一个类的全名。
以应用场景中呈现通信设备的运行状态为例，相应设置有以表格的形式显示通信设备的运行状态的组件1、以及以表格的形式显示通信设备的运行状态的组件2。当设计交通工具A的ExtJS界面时，配置文件既不包括组件1的类的全名，也不包括组件2的类的全名；当设计交通工具B的ExtJS界面时，配置文件包括组件1的类的全名；当设计交通工具C的ExtJS界面时，配置文件包括组件2的类的全名。
可选地，配置文件可以包括用于判断终端类型的适配判断函数，适配判断函数的返回值为真。
如前所述，ExtJS的Profile特性适配不同系统类型的终端访问ExtJS界面时，在配置文件列表中获取到可用的配置文件的名称之后，获取到的配置文件的名称对应的配置文件利用适配判断函数，判断访问ExtJS界面的终端的系统类型是否与适配的系统类型相同。本实施例为了确保可以根据配置文件载入ExtJS界面需要的各个类对应的组件，将适配判断函数的返回值固定为真值，在具体实现时即可免去对终端的系统类型的判断，在查找到配置文件的名称对应的配置文件之后，即可从中得到ExtJS界面的需要的各个类的全名，进而载入得到的类的全名对应的组件(详见下文)。
具体地，在配置文件profile/ProfileA中可以编写如下代码：
views:[
‘XX.view.ShipConfig’,
‘XX.view.UserConfig’,
……
]
在配置文件profile/ProfileB中可以编写如下代码：
views:[
‘XX.view.PlaneConfig’,
‘XX.view.UserConfig’,
……
]
在配置文件profile/ProfileC中可以编写如下代码：
views:[
‘XX.view.WarShipConfig’,
‘XX.view.UserConfig’,
……
]
相应地，XX.view.ShipConfig、XX.view.PlaneConfig、XX.view.WarShipConfig和XX.view.UserConfig为四个类的全名。其中，XX.view.UserConfig为交通工具A、交通工具B和交通工具C的配置文件中共同使用的类的全名，XX.view.ShipConfig为交通工具A的配置文件中单独使用的类的全名，XX.view.PlaneConfig为交通工具B的配置文件中单独使用的类的全名，XX.view.WarShipConfig为交通工具C的配置文件中单独使用的类的全名。
如前所述，如果Profile*为ProfileA，则将XX.view.ShipConfig和XX.view.UserConfig对应的组件载入；如果Profile*为ProfileB，则将XX.view.PlaneConfig和XX.view.UserConfig对应的组件载入；如果Profile*为ProfileC，则将XX.view.WarShipConfig和XX.view.UserConfig对应的组件载入。
步骤103：从组件库中载入配置文件中各个类的全名对应的组件，得到组件的类定义。
可选地，组件的类和另一个组件的类可以为父子类。
在具体实现时，子类可以继承父类的特性，两个组件的类之间为父类和子类的关系，可以避免在子类中重新定义与父类相同的部分，减少开发和维护的工作量，节省人力物力的成本。
比如舰船是一种特殊的船舶，除了具有船舶的功能以外，还具有特殊的功能，因此在实际应用中，可以将船舶配置的组件的类定义为父类，舰船配置的组件的类定义为子类，使舰船配置的组件的类继承船舶配置的组件的类，避免在舰船配置的组件的类定义时，再次定义与船舶配置的组件的类相同的部分。
具体地，在组件ShipConfig.js中可以编写如下代码：
Ext.define(‘XX.view.ShipConfig’,{
extend:‘Ext.container.Container’,
xtype:‘platconfig’,
……
})；
在组件PlaneConfig.js中可以编写如下代码：
Ext.define(‘XX.view.PlaneConfig’,{
extend:‘Ext.container.Container’,
xtype:‘platconfig’,
……
})；
在组件WarShipConfig.js中可以编写如下代码：
Ext.define(‘XX.view.WarShipConfig’,{
extend:‘XX.view.ShipConfig’,
xtype:‘platconfig’,
……
})；
具体地，在组件UserConfig.js中可以编写如下代码：
Ext.define(‘XX.view.UserConfig’,{
extend:‘Ext.container.Container’,
xtype:‘userconfig’,
……
})；
其中，ShipConfig.js、PlaneConfig.js、WarShipConfig.js和UserConfig.js为组件的名称，Ext.define后是类的全名XX.view.ShipConfig、XX.view.PlaneConfig、XX.view.WarShipConfig和XX.view.UserConfig，extend后是继承的类，xtype后是类的别名。
可以看出，ShipConfig.js、PlaneConfig.js和WarShipConfig.js采用相同的类的别名platconfig。另外，XX.view.WarShipConfig继承XX.view.ShipConfig，XX.view.ShipConfig为父类，XX.view.WarShipConfig为子类。
步骤104：根据得到的类定义将界面框架的组件实例化，生成ExtJS界面。
可选地，组件库中可以包括多个组件，且多个组件中，至少两个组件的类的别名可以相同。
相应地，该步骤104可以包括：
利用界面框架的组件获取生成ExtJS界面需要的类的别名；
在得到的类定义中查找与获取的类的别名对应的类定义；
根据找到的类定义将界面框架的组件实例化，生成ExtJS界面。
在具体实现时，类的别名相同的组件可以为实现功能相同且实现方式不同的至少两个组件。比如实现功能都是显示通信设备的运行状态，一个实现方式是以表格的形式显示，另一个实现方式是以图形的方式显示。由于都需要显示通信设备的运行状态，因此采用相同的别名，界面框架的组件中指定的类的别名在两次实现时就不会变化，可以减少开发和维护的工作量。至于两种不同的实现方式，由于类的全名是不同的，因此只要指定对应的配置文件，就可以载入对应的组件，采用相同的别名也可以从载入的组件中得到需要的类定义，进而根据得到的类定义进行实例化。
在实际应用中，类的别名可以采用xtype创建。
在具体实现时，访问ExtJS中的组件可以使用组件的完整类名(即全名)，也可以使用非完整类名(即别名)，如xtype。xtype可以尽可能保持类名的不同，同时在类名相同时还可以避免发生冲突，以免同一个类名被重复定义。具体地，当两个组件采用相同的xtype，则后载入的组件会覆盖先载入的组件并生效。
利用上述特点，在实际应用中，当至少两个载入的组件的xtype相同时，可以通过控制载入顺序保证生效的组件。特别地，可以父类和子类采用同一个xtype，由于父类先载入，子类后载入，因此必定是子类生效，特别适用于对通用组件的针对性扩展开发。以船舶配置的组件的类定义为父类，舰船配置的组件的类定义为子类为例，船舶配置的组件的类和舰船配置的组件的类别名相同，先载入船舶配置的组件，再载入舰船配置的组件，这样舰船配置的组件的类定义先继承与舰船配置的组件的类相同的部分，再定义与船舶配置的组件的类不同的部分即可，大大减少开发和维护的工作量。
具体地，利用界面框架的组件获取生成ExtJS界面需要的类的别名，可以包括：
在界面框架的组件中，获取生成ExtJS界面需要的类的别名。
具体地，可以在profiles：[‘Profile*’]之后编写如下代码：
mainView:’XX.view.Main’
如果ExtJS界面的框架都相同，则在界面框架组件Main.JS中可以编写如下代码：
Ext.define(‘XX.view.Main’,{
extend:‘Ext.container.Container’,
items:[
{xtype:’platconfig’,},
{xtype:’userconfig’},
……
]
即直接在界面框架的组件Main.JS中，获取生成ExtJS界面需要的类的别名platconfig、userconfig。
优选地，界面框架的组件可以包括界面框架的子组件的类的别名，界面框架的子组件可以包括生成ExtJS界面需要的类的别名。
相应地，利用界面框架的组件获取生成ExtJS界面需要的类的别名，可以包括：
在界面框架的组件中，获取界面框架的子组件的类的别名；
在获取的类的别名对应的子组件中，获取生成ExtJS界面需要的类的别名。
在具体实现时，ExtJS中的组件为容器类组件(Ext.container.Container)，容器类组件中可以设置子组件。当对容器类组件实例化时，会先对容器类组件中的子组件实例化。在上述实现方式中，界面框架的组件中设置界面框架的子组件，当对界面框架的组件实例化时，会根据界面框架的组件包括的界面框架的子组件的别名，将对应的界面框架的子组件实例化，而对界面框架的子组件实例化时，会根据界面框架的子组件包括的各个类的别名和载入的组件得到的类定义进行实例化。这样在界面框架的组件中，不需要具体指定ExtJS界面需要的类(包括全名和别名)，只要在配置文件中指定界面框架的子组件的类的全名，即可在根据配置文件载入组件时，将指定的界面框架的子组件载入，从而在生成ExtJS界面时按照上述流程进行实例化。
如果ExtJS界面的框架存在不同，则在界面框架组件Main.JS中可以编写如下代码：
Ext.define(‘XX.view.Main’,{
extend:‘Ext.container.Container’,
items:[
{xtype:’frame’,},
……
]
相应地，在配置文件profile/ProfileA中编写的代码可以改为如下形式：views:[
‘XX.view.FrameA’,
‘XX.view.ShipConfig’,
‘XX.view.UserConfig’,
……
]
在配置文件profile/ProfileB中编写的代码可以改为如下形式：
views:[
‘XX.view.FrameB’,
‘XX.view.PlaneConfig’,
‘XX.view.UserConfig’,
……
]
相应地，增加的组件FrameA.js中可以编写如下代码：
Ext.define(‘XX.view.FrameA’,{
extend:‘Ext.container.Container’,
xtype:‘frame’,
items:[
{xtype:’platconfig’,},
{xtype:’userconfig’},
……
]
……
})；
增加的组件FrameB.js中可以编写如下代码：
Ext.define(‘XX.view.FrameB’,{
extend:‘Ext.container.Container’,
xtype:‘frame’,
items:[
{xtype:’platconfig’,},
……
]
……
})；
如果Profile*为ProfileA，则将XX.view.FrameA、XX.view.ShipConfig和XX.view.UserConfig对应的组件载入，实例化时按照组件FrameA.js，依次根据载入的组件的类定义，将XX.view.ShipConfig和XX.view.UserConfig实例化；如果Profile*为ProfileB，则将XX.view.PlaneConfig和XX.view.UserConfig对应的组件载入，实例化时按照组件FrameB.js，依次根据载入的组件的类定义，将XX.view.ShipConfig实例化。
可选地，该生成方法还可以包括：
接收用户选择的配置文件的名称；
在配置文件列表中设置接收的名称。
可选地，该生成方法还可以包括：
接收用户选择的至少类的全名，生成配置文件。
可选地，该生成方法还可以包括：
接收并保存用户输入的组件。
具体地，ExtJS界面的代码在MVVM(Model-View-ViewModel)架构的基础上编写。
本发明实施例通过在配置文件列表中获取到ExtJS界面的配置文件的名称，再查找配置文件的名称对应的配置文件，配置文件包括至少一个类的全名，可以载入配置文件中各个类的全名对应的组件，得到组件的类定义，然后根据得到的类定义将界面框架的组件实例化，即可生成ExtJS界面。由于ExtJS界面是根据得到的类定义生成的，而得到的类定义可以根据配置文件中指定的类的全名确定，同时依据的配置文件可以在配置文件列表中指定，因此在生成不同的ExtJS界面时，只需要根据需要的类选择并在配置文件列表中指定可得到相应类定义的配置文件，即可通过本发明提供的方法生成相应的ExtJS界面，避免在生成不同ExtJS界面时重复开发，节省人力物力资源，显著降低研发和后期维护的成本。
本发明实施例提供了一种ExtJS界面的生成装置，图2为本实施例提供的ExtJS界面的生成装置的结构示意图，参见图2，该生成装置包括：
获取单元201，用于在配置文件列表中获取ExtJS界面的配置文件的名称；
查找单元202，用于查找配置文件的名称对应的配置文件，配置文件包括至少一个类的全名；
载入单元203，用于从组件库中载入配置文件中各个类的全名对应的组件，得到组件的类定义；
生成单元204，用于根据得到的类定义将界面框架的组件实例化，生成ExtJS界面。
可选地，组件库可以包括多个组件，且多个组件中，至少两个组件的类的别名相同。
相应地，生成单元204可以包括：
获取子单元，用于利用界面框架的组件获取生成ExtJS界面需要的类的别名；
查找子单元，用于在得到的类定义中查找与获取的类的别名对应的类定义；
实例化子单元，用于根据找到的类定义将界面框架的组件实例化，生成ExtJS界面。
可选地，界面框架的组件可以包括界面框架的子组件的类的别名，界面框架的子组件包括生成ExtJS界面需要的类的别名；
相应地，获取单元201可以用于，
在界面框架的组件中，获取界面框架的子组件的类的别名；
在获取的类的别名对应的子组件中，获取生成ExtJS界面需要的类的别名。
可选地，组件的类和另一个组件的类可以为父子类。
可选地，配置文件可以包括用于判断终端类型的适配判断函数，适配判断函数的返回值为真。
本发明实施例通过在配置文件列表中获取到ExtJS界面的配置文件的名称，再查找配置文件的名称对应的配置文件，配置文件包括至少一个类的全名，可以载入配置文件中各个类的全名对应的组件，得到组件的类定义，然后根据得到的类定义将界面框架的组件实例化，即可生成ExtJS界面。由于ExtJS界面是根据得到的类定义生成的，而得到的类定义可以根据配置文件中指定的类的全名确定，同时依据的配置文件可以在配置文件列表中指定，因此在生成不同的ExtJS界面时，只需要根据需要的类选择并在配置文件列表中指定可得到相应类定义的配置文件，即可通过本发明提供的方法生成相应的ExtJS界面，避免在生成不同ExtJS界面时重复开发，节省人力物力资源，显著降低研发和后期维护的成本。
需要说明的是：上述实施例提供的ExtJS界面的生成装置在生成ExtJS界面时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将单元的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的ExtJS界面的生成装置与ExtJS界面的生成方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。