Web Dynpro Introduction

 

Web Dynpro是SAP提供的一种编程模型。JAVA和ABAP都可以使用这种编程模型。适用于通过声明的方式生成标准的用户界面，能够极大地提高开发web application的效率。

从技术角度来讲，ABAP，JAVA WEB DYNPRO是sap开发基于web界面的一次革命。它完全不同于以前的开发模式，是ERP应用web界面开发的一次飞跃。

Web Dynpro基于MVC规范，使用了声明性的编程技术。也就是说你指定你在客户端要显示什么样的界面元素，然后这些界面元素怎样取得数据。你还要在你的应用中声明可能的浏览路径。所有创建界面元素所需要的代码会自动生成出来，这使你从重复的编码中解脱出来，通过javascript实现交互。

ABAP WEB DYNPRO在netweaver 7.0之后可以被使用。为了开发Web Dynpro的相关对象，object navigator（SE80）被增强了。

Web Dynpro支持Structured开发。软件通过Web Dynpro componentｍ模块化，它们可以被组合起来形成复杂的ｗｅｂ应用。

Ｗｅｂ　Ｄｙｎｐｒｏ是以声明的方式进行开发的，ＡＢＡＰ　ＢＥＮＣＨ提供了一些工具一以Ｗｅｂ　Ｄｙｎｐｒｏ　Ｍｅｔａｌ Model的方式来抽象的表示你的应用。所有需要的代码便会被自动创建并符合Web Dynpro框架的标准。

Web Dynpro框架允许你将自己的源代码放在自动生成的代码的指定位置。

所有的Web Dynpro应用都基于相同的units。然而通过加入自己的编码，你就可以扩展这个框架来满足任何的业务需求。

不是在设计的时候就要决定所有的实施细节。可以在运行的时候动态决定界面的显示。这样就使你的应用变得非常灵活而不需要写HTML或JAVASCRIPT代码。

Web Dynpro可以访问不同的数据源：

l         所有可复用的部件都可以被调用（如FM或methods）甚至通过OPEN SQL直接从数据库中取得数据。然而这样会导致flow logic和business logic混淆，所以应当避免。

l         通过创建web service client object可以访问web service

l         SAP JAVA Connector（JCo）可以调用EnterpriseJavaBeans，它在Java Engine上。

Model object在ABAP Web Dynpro中还不被支持。最好的方式是通过封装业务逻辑的可复用entity来创建包含源代码的classes。也可以开发无界面的web Dynpro components，其目的只是为了复用。这些components可以以component reuse的方式被访问。

Web Dynpro的主要目的是能够在structure design的方式下使开发人员以最小的代能够开发功功能强大的web应用。

Web Dynpro的哲理便是尽量少的手工敲入代码。Web Dynpro通过下面两种方式来实现这一目标：

l         Web Dynpro使用声明性的中性语言元模型来定义用户界面。通过这种抽象的定义，开发环境自动生成所需的源代码。也可以手工加入代码，不过使用来操作数据的，而不是定义用户界面。

l         Web Dynpro具有支持国际化，弹性的，逻辑层和用户界面分离的技术特点。这是因为使用了MVC设计模式

由于繁琐的UI编码被去除了，开放人员可以把精力集中到业务逻辑层面了

Web Dynpro可以运行在不同的设备和网络环境这就很好的支持了协同的scenario。

Web Dynpro Components可以构建复杂的web应用，构建可复用的互动的程序。它们可以在大型应用互相嵌套。

Web Dynpro Components是其他UI界面元素和程序的容器。

跟UI相关的有window和view。View的layout就是page上的一个方形区域在客户端显示。View包含View Elements比如input fields和button。在客户端显示的整个页面可以是一个view也可以是多个view。View的组合以及view之间的流程是通过window来定义的。一个window可以包含任意数量的views。一个view可以被任意数量的window所包含。

Web Dynpro的源代码位于Web Dynpro Controllers中。Controller的全局变量的层级存储称为context。

可以通过三种不同的方式来使用Web Dynpro Components：

l         通过Web Dynpro Application，web Dynpro Component可以与URL建立关系，然后就可以通过浏览器或其他Web Dynpro Client调用。

