CN106547525A - 一种执行完全状态模式的web app的方法和装置 - Google Patents

Abstract

本申请提供了一种执行完全状态模式的web app的方法、执行完全状态模式的web app的装置、一种完全状态模式APP，涉及计算机技术领域。所述方法包括：预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。本申请对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。

Description

一种执行完全状态模式的web app的方法和装置

技术领域

本申请涉及计算机技术领域，特别是涉及一种执行完全状态模式的web app的方法和一种执行完全状态模式的web app的装置。

背景技术

web app是一种通过网络(如互联网或内联网)访问的应用程序；也可以指计算机软件承载在浏览器支持环境下或使用浏览器支持语言(如JavaScript，脚本)并依赖于web浏览器来渲染的应用程序。web app的流行归功于网页浏览器的普及，以及使用这一轻薄客户端方便的用户体验。不必下载安装就可以实现更新和维护，具有支持跨平台的内在属性，是web app开始流行的关键原因。典型的web app产品包括web邮箱、web商店、wikis等等。要实现web app必须满足以下几点关键条件：

(1)用户交互。web app必须可以提供界面给用户进行数据展示和用户操作。

(2)数据交互。web app必须可以使用http协议通过互联网与web服务进行交互，如数据下载和上传

(3)安全保证。web app必须有能力识别用户身份和权限。

但是在先技术中，对于web app，其对各个阶段的业务逻辑都在一起实现，其存在大量的条件语句，而巨大的条件语句是不受欢迎的，它们形成一大整块并且使得代码不够清晰，这又使得它们难以修改和扩展，耦合性高。比如，在先技术中，对web app的编辑和保存在一个类中，其中，保存时不需要先判断启用哪部分键盘事件和鼠标事件，并且禁用哪部分键盘事件和鼠标事件，而在进行保存行为时也需要先判断启用哪部分键盘事件和鼠标事件，并且禁用哪部分键盘事件和鼠标事件，编辑行为和保存行为对于键盘和鼠标事件的判断则存在耦合，并且代码量较多。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种执行完全状态模式的web app的方法和相应的一种执行完全状态模式的web app的装置。

为了解决上述问题，本申请公开了一种执行完全状态模式的web app的方法，其特征在于，包括：

预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

为了解决上述问题，本申请还公开了一种执行完全状态模式的web app的装置，包括：

预置模块，用于预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

状态执行模块，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

为了解决上述问题，本申请还公开了一种完全状态模式web app，包括：

状态执行模块，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类；其中所述各个状态类根据web app的状态设置，所述web app的状态根据决定web app行为变化的属性进行划分；其中，每个状态类包括 相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。

本申请实施例包括以下优点：

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，即条件判断语句的数量少，分散到具体的状态类中，耦合性低。

比如，对web app的编辑和保存，分别设置编辑状态类和保存状态类，在编辑状态类中，直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件，然后进入保存状态类后，在保存状态类中直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件。由于两个状态是独立的，如此web app的保存状态和编辑状态之间对于键盘事件和鼠标事件的逻辑的就解耦了，也不存在大块化的条件判断语句，将大块化的条件判断语句分支化到各个状态类中。

附图说明

图1是本申请的一种执行完全状态模式的web app的方法实施例的步骤流程图；

图2是本申请的另一种执行完全状态模式的web app的方法实施例的步骤流程图；

图2A是本申请实施例的状态类以及实现状态类相关的基类、环境类之间的关系图；

图2B是本申请实施例图2实施例的各状态类的转换关系图；

图3是本申请的另一种执行完全状态模式的web app的方法实施例的步骤流程图；

图3A是本申请实施例图3实施例的各状态类的转换关系图；

图3B是本申请实施例图3实施例的弹出窗口示例；

图4是本申请的一种执行完全状态模式的web app的装置实施例的结构框图；

图5是本申请的另一种执行完全状态模式的web app的装置实施例的结构框图；

图6是本申请的另一种执行完全状态模式的web app的装置实施例的结构框图；

图7是本申请的一种完全状态模式web app的实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，基于状态模式，预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。，并且，可以不用大量的修改原代码，即可很容易的增加新的状态，可扩展性高。

