Web Dynpro Controller

在ABAP Web Dynpro Component中有四种controller。他们的主要区别是他们的内容不同：

l         Component Controller：每个web Dynpro component都只有一个component controller。这是一个global controller，其他的controller都可见。Component controller用于整个component的功能。它没有visual interface。

l         Custom controller：它是可选的。它必须在design时定义，用于封装component controller的一些子功能。一个component可以定义多个custom controller。Web Dynpro Framework可以自动实例化custom controller，不过实例化的顺序不确定。所以custom controller中的代码不能依赖于其他custom controller代码的存在。

l         Configuration Controller：如果相应的component实施了特殊的configuration或personalization functionality，才会需要configuration controller。任何component只能有一个configuration controller。任何其他的controller都能访问configuration controller，不过configuration controller不能访问其他的controller。

l         View controller：每个view都包括layout部分和一个view controller。这个controller只涉及跟view相关的逻辑，比如检查用户的输入或者处理用户行为等。

l         Window Controller：每个window都只能有一个window controller。这个controller主要用来在处理inbound plug复用作为child controller的传输的数据。这个controller的methods可以被window的inbound plug methods调用。

运行时，所有的controller instances都是他们parent component的singletons。这对于view controllers也是适用的，所以将一个view潜入到view assembly中多次是不被允许的。

Controller的global data是以层级的形式存储的，称为controller context。这个context和在这个controller定义的methods如果没有声明使用这个controller的时候是private的。不过view controller不能被声明为used controller，所以view controller的context和methods总是private的。

Web Dynpro使用的是状态相关的技术，也就是说controller instance的lifetime不受处理程序代码和处理UI时间的限制。根据controller type的不同，controller的lifetime的处理机制也不同：

l         Component controller：component controller的lifetime与component的lifetime相同。当启动一个Web Dynpro Application时，component controller被Web Dynpro runtime实例化。

l         Custom controllers：custom controller是其方法第一次被调用时实例化。Custom controller的实例不能被直接删除。

l         Configuration controllers：作为component的第一个controller实例化。其lifetime与component一致。

l         View controller：view controller在其method第一次被调用时实例化。View controller可以通过其属性控制：如果选择了framework controlled，view instance随component一起被删除。如果选择了when visible，如果view不在属于view assembly就会被删除。

l         Window controllers：window controller也是在controller的method第一次调用时实例化。这可以通过启用一个web Dynpro Application或者在父component window中嵌入相关的interface view来实现。Window controller instance不能被直接删除。

每个controller都有它自己的context。Context root node已经存在，其他的nodes和attributes必须静态或通过源代码定义。

对于所有的controller来说，存在着Web Dynpro Framework按预先定义的顺序调用的methods，它们被称为hook methods。根据controller type的不同，有不同的hook methods。不过所有的类型的controller都至少有两个hook methods。这两个methods在controller instance的lifetime中仅执行一次：当controller instance创建时执行wddoinin()，当controller instance删除时执行wddoexit()。

额外的methods可以在method tab中定义。

与UI elements的值和属性不相关的attributes可以在attributes tab中声明。这些attributes在controller的所有methods中都是visible的。有两个预定义的attributes，一个是用来访问controller的功能：WD_THIS，一个是context:：WD_CONTEXT。

要想在不同的controller之间共享信息，必须在一个controller中声明对另一个controller的引用。这种需求的最常见情况是你想创建一个mapped context node或者使用另一个controller自定义的method。

你不能将view controller作为引用的controller，因为这会违背MVC的设计思想。View controller只用来显示数据和响应用户的action。View controller不负责生成要显示的数据，这是custom controller的任务。

业务逻辑，比如function modules，BAPI，helper class中的methods在所有controller中都可以call。

对于component和custom controllers，可以通过arbitrary parameters定义events。任何其他controller的任何method，如果被定义成event handler，都可以register到这些events。这样的events的一个典型应用便是当component controller中的代码执行完之后自动执行view controller中的代码。可以通过view controller订阅component controller触发的事件来实现。

通过design time declarations，web dynpro framework可以自动管理定义，触发和订阅这样的事件。你还可以在runtime实现dynamic event subscription。如果两个以上的methods定义了同一个事件，这些methods的执行顺序是不确定的。

Component controller也只有component controller有额外的standard hook methods。它们是在navigation requests处理前执行的wddobeforenavigation()和view assembly中所有views处理之后执行的wddopostprocessing()。

Attributes，methods，context elements，和events都可以被标记为interface elements。这些elements可以通过interface controller被其他components使用。

View controller是在建立Web Dynpro Component的可视化部分用来处理数据显示和响应用户action的每个方面。

不同view controller之间的navigation的发生，就会创建特殊的navigation events和navigation handlers。它们被称为navigation plugs。当outbound plug被fire时就会触发navigation event。

一个outbound plug的通用名称是<outbound plug>，它的declaration就会在view component controller中生成一个method，名称是FIRE_<Outbound plug>_PLG。这个method只有web Dynpro framework能看到，而developer不能看到。

一个inbound plug是event handler，用于注册到一个navigation request。一个inbound plug使用通用名称<inbound plug>，它的declaration在view’s component controller中也生成一个method，称为Handle<inbound plug>。

一个inbound plug（method HANDLE<inbound plug>）的静态注册到outbound plug(method:fire_<outbound plug>_PLG)触发的navigation event称为navigation link。Navigation link不是view的一部分，不过在潜入view的window中定义。在不同的window中，event registration的定义可以不同。

Action link是一个client-side event（比如在浏览器上按一个按钮），在相应的view controller中定义event handler method。当定义一个名字为<action>的action时，一个event handler method就会自动生成（ONACTION<Action>）。如果一个client event的结果就是要替换当前view在这个action的event handler method中相关的outbound plug就会被fire。

View controller中有两个特殊的hook methods：

l         Wddobeforeaction()在任何view中一旦client event被fire就会被处理。在event handler methods处理之前所有view的wddobeforeaction都会被执行

l         Wddomodifyview(()允许你动态处理view的layout。

除了所有controller的标准attributes，view controller还有一个reference用于指向component的component controller：WD_COMP_CONTROLLER。这个reference用来使用于component controller相关的功能。它用来访问在component controller中声明的methods或messages。

Window controller跟view controller很相似，技术上来看，它就像没有UI的view controller。所有在web application中要显示的view都必须嵌入到window中然后通过application或calling component调用。

Web Dynpro包含了所有的要显示的views以及定义了可能的view assemblies的navigation links。

每一个Web Dynpro Window都包含outbound plugs和inbound plugs，跟view一样。可以使用这些plugs来实现cross-component navigation。要想让component interface能够访问到plugs，要为每个plug选上Interface属性。这些plugs就会成为interface view的一部分。

Window controller也有特殊的attribute：WD_COMP_CONTROLLER，用于access component controller。