- 浏览: 176593 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
cjy11520:
...
Myeclipse6.0注册码 -
xwei78:
正好是所需,简单明了。
弹窗确定关闭 同时关闭父窗口 -
administrator1616:
搞个注册工具类不就行了
Myeclipse6.0注册码 -
loky:
mousegod2008 写道找了一上午,连破解的那个keyg ...
Myeclipse6.0注册码 -
mousegod2008:
找了一上午,连破解的那个keygen类都研究了,依然不能注册, ...
Myeclipse6.0注册码
Introduction:-
Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application. Controllers contain the source code of a Web Dynpro application; they hold the context data and care for event handling and navigation. Any programming of flow logic requires the knowledge of how controllers are defined and what kind of entities they offer.
Controller Types
There are four types of controllers in an ABAP Web Dynpro component. These different controller types differ in the entities they are composed of:-
1. Component controller:-
There is only one component controller per Web Dynpro component. This is a global controller, visible to all other controllers. The component controller drives the functionality of the entire component. This controller has no visual interface. The lifetime of the component controller equals the lifetime of the component. When starting a Web Dynpro application, the component controller is instantiated by the Web Dynpro runtime
2. Custom controllers
Custom controllers are optional. They have to be defined at design time and can be used to encapsulate sub-functions of the component controller. Multiple custom controllers can be defined in a component. Custom controllers are instantiated automatically by the Web Dynpro framework and the instantiation order is undefined; therefore, the coding in a custom controller should make no assumptions about the existence of any other custom controller. The instantiation of a custom controller is delayed until the first method of the controller is called. Custom controller instances cannot be deleted explicitly.
3. Configuration controller
This is a special custom controller. It is only necessary if the corresponding component implements special configuration and personalization functionality. Only one configuration controller may exist in any component. Any other controller can access the configuration controller, but the configuration controller cannot access any other controller. This controller is instantiated as the first controller of the component. It lives as long as the component lives.
4. View controllers
Each view consists of the layout part and exactly one view controller. This controller cares for view-specific flow logic, like checking user input and handling user actions. The instantiation of a view controller is delayed until the first method of the controller is called. The lifetime of a view controller can be controlled by the views properties. If framework controlled is selected, the view instance will be deleted with the component. If when visible is selected, the view instance is deleted as soon as the view no longer belongs to the view assembly.
5. Window controllers
Each window has exactly one window controller. This controller can be used to care for the data passed via the inbound plugs when being reused as a child controller. Methods of this controller can be called from the inbound plug methods of the window. The instantiation of a window controller is delayed until the first method of this controller is called. This is done by starting a Web Dynpro application or by embedding the related interface view in the parent component's window. Window controller instances cannot be deleted explicitly.
At runtime, all controller instances are singletons in respect to their parent component.
This is also true for view controllers; thus, embedding a view in a view assembly more than one time is not allowed. The global data of a controller is stored in hierarchical data storage, the controller context. This context and the methods defined in a controller are private unless another controller explicitly declares the usage of this controller. However, a view controller cannot be declared as a used controller, so the context data and the methods of a view controller are always private.
Common Controller Entities:-
Each controller has its own context. The context root node already exists. All other nodes and attributes have to be defined statically or by source code. For all controllers, there exist methods that are called by the Web Dynpro framework in a predefined order. These are called hook methods. Depending on the controller type, there are different hook methods available. At least two hook methods are contained in all controller types. These methods are processed only once during the lifetime of a controller instance: when a controller instance is created (wddoinit( )) and when a controller instance is deleted (wddoexit( )). Attributes not related to the value or property of UI elements can be declared using the Attributes tab. These attributes are then visible in all methods of this controller. There are two predefined attributes, which are used to access the functionality of the controller (WD_THIS) and of the context (WD_CONTEXT). For information to be shared between different controllers, one controller must declare the use of another controller. This is done on the Properties tab of the controller that needs to access another controller. The most frequent requirement for this kind of data sharing is when we wish to create a mapped context node or we wish to access another controller's instance methods. We may not specify the name of a view controller as a used controller, as this would violate good MVC design principles. A view controller should be written such that it is responsible for nothing more than the display of data and user interaction. A view controller is not responsible for generating the data it displays; that is the role of a custom controller. Business logic, such as function modules, BAPIs, or methods in helper classes can be accessed from the methods of all controllers.
Special Entities of Component/Custom Controllers:-
For both component and custom controllers, events can be defined with arbitrary parameters. Any method of any other controller (also view and window controllers) can register to these events if this method is defined as an event handler method. A typical use of such events is the invocation of processing in a view controller after processing in the component controller has been completed. This can be achieved when a method in the view controller subscribes to an event raised by the component controller. Using our design time declarations, the Web Dynpro framework will automatically manage the definition, triggering, and handler subscription to such events for us. If two or more methods subscribe to the same event, the order in which they will be executed is undefined. Only the component controller has additional standard hook methods. These are processed directly before the navigation requests are processed (wddobeforenavigation( )) and after all views of the view assembly to be sent have been processed (wddopostprocessing( )).Attributes, methods, context elements, and events can be marked as interface elements. These elements are then exposed to other components by means of the interface controller.
Special Entities of View Controllers:-
A view controller is a visual building block of a Web Dynpro component and is designed to handle all aspects of data display and user interaction. For navigation to take place between different Web Dynpro view controllers, special navigation events and navigation event handlers have been created. These are called navigation plugs. A navigation event is raised when an outbound plug is fired. Using the generic name <Outbound plug> for an outbound plug, its declaration will cause a method to be generated in the view's component controller, called FIRE<Outbound plug>PLG. This method is only visible for the Web Dynpro framework; it is not visible to the developer. An inbound plug is the navigation event handler that can be registered to a navigation request. Using the generic name <Inbound plug> for an inbound plug, its declaration will cause a method to be generated in the view's component controller, called
HANDLE<Inbound plug>.A static registration of an inbound plug (method HANDLE<Inbound plug>) to the navigation event raised by an outbound plug (method FIRE<Outbound plug>PLG) is called a navigation link. Navigation links are not part of a view but are defined in a window embedding the view. Thus, in different windows, the event registration can be defined differently. An action links a client-side event to an event handler method defined in the corresponding view controller. When defining an action having the name <Action>, an event handler method (ONACTION<Action>) is automatically generated. If a view will be replaced as a result of a client event, the related outbound plug can be fired in this action event handler method. There are two special hook methods found in view controller: wddobeforeaction( ) is processed if a client event is fired in any view. Before the action event handler methods are processed, thewddobeforeaction( )_methods are executed for all views that are part of the last view assembly: _wddomodifyview( ) is a method that allows us to programmatically manipulate the layout of the view. This event can be used to define the UI dynamically. In addition to the standard attributes of all controllers, a view controller has a reference to the component controller of its component: WD_COMP_CONTROLLER. This reference can be used to access functionality related to the component controller. It is used when accessing messages or when calling a method declared in the component controller.
Special Entities of Window Controllers:-
Window controllers are very similar to view controllers. Technically, it is like a view controller without a UI (view layout). All views that are to be displayed when using a Web application have to be embedded in the window that is referred to by the application or the calling component. The Web Dynpro window contains the structure of all views to be displayed and the navigation links defining the possible view assemblies. Each Web Dynpro window contains outbound plugs and inbound plugs, like views. We can use the plugs to set up cross-component navigation. To expose the plugs to the component interface, select the property Interface for each plug. These plugs will then be part of the related interface view. The window controller also has the special attribute WD_COMP_CONTROLLER, which holds the reference to the component controller.
http://wiki.sdn.sap.com/wiki/display/WDABAP/Introduction+to+controllers
Controllers are the active parts of a Web Dynpro application. They define how the user can interact with the Web Dynpro application. The data that a controller can access is defined in the corresponding context. Different instances of controllers and contexts exist within a Web Dynpro application. Controllers contain the source code of a Web Dynpro application; they hold the context data and care for event handling and navigation. Any programming of flow logic requires the knowledge of how controllers are defined and what kind of entities they offer.
Controller Types
There are four types of controllers in an ABAP Web Dynpro component. These different controller types differ in the entities they are composed of:-
1. Component controller:-
There is only one component controller per Web Dynpro component. This is a global controller, visible to all other controllers. The component controller drives the functionality of the entire component. This controller has no visual interface. The lifetime of the component controller equals the lifetime of the component. When starting a Web Dynpro application, the component controller is instantiated by the Web Dynpro runtime
2. Custom controllers
Custom controllers are optional. They have to be defined at design time and can be used to encapsulate sub-functions of the component controller. Multiple custom controllers can be defined in a component. Custom controllers are instantiated automatically by the Web Dynpro framework and the instantiation order is undefined; therefore, the coding in a custom controller should make no assumptions about the existence of any other custom controller. The instantiation of a custom controller is delayed until the first method of the controller is called. Custom controller instances cannot be deleted explicitly.
3. Configuration controller
This is a special custom controller. It is only necessary if the corresponding component implements special configuration and personalization functionality. Only one configuration controller may exist in any component. Any other controller can access the configuration controller, but the configuration controller cannot access any other controller. This controller is instantiated as the first controller of the component. It lives as long as the component lives.
4. View controllers
Each view consists of the layout part and exactly one view controller. This controller cares for view-specific flow logic, like checking user input and handling user actions. The instantiation of a view controller is delayed until the first method of the controller is called. The lifetime of a view controller can be controlled by the views properties. If framework controlled is selected, the view instance will be deleted with the component. If when visible is selected, the view instance is deleted as soon as the view no longer belongs to the view assembly.
5. Window controllers
Each window has exactly one window controller. This controller can be used to care for the data passed via the inbound plugs when being reused as a child controller. Methods of this controller can be called from the inbound plug methods of the window. The instantiation of a window controller is delayed until the first method of this controller is called. This is done by starting a Web Dynpro application or by embedding the related interface view in the parent component's window. Window controller instances cannot be deleted explicitly.
At runtime, all controller instances are singletons in respect to their parent component.
This is also true for view controllers; thus, embedding a view in a view assembly more than one time is not allowed. The global data of a controller is stored in hierarchical data storage, the controller context. This context and the methods defined in a controller are private unless another controller explicitly declares the usage of this controller. However, a view controller cannot be declared as a used controller, so the context data and the methods of a view controller are always private.
Common Controller Entities:-
Each controller has its own context. The context root node already exists. All other nodes and attributes have to be defined statically or by source code. For all controllers, there exist methods that are called by the Web Dynpro framework in a predefined order. These are called hook methods. Depending on the controller type, there are different hook methods available. At least two hook methods are contained in all controller types. These methods are processed only once during the lifetime of a controller instance: when a controller instance is created (wddoinit( )) and when a controller instance is deleted (wddoexit( )). Attributes not related to the value or property of UI elements can be declared using the Attributes tab. These attributes are then visible in all methods of this controller. There are two predefined attributes, which are used to access the functionality of the controller (WD_THIS) and of the context (WD_CONTEXT). For information to be shared between different controllers, one controller must declare the use of another controller. This is done on the Properties tab of the controller that needs to access another controller. The most frequent requirement for this kind of data sharing is when we wish to create a mapped context node or we wish to access another controller's instance methods. We may not specify the name of a view controller as a used controller, as this would violate good MVC design principles. A view controller should be written such that it is responsible for nothing more than the display of data and user interaction. A view controller is not responsible for generating the data it displays; that is the role of a custom controller. Business logic, such as function modules, BAPIs, or methods in helper classes can be accessed from the methods of all controllers.
Special Entities of Component/Custom Controllers:-
For both component and custom controllers, events can be defined with arbitrary parameters. Any method of any other controller (also view and window controllers) can register to these events if this method is defined as an event handler method. A typical use of such events is the invocation of processing in a view controller after processing in the component controller has been completed. This can be achieved when a method in the view controller subscribes to an event raised by the component controller. Using our design time declarations, the Web Dynpro framework will automatically manage the definition, triggering, and handler subscription to such events for us. If two or more methods subscribe to the same event, the order in which they will be executed is undefined. Only the component controller has additional standard hook methods. These are processed directly before the navigation requests are processed (wddobeforenavigation( )) and after all views of the view assembly to be sent have been processed (wddopostprocessing( )).Attributes, methods, context elements, and events can be marked as interface elements. These elements are then exposed to other components by means of the interface controller.
Special Entities of View Controllers:-
A view controller is a visual building block of a Web Dynpro component and is designed to handle all aspects of data display and user interaction. For navigation to take place between different Web Dynpro view controllers, special navigation events and navigation event handlers have been created. These are called navigation plugs. A navigation event is raised when an outbound plug is fired. Using the generic name <Outbound plug> for an outbound plug, its declaration will cause a method to be generated in the view's component controller, called FIRE<Outbound plug>PLG. This method is only visible for the Web Dynpro framework; it is not visible to the developer. An inbound plug is the navigation event handler that can be registered to a navigation request. Using the generic name <Inbound plug> for an inbound plug, its declaration will cause a method to be generated in the view's component controller, called
HANDLE<Inbound plug>.A static registration of an inbound plug (method HANDLE<Inbound plug>) to the navigation event raised by an outbound plug (method FIRE<Outbound plug>PLG) is called a navigation link. Navigation links are not part of a view but are defined in a window embedding the view. Thus, in different windows, the event registration can be defined differently. An action links a client-side event to an event handler method defined in the corresponding view controller. When defining an action having the name <Action>, an event handler method (ONACTION<Action>) is automatically generated. If a view will be replaced as a result of a client event, the related outbound plug can be fired in this action event handler method. There are two special hook methods found in view controller: wddobeforeaction( ) is processed if a client event is fired in any view. Before the action event handler methods are processed, thewddobeforeaction( )_methods are executed for all views that are part of the last view assembly: _wddomodifyview( ) is a method that allows us to programmatically manipulate the layout of the view. This event can be used to define the UI dynamically. In addition to the standard attributes of all controllers, a view controller has a reference to the component controller of its component: WD_COMP_CONTROLLER. This reference can be used to access functionality related to the component controller. It is used when accessing messages or when calling a method declared in the component controller.
Special Entities of Window Controllers:-
Window controllers are very similar to view controllers. Technically, it is like a view controller without a UI (view layout). All views that are to be displayed when using a Web application have to be embedded in the window that is referred to by the application or the calling component. The Web Dynpro window contains the structure of all views to be displayed and the navigation links defining the possible view assemblies. Each Web Dynpro window contains outbound plugs and inbound plugs, like views. We can use the plugs to set up cross-component navigation. To expose the plugs to the component interface, select the property Interface for each plug. These plugs will then be part of the related interface view. The window controller also has the special attribute WD_COMP_CONTROLLER, which holds the reference to the component controller.
http://wiki.sdn.sap.com/wiki/display/WDABAP/Introduction+to+controllers
发表评论
-
abap webdynpro 导入excel并显示
2011-11-10 11:21 3502sdn上有关于将excel如何通过abap webdynpro ... -
关于personalization的设置问题
2011-05-17 21:54 908Application有一个参数WDDISABLE ... -
表的排序或过滤
2011-04-22 10:31 931对一张Webdynpro for abap表进行排序或列 ... -
return to uwl main view con.
2010-12-08 16:11 781前面提到了portal集成工作流项进行审批时,审批完 ... -
return to uwl main view
2010-11-17 16:07 829java里审批完成直接回到列表 WDPortalEventin ... -
一个完整的CRUD例子
2008-12-19 13:41 13001.思想 明确的MVC模式,把所有的方法声明代码实 ... -
Abap Web Dynpro 几个不熟悉的环节
2008-12-14 14:03 1088abap web dynpro的几个不熟悉的环节: 1. 设置 ... -
Implicit and Explicit configuration
2008-12-05 16:53 1079Implicit Customizing Implic ... -
important attributes in different controllers
2008-11-27 12:00 937Controller Attributes Each co ... -
component controller and view controller methods
2008-11-26 19:45 1044Depending on the controller ...
相关推荐
sap wda实例与讲解 sap wda实例与讲解 sap wda实例与讲解
SDN上下的,WDA的教程资料,有图有真相,很详细的,不过由于版本的关系,图可能会有些不致. WDA的初学者,建议下来看看
苹果手机自动化测试 资源 网盘下载 包含Vmware、macos、 xcode、 wda源码 适合小白 希望在window平台实现苹果手机控制 按照视频教程操作可以少走弯路 想在window平台通过虚拟机实现xcode学习、开发的菜鸟
学习Web Dynpro系列 WDA Architecture ,共同进步,共同学习
WDA S60软件汉化全新教程 手机汉化是指把手机软件的语言界面中文化。汉化听起来是一门很高深的技术。其实不然,学会基本的手机汉化很简单,只要您花点时间看这个教程,并加上一点点实践,您也可以像操作word文档...
WDA学习笔记二.docx, webDynproForABAP
创造一个Dynpro组件ZZ_00_BAPIFLIGHT FLIGHTLISTVIEW与一个观点。 包含了数个输入字段,按钮触发一个搜索事件,搜索结果列表显示。该组件BAPI语境指的是一个控制器结构,包含一个服务调用这个BAPI EXECUTE_BAPI_FLIGHT_...
资源来自pypi官网。 资源全名:facebook-wda-0.0.2.dev11.tar.gz
这是显示通过扩展教程网页Dynpro BAPI为ABAP用法与额外——为了要显示一个消息在此情况下,没有航班可供一个特定的出发点与目的地的组合。当然,你将能够重新回到寻找一个新的组合。
火箭620 扩展卡驱动 新的3T硬盘自带的
资源来自pypi官网。 资源全名:facebook-wda-1.0.1.tar.gz
资源分类:Python库 所属语言:Python 资源全名:facebook-wda-0.0.2.dev30.tar.gz 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059
资源分类:Python库 所属语言:Python 使用前提:需要解压 资源全名:facebook_wda-1.4.3-py3-none-any.whl 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059
SAP WDA PA
wda 基础培训教程,适合web dynpro for abap 入门培训用
淘宝tidevice启动WDA背后的秘密
本设计源码提供了一个基于Java的WDA文件在线预览系统。项目包含137个文件,主要使用Java编程语言,并包含了CSS、JavaScript和HTML。文件类型包括53个Java源代码文件、17个JAR包文件、15个PNG图片文件、13个JSP页面...
WDA ALV程序创建显示自己做的记录步骤
python-wda Facebook WebDriverAgent Python客户端库(非官方)在描述的已实现api 大多数功能已完成。 由于facebook / WebDriverAgent已被存档。 推荐使用分叉的WDA: : 经过测试: : 备择方案 gwda(Golang)...