其中，所述状态模式的介绍如下：在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，该属性叫做状态，该对象叫做有状态的(stateful)对象，该对象状态是从事先定义好的一系列值中取出的。当一个有状态对象，执行该状态类中的行为时，其与外部事件产生互动，继而根据该状态下的状态转换逻辑，该对象的内部状态会改变为其他状态，该对象会执行相应的其他状态类，从而使得对象的行为也随之发生变化。

参照图1，其示出了本申请的一种执行完全状态模式的web app的方法实施例的步骤流程图，具体可以包括如下步骤：

步骤110，预先根据决定web app行为变化的属性，将web app划分为 各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

所述状态，指web app对象实例的属性的属性值，所述行为，指web对象的功能，该行为可以理解为方法。比如方法function activateKeyboard()，为启用键盘事件的行为。

在本申请实施例中，对于一个web app，可以根据其逻辑将其分为多个状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。

需要说明的是，所述状态类比如初始状态类、加载状态类、编辑状态类、保存状态类。当然，实际应用中，状态类可以根据实际需求划分，可以包括任意类，本申请实施例不对其加以限制。

其中，每个状态转换逻辑根据相应状态下的一个具体行为触发状态类的跳转。

步骤120，当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

在实际应用中，web app启动后，可以创建一个web app对象，该web app对象可以理解为web app的实例。然后为该web app对象设置一个最开始的状态类，那么web app对象即可首先执行该初始被设置的状态类，然后执行该状态类的相关行为，在执行过程中，可根据该状态类的状态转换逻辑，将web app对象跳转为执行另一个状态类。那么跳转后，该web app对象执行该另一个状态类的相关行为，在执行过程中根据该状态类的状态转换逻辑再跳转为执行下一个状态类。其他情况以此类推。

在实际应用中，步骤110可离线进行预置，而步骤120在浏览器中执行。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之 间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，即条件判断语句的数量少，分散到具体的状态类中，耦合性低。

比如对web app的编辑和保存，分别设置编辑状态类和保存状态类，在编辑状态类中，直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件，然后进入保存状态类后，在保存状态类中直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件。由于两个状态是独立的，如此web app的保存状态和编辑状态之间对于键盘事件和鼠标事件的逻辑的就解耦了，也不存在大块化的条件判断语句，将大块化的条件判断语句分支化到各个状态类中。

在图1实施例的基础上，参照图2，本申请实施例将状态类划分为了至少下面几个状态类：初始状态类、加载状态类、编辑状态类、保存状态类，以执行本申请实施例的过程。

参照图2，示出了本申请的一种执行完全状态模式的web app的方法实施例的步骤流程图，具体可以包括如下步骤：

步骤210，预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

所述状态，指web app对象实例的属性的属性值，所述行为，指web对象的功能，该行为可以理解为方法。比如方法function activateKeyboard()，为启用键盘事件的行为。

在本申请实施例中，对于一个web app，可以根据其逻辑将其分为多个状态类，如初始状态类、加载状态类、编辑状态类、保存状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。

其中，每个状态转换逻辑根据相应状态下的一个具体行为触发状态类的 跳转。

比如上述初始化状态类的相关行为可包括：为web app的各种变量分配空间、为各种变量赋予初始值、初始化鼠标，键盘，网络，以及其他异步处理事件，初始化界面等，其第一状态转换逻辑可包括，在为所有变量赋予初始值之后，跳转至执行加载状态类。

上述加载状态类的相关行为可包括：载入各种信息，渲染web app的主界面、获取从上一状态传来的上下文数据、等，其第二状态转换逻辑可包括：在web app的主界面渲染完毕之后跳转至执行编辑状态类。

上述编辑状态类的相关行为可包括：启用键盘事件、启用鼠标事件、接收点击保存按钮的事件、获取从上一状态传来的上下文数据、web app关闭等各种业务逻辑等，其第三状态转换逻辑可包括：接收到对保存按钮的点击事件后，跳转至执行保存状态类。

