CN103645901A

CN103645901A - 一种基于事件链的用户界面插件化交互方法

Info

Publication number: CN103645901A
Application number: CN201310689128.9A
Authority: CN
Inventors: 章奕; 武剑锋; 王泊; 胡汉英; 黄寅飞; 白硕
Original assignee: Shanghai Stock Exchange
Current assignee: Shanghai Stock Exchange
Priority date: 2013-12-16
Filing date: 2013-12-16
Publication date: 2014-03-19

Abstract

本发明涉及应用程序的用户界面开发领域，具体是一种基于事件链的用户界面插件化交互方法，其特征在于在插件的相互通信中，数据从第一插件A向第二插件B传递，我们将第一插件A作为一个事件源，第一插件A中用户的操作作为事件，第二插件B作为事件监听者。当第二插件B被加载时，第二插件B向第一插件A注册，注册成功之后，一旦第一插件A中有第二插件B感兴趣的事件发生，第一插件A便会将事件通知给监听者第二插件B。本发明同现有技术相比，其优点在于：借助事件链的处理机制，解决应用程序中交互用户界面的插件间通信问题；拥有较佳的灵活性，创建更为稳定的程序，减少开发者的重复编写代码劳动，各个部分之间的耦合度降低，独立性增强。

Description

一种基于事件链的用户界面插件化交互方法

[技术领域]

本发明涉及应用程序的用户界面开发领域，具体是一种基于事件链的用户界面插件化交互方法。

[背景技术]

实现界面层和业务层的分离，这是应用程序开发者一直以来的理想。在传统的开发过程中混淆了大量用于显示逻辑的swing代码和用于业务逻辑的代码，使得界面设计与程序开发无法清晰的分离，导致大量显示逻辑的swing代码不能重用，这常常导致开发者不得不在显示逻辑之间进行单调的复制—粘贴操作，进而导致同一段代码出现多个版本，从而使得程序的调试和设计极其错综复杂。而通过设计模式中的命令模式将业务逻辑代码从显示逻辑中剥离出来，也仅是有限地实现了表现与逻辑的分离，始终没有摆脱显示与业务揉和的问题。

插件化交互方法是为了解决这一问题应运而生的，软件开发者通过公开的插件接口规范，在不修改程序主体（程序运行平台）的情况下对功能进行扩展与加，这样，开发者就可以根据实际需求来分析哪些部分功能由主体完成（即主体插件的基本功能），哪些部分功能由插件完成（即需要扩展的插件功能）。

但是插件化交互必须解决一个问题：如何在主程序与插件间正确地互相通信。目前，主要有三种插件间通信方法：通过包约束条件建立插件之间的关联关系；扩展点机制实现插件间通信；使用单例模式实现插件间信息共享。这三种方法必须显示建立两个插件之间类的关联关系，其中第二种方法还需要通过配置文件建立扩展和扩展点之间的关系。

[发明内容]

本发明的目的是为了解决由于应用程序开发过程中界面设计与程序开发无法清晰的分离，从而使得程序的调试和设计错综复杂，导致显示与业务揉和的技术问题，实现界面层和业务层的分离，使插件化交互方法过程中程序与插件间正确地互相通信。

为了实现上述目的，提供一种基于事件链的用户界面插件化交互方法,在插件的相互通信中，数据从第一插件A向第二插件B传递，我们将第一插件A作为一个事件源，第一插件A中用户的操作作为事件，第二插件B作为事件监听者。当第二插件B被加载时，第二插件B向第一插件A注册，注册成功之后，一旦第一插件A中有第二插件B感兴趣的事件发生，第一插件A便会将事件通知给监听者第二插件B。

所述的具体方法如下：

A.首先，由于第一插件A都能单独作为产品，因而第一插件A判断是否和第二插件B也存在于环境中，如果存在，则启用相应的功能，否则，隐藏与第二插件B相关的功能，插件ID必须是唯一的，能通过第二插件B的ID来检测B是否存在；

B.其次，在第一插件A中定义事件源对象、事件、事件监听器接口；

(a).定义事件源对象：事件源对象提供对监听对象管理，包括监听器对象的注册方法，注销方法，以及将事件通知给监听器，事件源维护了一个监听者队列，所有监听者都需要向事件源注册，加入该队列，当监听者不再监听事件时，便向事件源注销，退出该队列；

（b）.定义事件：事件对象包装了事件相关的具体信息、作为参数传递给监听器，事件对象的具体信息内容用户可以自己定制，包含事件发生的时间，事件源对象；

（c）.定义事件监听器接口：事件监听器接口，所有事件监听者都应该实现该接口，并在具体实现中提供相应的事件处理方法，事件发生时，事件源便调用监听器接口提供的事件处理方法统一通知监听者队列中的所有事件监听器对象。