l         将Web　Ｄｙｎｐｒｏ　Ｃｏｍｐｏｎｅｎｔ作为一个Ｓｕｂ　Ｃｏｍｐｏｎｅｎｔ复用。ＷｅｂＤｙｎｐｒｏＣｏｍｐｏｎｅｎｔ的可视界面可以作为ｍａｉｎ　ｃｏｍｐｏｎｅｎｔ界面的一部分。

l         将Web　Ｄｙｎｐｒｏ　Ｃｏｍｐｏｎｅｎｔ作为一个Ｓｕｂ　Ｃｏｍｐｏｎｅｎｔ复用时，在ｐｒｏｇｒａｍｍｉｎｇ　ｉｎｔｅｒｆａｃｅ中定义的方法和变量能够被ｍａｉｎ　ｃｏｍｐｏｎｅｎｔ访问。

Ｗｅｂ　Ｄｙｎｐｒｏ　ＣｏｎｔｒｏｌｌｅｒＣｏｎｔｅｘｔ中定义的变量可以和其他的ｃｏｎｔｒｏｌｌｅｒ的变量建立关系，这称为ｃｏｎｔｅｘｔ　ｍａｐｐｉｎｇ。这样不同的ｃｏｎｔｒｏｌｌｅｒ就可以使用公用的属性了，所以在ｃｏｎｔｒｏｌｌｅｒ　ｃｏｎｔｅｘｔ之间ｃｏｐｙ这些属性就没有必要了。

可以输入数据的ＵＩ　ｅｌｅｍｅｎｔｓ必须与相应的ｃｏｎｔｒｏｌｌｅｒ　ｃｏｎｔｅｘｔ的属性建立关系，这成为ｄａｔａ　ｂｉｎｄｉｎｇ。通过ｄａｔａ　ｂｉｎｄｉｎｇ　ＵＩ　ｅｌｅｍｅｎｔｓ和ｃｏｎｔｅｘｔ　ａｔｔｒｉｂｕｔｅｓ之间的数据传输就可以自动实现了。

有了这两个概念ＵＩ　ｅｌｅｍｅｎｔｓ与不同的ｖｉｅｗ之间的关系只是通过声明的方式就可以建立了。

Context Mapping就可以使一个Controller中的context node为另一个Controller中的context node提供数据。这是controller之间共享数据的首要方式。

当一个component中的controller之间共享数据时称为internal mapping。

作为data source的context node称为mapping origin node，而另一端称为mapped node。

位于不同Web Dynpro controller之间的数据共享称为external mapping。

要想建立mapping的关系，必须遵循下面的步骤：

l         作为mapping origin，node必须存在于controller的context

l         Mapping origin controller不能是view controller

l         包含mapped node的controller必须声明所使用的mapping origin controller

Data binding就是view controller context与interface上的UI element之间数据的自动传输。

你不能将UI elements和其他controller的context node或attributes绑定到一起。UI elements是是view controller私有的。

Data binding将UI elements和controller中的应用程序代码分离开来。所以，要想操作UI

 Elements的属性，controller中的应用代码只能操作绑定到这个UI ELEMENTS上的context node或attributes。WebDynpro framework用来完成下面两个任务：

l         在显示时，context attributes向UI element上的数据传输

l         当屏幕上的数据被修改时，重新设置context attribute的值。屏幕上被输入的值会自动被转换和按照类型检查。如果发生错误，错误信息就会被显示。

Data binding的功能是强大的，不仅UI element的值可以被绑定，其他的UI properties也可以被绑定，比如element的可见性。这样通过操作context attributes就可以操作UI element的属性了。

View之间的切换是通过outbound plugs来实现的。引发一个outbound plug就会触发navigation event。Navigation event是特殊的异步events，被放到navigation queue中。一个view可以有多个outbound plugs。这可以用来定义下一个UI，包括多个views。Web Dynpro的处理过程当中navigation queue是在一定的时间节点处理的。在到达时间节点之前，navigation stack可以通过额外的outbound plugs扩展，或者完成的navigation stack可以被删除。Outbound plug应当按照促使离开当前view的action命名。