上述保存状态类的相关行为可包括：保存当前web app中的内容至存储区域，取消保存操作(如，接收到esc事件)、获取从上一状态传来的上下文数据等，其第四状态转换逻辑可包括：在保存完毕之后或者接收到取消保存操作后，跳转至执行编辑状态类。

在实际应用中，本申请实施例可以如图2A设置：

环境类(Context):定义业务逻辑的接口，如图2A的Request()。维护一个状态类的实例，该环境类生成一个web app对象。

基类(State):定义一个接口如图2A的Handle()，以封装与Context的一个状态类相关的行为。

各种状态类(ConcreteState)，如图2A的ConcreteStateA、ConcreteStateB等，每个状态类继承上述基类，也即各个状态类为该基类的子类，每个状态类实现一个与Context的一个状态相关的行为。该状态类包括初始状态类、加载状态类、编辑状态类、保存状态类。

步骤220，根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

在本申请实施例中，浏览器获从服务器侧获取到网页文档后，如htlm(Hyper text Markup Language，超文本标记语言)文档后，执行所述文档，则生成的web app对象执行初始状态类，此时web app的属性为初始状态。

在该初始状态的web app对象中，执行初始状态类里封装的各种初始状态的相关行为，如前述为web app的各种变量分配空间、为各种变量赋予初始值等。并且在执行到某个具体行为后，跳转至执行加载状态类，如前述在为所有变量赋予初始值之后，跳转至执行加载状态类。

结合图2B，其介绍了本申请实施例的状态转换过程。

然后，web app对象的属性更改为加载状态。

步骤230，在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

在web app的属性变更为加载状态之后，则执行加载状态类里封装的加载状态的相关行为。如前述载入各种信息，渲染web app的主界面等。并且在执行到某个具体行为后，跳转至执行编辑状态类，如前述在web app的主界面渲染完毕之后跳转至执行编辑状态类。

然后，web app对象的属性更改为编辑状态。

步骤240，在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

在web app对象的属性变更为编辑状态之后，则执行加载状态类里封装的编辑状态的相关行为。如前述启用键盘事件、启用鼠标事件、接收点击保存按钮的事件、web app关闭等各种业务逻辑等。并且在执行到某个具体行为后，跳转至执行保存状态类，如接收到对保存按钮的点击事件后，跳转至执行保存状态类。

然后，web app对象的属性更改为保存状态。

可以理解，在本申请实施例中，编辑状态类里可以封装各种与外界交互的行为，该行为可以根据实际需要封装，本申请不对其加以限制。

步骤250，在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

在web app的属性变更为保存状态之后，则执行保存状态类里封装的保存状态的相关行为。如前述保存当前web app中的内容至存储区域，取消保存操作(如，接收到esc事件)等等。并且在执行到某个具体行为后，跳转至执行保存状态类，如接在保存完毕之后或者接收到取消保存操作后，跳转至执行编辑状态类。

在状态类模式中，当web app一个状态调整至另外一个状态之后，前一个状态的信息则会被清除，如此后一个状态则不会与前一个状态产生交叉，不存在耦合。

在实际应用中，步骤210可离线进行预置，而步骤220-250在浏览器中执行。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，即初始化状态类、加载状态类、编辑状态类、保存状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。

在图2所示实施例的基础上，本申请还提供了一个优选的实施例：

参照图3，示出了本申请的另一种执行完全状态模式的web app的方法实施例的步骤流程图，具体可以包括如下步骤：

步骤310，预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类，至少一个弹出窗口状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

在通常情况下，所有与外部交互的行为或者说业务逻辑，都被封装在编 辑状态类中，但实际上，这些行为之间从整体层面上很可能还是具备平行性，所谓平行性指的是各个状态的行为所处的层次是一样的，相互独立的、没有关联的，是可以根据不同的状态来决定到底走平行线的哪一条。那么本申请实施例，则可以根据行为之间的平行性，将与外部交互的行为拆分为多个状态类，比如，将在web app主页面本身中与外部交互的行为保留在编辑状态类中，将需要从web app主页面弹出的窗口中与外部交互的行为单独设置一个弹出窗口状态类，独立于该编辑状态类执行。