C.最后，在第二插件B中实现监听器对象，监听器对象必须实现第一插件A中的事件监听接口，提供自身的事件处理方法，并且在第二插件B被加载时，调用第一插件A中的事件源对象类中的添加事件监听方法，将该监听器对象向第一插件A的事件源注册。

一种采用基于事件链的用户界面插件化交互方法的系统，包括程序运行平台和插件两部分，所述的程序运行平台包括应用程序模块、通用界面模块、核心模块，应用程序模块负责具体业务逻辑，可任意调用其他模块，通用界面模块负责界面，且只依赖核心模块，核心模块主要存放需要全局访问的内容，而模型集中存放数据模型，所述插件借助事件链的处理机制，实现了插件与应用程序框架内的各个模块之间的接入与交互，成为应用程序框架的扩展和补充。

所述的事件链的处理机制实现模块与模块之间的松耦合关系，通过建立一条事件链来组织请求的处理者，请求将会沿着链进行传递，请求发送者无须知道请求在何时、何处以及如何处理，实现了请求发送者与处理者的解耦，在系统中，每一个模块都有自己的事件处理器，每个请求都会在所有的事件处理器上流转一遍，这样就可以通过请求来沟通各个模块，从而避免了模块间的跨层调用和反向调用。

本发明同现有技术相比，其优点在于：

1.借助事件链的处理机制，通过事件链组织请求的处理者实现了请求发送者与处理者的解耦及插件与应用程序框架内的各个模块之间的接入与交互，解决由于应用程序开发过程中界面设计与程序开发无法清晰的分离，从而使得程序的调试和设计错综复杂，导致显示与业务揉和的技术问题，实现界面层和业务层的分离，使插件化交互方法过程中程序与插件间正确地互相通信；

2.基于多插件化，拥有较佳的灵活性，可封装核心数据、建立逻辑和功能的计算关系，创建更为稳定的程序，并减少开发者的重复编写代码劳动，同时使整个应用程序中的各个部分之间的耦合度降低，独立性增强。

[附图说明]

图1为事件链的基本架构图；

图2为应用程序入口类关系图；

图3为应用程序入口类关系图；

图4为界面模块类图；

图5为Config通用配置模块图；

指定图1作为本发明的摘要附图。

[具体实施方式]

下面结合附图对本发明作进一步说明，这种系统的结构和原理对本专业的人来说是非常清楚的。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明的设计思路就是对众多应用程序的通用功能等进行抽象提炼，定义成一系列核心模块，并采用事件链机制，专注于一系列核心模块的平台和架构的搭建，而使单个插件的开发更多关注于自身功能的实现，以及插件与核心平台的对接设计上，从而不必过多的考虑与其他模块的易融合性，从而能快速支持业务创新。

实现监听器对象是将两个插件之间的调用关系通过事件机制建立起来之后，我们便可以在监听器和事件中添加用户的逻辑功能。当然，上面是基于Java事件模型的一种参考实现，开发人员也可以完全不依赖Java事件机制，所有基类都可以由用户自己定义。

实施例1

本发明采用事件链机制，从而实现模块与模块之间的松耦合关系，通过建立一条事件链来组织请求的处理者，请求将会沿着链进行传递，请求发送者无须知道请求在何时、何处以及如何处理，实现了请求发送者与处理者的解耦。在系统中，每一个模块都有自己的事件处理器，每个请求都会在所有的事件处理器上流转一遍，这样就可以通过请求来沟通各个模块，从而避免了模块间的跨层调用和反向调用，本质上这种设计是通过一种隐性的绑定来松绑显性的编译层绑定。

如图1所示，图中各部分的具体解释如下表：

实施例2

本发明的核心模块包含如下部分：

1、应用模块（App）：App模块负责具体业务逻辑，可任意调用其他模块。

1）当需要创建一个EzXXX应用程序时，需要继承Application类，实现方法为init()、start()、exit()，即应用程序的初始化、启动和退出，如图2所示；

2）应用开发库会查找应用程序Cfg目录下的component.ini文件中的配置加载应用程序的主程序，component.ini配置文件内容如下：

3）app.class配置为应用的入口主程序EzXXXApp，应用程序管理类RuntimeManager，负责应用程序的启动，app.jar.keyword jar文件的检查关键字，同时也是根据该Jar文件下的MANIFEST.MF文件获取应用程序的版本号信息，如图3所示，图中各部分的功能描述如下表所示：

4）在plugins目录下通过配置文件去管理EzXXX应用程序所需要的应用插件，应用开发库会在应用程序启动时，搜索该目录下的所有插件，并进行初始化和功能启动等。

EzXXX\Plugins目录下会有ezxxxapp、about、config、view等目录，分别是应用、缺省显示、配置、界面等组件的插件，每一个目录下均有plugin.xml配置文件来配置插件，plugin.xml配置文件内容如下所示：

5）plugin.xml中定义了该plugin的名称、入口类、版本、作者。

6）Runtime和require都是该plugin jar包所依赖的jar包环境，通过编译脚本中预先指定的jar包引用关系，这两个属性可暂不使用。