Inbound plug是特殊的event handler方法用来响应outbound plug触发的navigation events。Inbound plug的方法仅在navigation queue处理的时候才会被调用。这仅在当前view没有引发outbound plug而且没有发生错误时发生。Inbound plug应当按照显示这个view的原因命名。

Outbound和inbound plugs通过navigation link联系在一起。技术角度看，他们之间的联系就意味着将inbound plug的event handler注册到了outbound plug的navigation event上了。

Outbound plug和inbound plug的event handler都允许有参数实现view之间的数据传递。

Window定义了什么样的view将会被显示出来，以什么样的组合方式显示，以及通过outbound plugs来改变组合方式。所以在定义window时，你要从三个方面定义：

l         Component中要显示的所有view都要放到window中

l         如果多个view要同时显示，view的位置和显示方式是由一个特殊的view element：viewContainer来实现的。这个container放到window上，每个区域用ViewContainerUIelement定义，所有要显示的view放到这个区域里。

l         View之间的navigation link要被定义

在view area中一次只能显示一个view，view之间的navigation link必须被定义一切换其中的内容。View area可以被empty view清空，这个view的inbound plug必须响应相应的navigation event

Outbound plug来决定view area中要显示那个view。

一个window可以在view area中放多个view，view的显示方式可以多种多样。View的显示是由用户的navigation links来决定的。

所显示的views集合称为view assembly。

SAP Web Dynpro是基于MVC的设计理念。MVC首先应用于small talk-80语言。MVC是软件开发的一场革命，因为它首先使用了一下软件部件：

l         每个部件负责各自相应的功能

l         The message protocols to which each component should respond

SAP修改和扩展了MVC specification用来创建Web Dynpro toolset。

一个web Dynpro component的架构可以分为两部分：external and internal visibility。

Internal visible部分还可以被分为visual entities和programming entities。Visual entities是由web Dynpro framework生成的UI elements，被发送到客户端。Internal visible entities包括windows和views。

一个view包括view layout和相应的view controller。View controller包括navigation plugs，methods和context。

Window里可以放入一个或多个views，还有自己的window controller。一个window controller可以包括navigation plugs，methods和context。每一个view都可以嵌入到多个windows中。

一个window的outbound plug可以连接到任何嵌入view的inbound plug，而view的outbound plug可以连接到其所在window的inbound plug。但是在同一个component的windows之间进行浏览是不可能的。

Component controller是component层次的controller。跟某个view相关的逻辑应当写到相关的view controller中。Controller之间的usage declaration允许你访问declared controller的context data和methods。一个view controller不能被声明为其他controller的used controller，因为这会违背MVC的原则。

业务逻辑不应作为Web Dynpro Component的一部分，应当定义在component外部使其具有高复用性。推荐使用ABAP classes来封装这些逻辑。

Custom controller是由开发人员定义的可选controller，这些controller可以模块化component content。比如custom controller可以作为一些view local controllers，或者用于封装一定model class的逻辑。这样可以减少component controller的内容。

如果一个web Dynpro component需要访问另一个web Dynpro component，调用方称为parent component，被调用方成为child component。一个具体的component usage instance就会被创建，parent component通过child component的component interface controller来使用它的功能。

Web Dynpro controller的用户唯一可见的部分便是interface controller和interface views。

l         所有的Web Dynpro Components都只有一个interface controller。通过interface controller，数据，方法，event handler就可以被其他component访问。

l         Interface view是Web Dynpro Component的visual interface。Interface view和window之间是一对一的关系。一旦定义了一个window，相应的interface view就会自动生成，这样就可以被外部的component访问。只有选中interface属性的component才能访问interface view的inbound和outbound plugs。Window的method和context data不能被相关的interface view访问。

l         如果component没有view，也就没有window。这样的component就没有interface view。这样的components没有visual interface被称为faceless components。

Web Dynpro Application是访问web Dynpro Component的入口，也是唯一的可以被URL访问的entity。

通常interface view和application是一对一的关系。

为了定义一个web dynpro application，需要一下几步：

l         要触发的component，称为root component

l         要使用root component的那个interface view

l         指定的interface view的那个inbound plug作为入口。