而由于可能从web app主页面中弹出的窗口有多个，本申请则可以对每个弹出窗口单独设置一个弹出窗口状态类。

相应的，在编辑状态类中，针对每个弹出窗口状态类，设置了相应的第五状态转换逻辑，其在主页面中接收到相应的操作之后，则将web app对象跳转至执行相应的弹出窗口状态类。

在本申请实施例的一种优选实施例中，本申请实施例还包括：

步骤302，在编辑状态类中加入sticky属性，所述sitcky属性用于web app对象的编辑状态类跳转为执行其他状态类时，保留编辑状态所对应的界面元素。

在实际应用中，因为一个状态转换到另外一个状态之后，前一个状态会清理，那么如果编辑状态转换到弹出窗口状态之后，编辑状态则会清理，则其主页面就不存在了，该种情况可能会误导用户该web app出现了问题，并且影响界面的可视度，不方便用户观看主页面上弹窗覆盖部分之外的信息。那么本申请则添加了sticky属性，该属性可以保证编辑状态跳转至其他状态类之后，主界面的UI界面还在显示。

需要说明的是，该stickey属性通过基类的接口实现，如果某个状态类为该sticky属性的值设置为1，则不对该状态类进行清理，保留编辑状态所对应的界面元素，如保留图3B中web app的弹出窗口“新建bucket”后的web app主页面。在本申请实施例中，对编辑状态类执行时将sticky属性设置为1，其他状态类可将其值设置为null。

当然，在本申请实施例中，也会定义前述环境类(Context)、基类(State)、以及各个状态类(ConcreteState)继承基类。

基类比如：

当然本申请实施例中，根据实际的业务逻辑，还可以设置其他状态类，比如预览状态栏等，本申请实施例不对其加以限制。

步骤320，根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

本申请实施例结合图3A进行描述。

本步骤与图2实施例的步骤220类似，在此不再赘叙。

步骤330，在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

本步骤与图2实施例的步骤330类似，在此不再赘叙。

步骤340，在编辑状态的web app对象中，执行编辑状态的相关行为，并根据各第五状态转换逻辑将web app对象跳转为执行相应的弹出窗口状态，根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

如前述例子有在编辑状态之后有两个弹出窗口状态，即windowPopup1State和windowPopup1State。

对于windowPopup1State，如图3B，假使其对应bucket管理栏，其第五状态转换逻辑可以为：当接收到用户对bucket管理栏的点击操作，则弹出新建bucket窗口，web app对象的属性变为弹出窗口状态windowPopup1State。假使其对应资源监控报表栏，其第五状态转换逻辑可以为：当接收到用户对资源监控报表栏的点击操作，则弹出资源监控报表窗口web app对象的属性变为弹出窗口状态windowPopup1State。

当然，在前述在编辑状态类中加入sticky属性的情况下，步骤340还包括：

在web app对象的状态跳转到其他状态之后，保留编辑状态类对应的界面元素。

该界面元素可以理解为web app的主页面。

在本申请实施例的一种优选实施例中，本申请实施例还包括：

步骤342在编辑状态类中，判断是否将web app对象由编辑状态类跳转至弹出窗口状态类；如果是跳转至弹出窗口状态，则保留编辑状态所对应的界面元素。

在本申请实施例中，还可以在编辑状态类中在跳转到其他状态时，还可以判断跳转的对象，如果跳转的对象不是弹出窗口状态，则对编辑状态进行清理。比如判断跳转的对象是保存状态，则将sticky设置为null，那么web app的状态变为保存状态后，则该编辑状态被清理。

如果跳转的对象是弹出窗口状态，则保留编辑状态所对应的界面元素。比如判断跳转的对象是保存状态，则将sticky设置为1，那么web app的状态变为保存状态后，则该编辑状态不会被完全清理，会保留web app的主页面。

步骤350在弹出窗口状态类中，执行弹出窗口状态类的相关行为，并根据第七状态转换逻辑将web app对象跳转为执行编辑状态类。

在web app对象的属性变更为弹出窗口状态之后，则执行弹出窗口状态类里封装的弹出窗口状态的相关行为，如前图3B的windowPopup1State extends State下，使用蒙板将底部进行遮盖、不允许用户进行操作的行为，允许用户进行输入、提交、取消等行为。