2、通用界面模块（View）：如图4所示，主要包括界面框架，菜单管理，状态栏管理，视图管理。View模块实现了基础Frame，用户仅需开发和制定自己的mainPanel，然后通过Viewport加载到Frame之上即可实现主体界面的展示。

3、Config模块：通用配置管理窗口，集成了前台系统通用的参数配置窗口，调用如下代码即可显示如下图所示效果:

ConfigManager.getInstance().add(new PbuConfigMainPanel());

ConfigManager.getInstance().showConfigDialog();

Configure主窗口界面如图5所示，实现了IConfig接口，实现其中的handleApply()、handleCancel()、handleDefault()、handleOk()方法，即可完成应用、取消、默认、确定的功能。

4、Core核心模块：Core核心模块作为本发明的核心模块，包括以下几个部分：

1）基础框架的main类：会查找应用程序Cfg目录下的component.ini文件中的配置加载应用程序的主程序。

2）RuntimeManager应用程序管理类：应用程序继承Application抽象类，通过RuntimeManager的setup(Application application)方法把应用交给RuntimeManager管理，供RuntimeManager负责初始化，启动和退出的管理。

3）事件链类（chain）；事件链分为同步事件和异步事件，每个异步事件都要到线程池取线程进行处理，所以异步事件只在耗时较长比如IO操作等时使用，且不要频繁使用。同步事件，目前前台软件大部分均使用同步事件处理，所谓同步处理方式，也就是该事件在某事件链上处理完成后才会返回，继续下一个事件的处理。

4）定时器SimpleTimer类：机制类似JDK的Timer，只所以使用SimpleTimer不使用JDK的Timer，是因为JDK的Timer在人为调整本地时间时，会造成Timer不能触发的问题。

5）Util Package：一些共用的方法。

6）Boot模块：系统的入口类，该类会调用Core包下的Main类，使得基于本发明的应用程序均是通过该Boot模块启动的。

7）About模块：缺省显示的菜单项，内容包括：版本信息和版权信息。

关于事件链的部分，需要对接收事件的类进行初始化，并通过Plugin的方式注册，随后当，想触发事件时，加入如下代码即：

Event e=new SimpleEvent(EzXXXEID.EID_MD_MSG_UI_UPDATE, instid, null, null);

ChainServiceImpl.getInstance().getChain().fireEvent(e);

关于界面管理的部分，继承应用开发库中的EzPanel类，制定的主界面panel（如MainPanel）如下所示：

关于菜单管理的部分，通过XML来配置，应用程序会在初始化的时候进行对该配置文件的装载，菜单XML配置文件内容如下所示：

Claims

1.一种基于事件链的用户界面插件化交互方法,其特征在于在插件的相互通信中，数据从第一插件A向第二插件B传递，我们将第一插件A作为一个事件源，第一插件A中用户的操作作为事件，第二插件B作为事件监听者。当第二插件B被加载时，第二插件B向第一插件A注册，注册成功之后，一旦第一插件A中有第二插件B感兴趣的事件发生，第一插件A便会将事件通知给监听者第二插件B。

2.如权利要求1所述的一种基于事件链的用户界面插件化交互方法，其特征在于所述的具体方法如下：

（a）.定义事件源对象：事件源对象提供对监听对象管理，包括监听器对象的注册方法，注销方法，以及将事件通知给监听器，事件源维护了一个监听者队列，所有监听者都需要向事件源注册，加入该队列，当监听者不再监听事件时，便向事件源注销，退出该队列；

（c）.定义事件监听器接口：事件监听器接口，所有事件监听者都应该实现该接口，并在具体实现中提供相应的事件处理方法，事件发生时，事件源便调用监听器接口提供的事件处理方法统一通知监听者队列中的所有事件监听器对象；

3.一种采用如权利要求1所述的基于事件链的用户界面插件化交互方法的系统，包括程序运行平台和插件两部分，其特征在于所述的程序运行平台包括应用程序模块、通用界面模块、核心模块，应用程序模块负责具体业务逻辑，可任意调用其他模块，通用界面模块负责界面，且只依赖核心模块，核心模块主要存放需要全局访问的内容，而模型集中存放数据模型，所述插件借助事件链的处理机制，实现了插件与应用程序框架内的各个模块之间的接入与交互，成为应用程序框架的扩展和补充。

4.如权利要求3所述的基于事件链的用户界面插件化交互系统，其特征在于所述的事件链的处理机制实现模块与模块之间的松耦合关系，通过建立一条事件链来组织请求的处理者，请求将会沿着链进行传递，请求发送者无须知道请求在何时、何处以及如何处理，实现了请求发送者与处理者的解耦，在系统中，每一个模块都有自己的事件处理器，每个请求都会在所有的事件处理器上流转一遍，这样就可以通过请求来沟通各个模块，从而避免了模块间的跨层调用和反向调用。