1.3 Web Dynpro组件
一个Web Dynpro组件（Component）是一个可重复使用的实体。它可以把所有Web Dynpro组件结合在一起，但需要可执行组件（如Web Dynpro Application）作为程序的一部分，这样程序才能运行。
用Web Dynpro组件开发有以下优点。
1）结构化编程。
2）易于创建管理应用程序模块。
3）组件是可复用的。
4）易于软件整合。
在Web Dynpro组件中包含任意数量的窗体（Window）和视图（View）以及相应的控制器（Controller）。其他Web Dynpro组件也可以被引用，如图1-2所示。
图1-2
窗体和视图主要和用户界面（User Interface，UI）元素有关。窗体只是一种容器，在一个组件内可以包含任意多个窗体，一个窗体可以嵌入任意多个视图，一个视图可以包含任意多个UI元素（UI Element），而组件控制器（Component Controller）只有一个。如果一个组件不需要视图，那么窗体也就无须存在了。
一个Web Dynpro组件的生命周期从第一次被调用开始，终止于调用和实例化它的Web Dynpro应用程序终止。对于嵌入的组件的生命周期而言，直到需要的时候它才会被实例化，它的生命周期在调用它的应用程序结束的同时结束。
1.3.1 Web Dynpro组件特性
一个Web Dynpro组件始终是强制性地创建了窗体、视图和其控制器，这是关系到自身存在的组成部分。Web Dynpro组件之间的通信是借助组件接口（Component Interface）实现的，因此它不考虑自身的部分组成。一个Web Dynpro组件可嵌入其他Web Dynpro组件中。
总之，Web Dynpro组件的特性包括以下几个方面。
1）可以包含任意数量的窗体、视图以及与之对应的控制器。
2）可以嵌套其他的组件。
3）每个Web Dynpro应用程序必须有组件控制器。
4）每个组件包含一个接口，每个接口包含两个部分。
① 接口视图：用来连接Web Dynpro Application和Web Dynpro窗体。
② 接口控制器：进行数据交换控制。
1.3.2 视图
视图（View）描述了一个矩形区域的布局（Layout）和用户接口的行为动作（Action）。
1．布局
每个Web Dynpro应用程序都至少有一个视图。每个视图的布局都由不同的用户界面UI元素组成，这些UI元素可以相互嵌套，如图1-3所示。每一个UI元素的位置是由布局变式决定的。
2．Context和视图控制器（View Controller）
除了布局这一有形的部分以外，视图也包含一个视图控制器和一个Context。视图中的UI元素可以绑定Context中的数据，这些数据被Context存储和管理，使它们能够在屏幕上表示或使用。视图控制器包含很多方法，这些方法用来查询数据或处理用户输入，如图1-4所示。
图1-3
图1-4
3．入/出站插头（Inbound/Outbound Plug）
视图还包含入站插头（Inbound Plug）和出站插头（Outbound Plug），使视图可以彼此相连或者一个视图可以和一个接口视图联系在一起。这些插头可使用导航链接（Navigation Link）互相连接在一起。
4．空视图
空视图是一种特殊类型的视图。在没有手动嵌入视图的情况下，它总是在一个窗体中或视图集（View Sets）区域中自动生成。也可以手动将其嵌入在一个非空的窗体中，就像一个普通视图一样。空视图在运行时占用一个窗体的大小，可以使用特定的空视图隐藏其他的视图。
注：视图集（View Sets）是Web Dynpro for Java中的概念，这里不进行详细介绍。
当创建一个空视图时，一个命名为ShowEmptyView的入站插头会被默认自动创建。
5．视图设置
不同视图之间的导航是通过插头实现的。如前所述，这些插头分为入站插头和出站插头。入站插头定义了视图被调用的入口，出站插头用于调用接下来要显示的视图。插头是视图控制器的一部分，存在于所在的视图中。
由于接口视图导航方面的性能完全与视图相同，插头和导航链接也适用于接口视图。
若干视图通常嵌入在一个Web Dynpro窗体中。因此，有必要限定一个作为首先显示的视图（初始视图）。这种视图被分配默认属性（Set as default），随后的导航结构是依附于这一视图创建的。
视图的入口，也就是入站插头，总是调用一个事件处理方法。这就是为什么会为每个入站插头自动生成一个事件处理方法（它的使用是可选的）。在这种情况下，入站插头本身代表了事件处理。如果视图是窗体标记为默认的视图，则不使用入站插头。要从一个视图转到另一个视图，第一个视图的出站插头必须通过一个导航链接连接到第二个视图的入站插头，如图1-5所示。
图1-5
一个出站插头通过导航链接可以连接到很多视图。相反，一个入站插头可以被几个出站插头控制。入站插头和出站插头的关联信息不包含在每个视图中，此信息是储存在导航连接中。
综上所述，得出以下结论。
1）每个Web Dynpro应用程序至少有一个视图。
2）每个视图里面可以放置不同的UI元素。
3）视图包含两个很重要的组件：视图控制器和Context。
① Context用来存储、管理数据以及进行UI元素的绑定。
② 视图控制器用来查询数据以及处理用户输入等。
4）每个视图都有入站插头和出站插头。入站插头用来调用这个视图，而出站插头用来调用下一个视图。
5）连接关系：几个视图之间的连接通过导航链接来实现。
注：每个窗体可能有多个视图，所以必须指定初始视图，而且这个视图没有入站插头。
1.3.3 窗体
窗体（Window）用来结合若干个视图和视图集。一个视图只有被嵌入在窗体中才能由浏览器显示。一个窗体包含由导航链接关联的一个或多个视图，其中一个视图或视图集会被指定为默认用于首次显示在窗体中，如图1-6所示。
图1-6
窗体定义了在哪个组合中显示哪些视图以及执行出站插头时会如何改变视图组合，所以，创建一个窗体时，需要定义3个元素。
1）组件的可视界面中的所有视图必须嵌入到窗体中。
2）如果需要并排显示多个视图，则需要使用布局中包含视图容器UI元素（View Container UI element）的特殊UI元素来定义这些视图的布局和位置。此视图容器嵌入在窗体中，并且，在视图容器UI元素中定义的每个区域内，所有可能的视图均被嵌入到窗体中。每个视图容器UI元素在启动时只有一个缺省视图。
3）不同视图之间的导航链接必须进行定义。
视图显示区域一次只能显示一个视图，必须定义视图之间的导航链接，才能替换视图显示区域的内容。通过创建空视图可以清空视图显示区域，相应的导航事件会调用空视图的入站插头。
注：视图容器UI元素可参见附录C。
1．插头（Plug）和窗体控制器（Window Controller）
和视图一样，窗体也有入站插头和出站插头。每个Web Dynpro窗体都有一个窗体控制器。这个窗体控制器是一个全局控制器。组件在所有其他控制器中是可见的，这一点区别于视图控制器。
注：入站插头、出站插头和窗体控制器在SAP NetWeaver平台7.0的Web Dynpro for Java中并未涉及。
2．接口视图（Interface View）
每个窗体可以指定一个接口视图。此接口视图用于显示整个窗体。在组件中接口视图和Web Dynpro应用相关联，这使得窗体和URL有一种对应关系，如图1-7所示。
图1-7
此外，该接口视图使窗体能够参与多个组件重用（详见1.4节）。这意味着除了所有组件的具体视图，在一个窗体中可嵌入其他组件的接口视图（前提：组件重用被创建）。就像视图一样，该接口视图和窗体的入站插头、出站插头集成在了一起，可以在其他组件的视图中被调用，如图1-8所示（前提：这些组件窗体的插头被明确标记为接口插头（Interface Plug））。
图1-8
每个窗体在同一时间只能显示一个视图，这也适用于接口视图。但是，在同一组件中可以同时声明几个接口视图的组件重用。这样程序员可以显示一个接口视图多次。
3．窗体插头Window Plug（入站插头和出站插头）
每个窗体都有一个或多个入站插头或者出站插头。使用这些插头，一个窗体可以被列入一个导航链接Navigation Link，如图1-9所示。和视图的插头一样，每个窗体插头在整个窗体中都是可见的，可在此窗体内进行导航。此外，插头也可用于连接接口视图，所以它们的可见性已超越了组件的限制。因此，它们属于与接口视图有关的窗体，如图1-10所示。
一个组件的窗体被嵌入在另一个组件的窗体以便显示。一个Web Dynpro应用被定义，以便用来调用相应窗体（前提：出站插头的属性设定为Exit）。要使用接口插头（Interface Plug）调用或者关闭一个Web Dynpro应用，入站插头属性应设为Startup，出站插头属性应设为Exit。
图1-9
图1-10
4．出站插头（Outbound Plug）
窗体的出站插头导航到相应视图的入站插头，如图1-11所示。使用这些出站插头，就可以在窗体内导航到不同的视图，而不是使用预定义的视图。其中设置具体哪个出站插头被调用，可以在接口入站插头Interface Inbound Plug（具体参见3.8.1.节）中的事件处理程序中编辑。
图1-11
5．入站插头（Inbound Plug）
窗体的入站插头是从视图的出站插头导航到其嵌入的窗体，如图1-12所示。就像视图的入站插头一样，代表相应的事件，从而调用分配给它们的事件处理方法（Event Handler Method）。这样在窗口控制器中就可以控制哪一个出站插头是下一个被调用的，并且程序员可以动态地定义视图在窗体中显示的次序。
图1-12
上述功能在接口出站插头（Interface Outbound Plug）中也是适用的。
综上所述，得出以下结论。
1）窗体是多个视图的组合容器，视图必须在窗体中才能被用户看到。
2）一个窗体包含至少一个视图，如果是多个视图的话需要通过导航链接来实现。当然，必须定义初始的视图。
3）每个窗体可以有一个或者多个入站插头以及出站插头对应视图的插头。
① 出站插头：连接窗体和视图的入站插头。
② 入站插头：连接视图的出站插头嵌入到窗体。
1.3.4 Web Dynpro控制器
1．控制器分类
控制器是Web Dynpro应用程序中很重要的部分。它们决定用户如何与Web Dynpro应用程序进行交互。控制器可以访问到的数据是定义在相应的Context内的。在同一个Web Dynpro的应用程序中有不同的控制器和Context的实例。除了控制单独视图的视图控制器外，还有为组件中所有视图提供服务的全局控制器。
（1）视图控制器（View Controller）
每个视图都有一个视图控制器，它是用来处理用户与系统间交互的。每个视图也有一个视图Context（View Context），其中包含了视图所需的数据，如图1-13所示。
视图控制器和相应的Context至少在视图被浏览时是可见的。在浏览器中如果视图被一个连续的视图所取代，本地数据也不再可用。不过，视图的生命周期也可以连接到组件的生命周期。
图1-13
无论是可见的还是被隐藏的视图，只要在其生命周期内，其自身及其数据都是客观存在的。
（2）全局控制器（Global Controller）
每个Web Dynpro组件至少包含一个全局控制器，在其他的组件中都是可见的。组件控制器的数据一旦被访问，其使用寿命就延长到整个组件的生命周期，直至组件不被使用。
程序员可以添加自定义的控制器（Custom Controller）。控制器组件和它包含的数据在组件的所有视图中都是可见的。另外Web Dynpro窗体中所附带的窗体控制器（Window Controller）也是全局控制器，同样在组件的所有视图中都是可见的，它们的关系如图1-14所示。
图1-14
（3）接口控制器（Interface Controller）
每个Web Dynpro组件都包含一个接口控制器。该控制器也是一个全局控制器，在其他组件内也是可以看到的。因此，这部分是Web Dynpro组件的一个接口。
控制器之间的通信是通过调用方法或触发事件来实现的。程序员在创建一个控制器时便定义了这些控制器实例。
2．源代码
每个控制器包含程序区域，程序员可以在其中插入自己的源代码（Source）。因此，应用程序编程接口（API）一般用于节点Context和它们的属性以及数据的处理。例如：使用API执行节点初始化、访问系统环境服务器抽象层以及进行动态消息处理。
控制器可以存储它们自己的源代码。
（1）事件处理程序（Event Handler）
当视图在初始化、被关闭，或遇到回车键时，事件处理程序（钩子函数Hook）将被执行。
当其他控制器触发注册的事件，事件处理程序（与事件关联）将被执行。
（2）方法（Method）
方法可以被其他控制器调用。
（3）供应函数（Supply Function）
当Context及其元素被调用时，执行供应函数用于初始化Context中的元素。视图或组件的数据存储在Context中，在控制器中用供应函数读写访问此数据只是一个起点。
3．Context结构
Context的数据在一个层次结构里被管理起来。每个Context有一个根节点，根节点下面是其数据字段（属性），整个Context存储在一个树状结构里，如图1-15所示。一般在编程时要根据应用数据的结构创建此树状结构。
图1-15
每个Context节点包含的数据字段可以分为以下两类。
1）对象类型的单个实例。
2）对象类型的实例表。
在一个Context中可以重复嵌套使用节点，这种节点叫作递归节点（Recursive Node），如图1-16所示。用作递归的节点总是新节点的上级节点，最新创建的递归节点是上级节点的引用，因此无法单独处理。
注：根节点Context不能被用于递归。
图1-16
4．Context属性
（1）基数
表1-1汇总了一个节点可能的基数。
表1-1
（2）头选择（Lead Selection）
头选择在嵌套的Context结构中是非常重要的，其定义了Context元素。
应用程序UI的例子中包含一个TextView元素，在运行时相应显示客户的名称。如果没有一个明确的选择路径，名称属性对所有值将是平等的，可能不会将客户名称正确地显示在TextView的元素上。出于这个原因，为客户设置的信息内容必须明确指定一个节点，这是通过初始化头选择实现的。初始化头选择始终指定了节点的第一个要素，如图1-17所示。
图1-17
（3）自动初始化头选择
选择使用预置的自动初始化头选择，在这种情况下，一个节点的第一个要素分配到头选择属性。
（4）手动初始化头选择
如果自动初始化头选择没有被预制，头选择可以被编程实现。在这种情况下，这个属性可以分配到任何一个节点的元素（例如，使用节点的索引）。
5．Singleton属性
这个属性决定了子节点在实例化时是Singleton还是Non-Singleton，它的值是布尔值。例如在加载一个包含多行的表时，每一行包含的详细数据不会被首先加载，而只有在用户选中并查询特定行时，与该行相关的数据才会被读取。
如果例子中客户节点设置为Singleton，头选择被设置为自动初始化，Context的运行如图1-18所示。
6．Context数据绑定和映射
在Web Dynpro架构中，不同控制器的Context有不同的应用。
（1）Context绑定
用户接口视图的UI元素可与Context元素绑定，如图1-19所示。
图1-18
图1-19
（2）Context映射
Context映射可以定义在两个全局控制器之间或从一个视图中的Context映射到一个全局控制器的Context。全局控制器的Context也可以绑定到Web Dynpro模型，如图1-20所示。
（3）定义两个Context之间的映射
视图Context的元素可以定义在本地的视图中。在这种情况下，所有包含的属性只在有关的视图中可见，当视图消失时，属性值也将被删除。
视图Context的元素也可以映射到全局控制器（如组件控制器）的Context上，如图1-21所示。图1-21中节点1与节点2分别映射到组件控制器对应的节点上，组件控制器在全局范围内都是可见的，所有控制器都涉及读取和写入访问所包含的属性。组件控制器Context的属性值都包含在这里，只要用户不退出该组件，这些值仍然可用，即使它不再显示在屏幕上。图1-22所示，节点1、节点2的属性值会更新组件控制器节点的值，反之，组件控制器节点的值也会更新节点1、节点2的值。
图1-20
图1-21
图1-22
要建立映射关系，应注意以下几点。
1）充当映射源的控制器，其Context中必须有节点。该节点不需要任何已声明的子节点或属性。
2）映射源控制器不能是视图控制器。
3）包括映射目标节点的控制器，必须声明把映射源控制器当作已用控制器。
7．事件（Event）
在组件控制器中可以创建事件。
事件用于控制器之间的通信。一个控制器通过触发不同的事件来调用另外一个控制器中的事件处理程序，如图1-23所示。
图1-23
使用接口控制器的事件可以实现跨组件通信。然而，控制器组件的事件只在本组件内是可见的。
（1）入站插头事件
在视图中入站插头也像一个事件一样会做出相应的反应。因此，当一个视图被一个入站插头调用时，该入站插头事件所对应的处理程序是第一个被调用的，如图1-24所示。在这种情况下，该事件处理程序会放置在当前视图或窗体控制器中。
图1-24
控制器的接口视图甚至通过相应的入站插头的事件处理程序来作为调用某一个视图的出发点。在事件处理程序中，可以为每一个接口视图的入站插头编辑各自的事件处理程序。
（2）用户界面元素事件
一些用户界面元素，例如按钮，有用户与程序交互的动作相联系的特殊事件。这些事件是预先定义的，并在设计时指定了相应的用户动作。
8．动作（Action）
一些用户界面元素，如按钮，可以与用户的动作进行交互：单击相应的按钮可以触发对应的事件，视图控制器中的处理程序会被调用，如图1-25所示。这样的用户界面元素会配备一个或多个事件，在设计时可以连接到一个特定的动作（例如：切换到下一个视图）。如果这种动作被创建，相应动作的事件处理程序也会被自动创建。有必要的话，用这种方法可以为用户界面元素的事件指定不同的动作。这些事件的事件处理程序会在相应的动作被触发时调用。
图1-25
在视图中动作是可重复使用的。也就是说一个动作能被连接到多个甚至不同的用户界面元素的事件。
注：不像跨组件事件那样，用户界面元素事件的可见范围是在视图控制器内的，在其他组件是看不到的。用户界面元素事件本身是预定义的，不能改变。