当然，在弹出窗口状态类中，还设置第七状态转换逻辑，用于将web app对象的状态从弹出窗口状态跳转为编辑状态，以执行编辑状态类的各种操作。如图3B中的弹出窗口状态windowPopup1State extends State，该第七逻辑可以为，当接收到对提交按钮的点击操作或者接收到对取消按钮的点击操作，则将web app对象跳转为执行编辑状态类。

步骤360，在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

本步骤与图2实施例的步骤250类似，在此不再赘叙。

在实际应用中，步骤310可离线进行预置，而不在320-360在浏览器中执行。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。比如对web app的编辑和保存，分别设置编辑状态类和保存状态类，在编辑状态类中，直接启用其需要的键盘事件和鼠 标事件、禁用其不需要的键盘事件和鼠标事件，然后进入保存状态类后，在保存状态类中直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件。由于两个状态是独立的，如此web app的保存状态和编辑状态之间对于键盘事件和鼠标事件的逻辑的就解耦了，也不存在大块化的条件判断语句，将大块化的条件判断语句分支化到各个状态类中。

尤其是，本申请实施例将弹出窗口状态从编辑状态中独立出来，进一步对web app进行了解耦，下面以一个为代码示例对该提取出的弹出窗口状态能够进一步解耦的原理进行论述：

1、将各个弹出窗口的行为都放在一个编辑状态类中的伪代码如下：

在通常情况下，将弹出窗口和其他业务逻辑一起放在编辑状态中，会使用蒙版将底部的内容区域遮盖，不允许用户操作(如图3B中2所述)，但实际上用户可以通过tab导航快捷键的方式进行操作，此时Web app无法区分出这种操作是否合法。并且如上述示例，有两个弹出窗口，而两个窗口都要要禁用某些键盘和鼠标事件，然后再启用某些键盘和鼠标事件，两者和外部代码之间就产生了耦合。特别是，窗口中需要处理的一般都是异步操作，那么代码中将会出现大量异步处理的代码，增大了代码耦合性，增加了开发难度。

而本申请实施例，对应上述伪代码，其将各个弹出窗口独立为弹出窗口状态类，其编辑状态类、弹出窗口状态类1和弹出窗口状态类2的伪代码如下：

在(1)的编辑状态类中，其处理弹出窗口windowPopup1的方法中，仅仅是将wep app对象的状态切换到(2)的弹出窗口状态1；其处理弹出窗口windowPopup2的方法中，仅仅是将wep app对象的状态切换到(3)的弹出 窗口状态2中。在编辑状态中，并不执行弹出窗口的具体行为。

由于各个状态之间，因此可以很容易的屏蔽用户对底部内容区域的操作。并且，弹出窗口状态类(2)和弹出窗口状态类(3)与编辑状态类(1)之间的逻辑就解耦了，对鼠标和键盘事件的代码也解耦了，大大降低了开发难度。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图4，示出了本申请的一种执行完全状态模式的web app的装置实施例的结构框图，具体可以包括如下模块：

预置模块410，用于预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

状态执行模块420，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，即条件判断语句的数量少，分散到具体的状态类中，耦合性低。

参照图5，示出了本申请的一种执行完全状态模式的web app的装置实 施例的结构框图，具体可以包括如下模块：

预置模块510，用于预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

状态执行模块520，具体包括：

初始化状态模块521，用于根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

加载状态模块522，用于在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

编辑状态模块523，用于在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

保存状态模块524，用于在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，即初始化状态类、加载状态类、编辑状态类、保存状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。

参照图6，示出了本申请的另一种执行完全状态模式的web app的装置 实施例的结构框图，具体可以包括如下模块：

预置模块610，用于预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类、至少一个弹出窗口状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

在本申请的另外一个优选实施例中，所述预置模块410还用于：在编辑状态类中加入sticky属性，所述sitcky属性用于web app对象的编辑状态类跳转为执行其他状态类时，保留编辑状态所对应的界面元素。

其中，每个所述状态转换逻辑根据相应状态下的一个或多个具体行为触发状态类的跳转。

状态执行模块620，具体包括：

初始化状态模块621，用于根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

加载状态模块622，用于在加载状态的web app对象中，执行加载状态的相关行为，并根据各第五状态转换逻辑将web app对象跳转为执行相应的弹出窗口状态，根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

编辑状态模块623，用于在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

在本申请的另外一个优选实施例中，所述编辑状态模块440还用于：

判断是否将web app对象由编辑状态类跳转至弹出窗口状态类；如果是跳转至弹出窗口状态，则保留编辑状态所对应的界面元素；

如果不是，则清理编辑状态类。

弹出窗口状态模块624，用于在弹出窗口状态类中，执行弹出窗口状态类的相关行为，并根据第七状态转换逻辑将web app对象跳转为执行编辑状 态类。

保存状态模块625，用于在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于web app，能以完全状态模式进行运行，其代码中条件判断块小，分散到具体的状态类中，耦合性低。

尤其是，本申请实施例将各弹出窗口状态从编辑状态中独立出来，进一步对web app进行了解耦，在弹出窗口状态下可以很容易的屏蔽用户对底部内容区域的操作，大大降低了开发难度。

参照图7，示出了本申请的一种完全状态模式web app的实施例的结构框图，具体可以包括如下模块：

状态执行模块710，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类；其中所述各个状态类根据web app的状态设置，所述web app的状态根据决定web app行为变化的属性进行划分；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。

当然，在本发明实施例中，可以预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，从而可以构建一个web app。然后即可得到状态执行模块710。

当然在状态执行模块710，还可包括web app对象创建模块，用于在启 动web app时，创建web app对象。

还可包括起始状态赋予模块，用于为创建的web app对象赋予一个最开始的状态类。

其中，每个所述状态转换逻辑根据相应状态下的一个或多个具体行为触发状态类的跳转。

在本申请另外一个优选的实施例中，所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类；

所述状态执行模块710包括：

初始化状态模块，用于根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

加载状态模块，用于在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

编辑状态模块，用于在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

保存状态模块，用于在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

在本申请另外一个优选的实施例中，所述状态类还包括：至少一个弹出窗口状态类；

所述编辑状态模块，还用于：

根据各第五状态转换逻辑将web app对象跳转为执行相应的弹出窗口状态。

在本申请另外一个优选的实施例中，还包括：

弹出窗口状态模块，用于在弹出窗口状态类中，执行弹出窗口状态类的相关行为，并根据第七状态转换逻辑将web app对象跳转为执行编辑状态类。

在本申请另外一个优选的实施例中，在所述编辑状态类中还包括sticky属性，所述sitcky属性用于web app对象的编辑状态类跳转为执行其他状态类时，保留编辑状态所对应的界面元素。

在本申请另外一个优选的实施例中，所述编辑状态模块还用于：

判断是否将web app对象由编辑状态类跳转至弹出窗口状态类；如果是跳转至弹出窗口状态，则保留编辑状态所对应的界面元素；

如果不是，则清理编辑状态类。

本申请实施例预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑，各个状态类之间是平行的，相互独立的，在web app执行时，web app对象的每个状态类独立执行，不和其他的状态存在交叉。因此，本申请实施例对于webapp，能以完全状态模式进行运行，其代码中条件判断块小，即条件判断语句的数量少，分散到具体的状态类中，耦合性低。

比如对web app的编辑和保存，分别设置编辑状态类和保存状态类，在编辑状态类中，直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件，然后进入保存状态类后，在保存状态类中直接启用其需要的键盘事件和鼠标事件、禁用其不需要的键盘事件和鼠标事件。由于两个状态是独立的，如此web app的保存状态和编辑状态之间对于键盘事件和鼠标事件的逻辑的就解耦了，也不存在大块化的条件判断语句，将大块化的条件判断语句分支化到各个状态类中。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介 质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个 流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的执行完全状态模式的web app的方法、执行完全状态模式的web app的装置、一种完全状态模式APP，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种执行完全状态模式的web app的方法，其特征在于，包括：

预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

2.根据权利要求1所述的方法，其特征在于，所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类；

所述当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类的步骤包括：

根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

3.根据权利要求2所述的方法，其特征在于，

所述状态类还包括：至少一个弹出窗口状态类；

在编辑状态的web app对象中，还包括：

根据各第五状态转换逻辑将web app对象跳转为执行相应的弹出窗口状态。

4.根据权利要求3所述的方法，其特征在于，还包括：

在弹出窗口状态类中，执行弹出窗口状态类的相关行为，并根据第七状态转换逻辑将web app对象跳转为执行编辑状态类。

5.根据权利要求3或4所述的方法，其特征在于，还包括：

在编辑状态类中加入sticky属性，所述sitcky属性用于web app对象的编辑状态类跳转为执行其他状态类时，保留编辑状态所对应的界面元素。

6.根据权利要求4所述的方法，其特征在于，在编辑状态中，还包括：

判断是否将web app对象由编辑状态类跳转至弹出窗口状态类；如果是跳转至弹出窗口状态，则保留编辑状态所对应的界面元素；

如果不是，则清理编辑状态类。

7.根据权利要求1所述的方法，其特征在于，每个所述状态转换逻辑根据相应状态下的一个或多个具体行为触发状态类的跳转。

8.一种执行完全状态模式的web app的装置，其特征在于，包括：

预置模块，用于预先根据决定web app行为变化的属性，将web app划分为各个状态，并为各个状态设置对应的状态类；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑；

状态执行模块，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类。

9.根据权利要求8所述的装置，其特征在于，所述状态类包括：初始状态类、加载状态类、编辑状态类、保存状态类；

所述状态执行模块包括：

初始化状态模块，用于根据所述初始状态类将所述web app对象设置为初始化状态，在初始化状态的web app对象中执行初始化状态的相关行为，并根据第一状态转换逻辑将web app对象跳转为执行加载状态类；

加载状态模块，用于在加载状态的web app对象中，执行加载状态的相关行为，并根据第二状态转换逻辑将web app对象跳转为执行编辑状态类；

编辑状态模块，用于在编辑状态的web app对象中，执行编辑状态的相关行为，并根据第三状态转换逻辑将web app对象跳转为执行保存状态类；

保存状态模块，用于在保存状态的web app对象中，执行保存状态的相关行为，并根据第四状态转换逻辑将web app对象跳转为执行编辑状态类。

10.根据权利要求8所述的装置，其特征在于，

所述状态类还包括：至少一个弹出窗口状态类；

所述编辑状态模块，还用于：

根据各第五状态转换逻辑将web app对象跳转为执行相应的弹出窗口状态。

11.根据权利要求10所述的装置，其特征在于，所述状态执行模块还包括：

弹出窗口状态模块，用于在弹出窗口状态类中，执行弹出窗口状态类的相关行为，并根据第七状态转换逻辑将web app对象跳转为执行编辑状态类。

12.根据权利要求10或11所述的装置，其特征在于，所述预置模块还用于：

在编辑状态类中加入sticky属性，所述sitcky属性用于web app对象的编辑状态类跳转为执行其他状态类时，保留编辑状态所对应的界面元素。

13.根据权利要求11所述的装置，其特征在于，所述编辑状态模块还用于：

判断是否将web app对象由编辑状态类跳转至弹出窗口状态类；如果是跳转至弹出窗口状态，则保留编辑状态所对应的界面元素；

如果不是，则清理编辑状态类。

14.根据权利要求8所述的装置，其特征在于，每个所述状态转换逻辑根据相应状态下的一个或多个具体行为触发状态类的跳转。

15.一种完全状态模式web app，其特征在于，包括：

状态执行模块，适于当web app对象执行某个状态类时，在该状态类的状态中，执行所述状态的相关行为，并根据该状态类的状态转换逻辑，将web app对象从当前执行的状态类，跳转为执行与所述状态转换逻辑对应的另一状态类；其中所述各个状态类根据web app的状态设置，所述web app的状态根据决定web app行为变化的属性进行划分；其中，每个状态类包括相应状态的相关行为，以及用于状态类跳转的状态转换逻辑。