- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
NWDS
- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-10-2009 8:48 AM
i want to know about the use of
1.Webdynpro Component Interfaces
2.interface controller
3.Implementing Interfaces
4.what is the difference between Custom Controllers and Component Controllers
and also can u tell me how to make use of them
- SAP Managed Tags:
- UI Web Dynpro Java
Accepted Solutions (0)
Answers (8)
Answers (8)
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
i had some problem in system so it post 3 times
Edited by: Ruturaj Inamdar on Jan 13, 2009 7:35 AM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
For web dynpro component Interface
Difference between CustomController and ComponentController
Regards
Ruturaj
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
For web dynpro component Interface
Difference between CustomController and ComponentController
Regards
Ruturaj
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
One of the main advantages of the original MVC design was its focus on the reusability of models, views, and controllers as individual coding units. However, Web Dynpro is focused on more than just the technical reuse of coding entities. Instead, Web Dynpro has been designed to be the foundation for implementing business solutions. Therefore, one of the key elements in its design was the need to provide a reusable unit of code that corresponded to an atomic step within a business process, rather than trying to build business solutions from reusable units of low level code that, in themselves, were not directly related to the business process.
In other words, the Web Dynpro component is a reusable unit of code at the business process level, rather than the technical coding level.
The resulting change in the nature of code reuse produces a shift in the developeru2019s focus of attention during coding. No longer are they concerned so much with the reuse of technical coding units; instead, the design of a Web Dynpro component focuses on the reuse of atomic units of business processing.
A component can be thought of as a set of controllers, views, and model usage declarations that have been aggregated for the specific purpose of reuse.
Always think of the Web Dynpro component as both:
u2022 Your unit of development and
u2022 Your unit of reuse
A component is therefore, the minimum unit of coding required when developing an executable Web Dynpro application [Page 12].
Figure 3: The composition of a Web Dynpro Component Web Dynpro Architecture Version 645 13
SAP Online Help 14.03.2006
As can be seen in Figure 3, a Web Dynpro component is not a single coding entity; rather, it is an aggregation of various controllers, views, windows, and model usages which, when taken together, form the reusable unit of business processing known as a component.
There are several key features that must be clearly understood concerning the structure of a Web Dynpro component:
1. It contains coding entities that are hidden from the outside world, and it also contains coding entities that are visible to the outside world. These two types of coding entity are divided from each other by the horizontal dotted line across the top of Figure 3.
2. It contains coding entities that handle the visual representation of data, and coding entities that handle the processing of data. These two types of coding entity are divided from each other by the vertical dotted line down the middle of Figure 3.
3. Within the scope of a component, the various controllers are designed as independent, yet interrelated programs. Therefore, if one controller wishes to gain access to the data and functionality within another controller (in the same component), a usage declaration must first be made: hence the u201CUsage Declarationu201D arrows between the various controllers in Figure 3.
4. Model objects are defined outside the scope of any particular Web Dynpro component. Once a model object has been created, any component can access its functionality by means of a usage declaration.
5. Web Dynpro components can use the data and functionality found within other Web Dynpro components. In order to achieve this, a usage declaration must be made in order to establish a u201CParent-Childu201D relationship between the two components.
Lifespan of a Web Dynpro Component
There are two distinct lifespan scenarios for Web Dynpro components:
1. Lifespan of the applicationu2019s root component
The component chosen to act as the applicationu2019s entry point is known as the root component (see Figure 2). When a user invokes the associated URL, the Web Dynpro framework creates an instance of the applicationu2019s root component.
This component instance will persist until such time as the user formally terminates the application, or closes their client (e.g. the browser), enters a new URL, or remains inactive for the configured time out period.
2. Lifespan of a child component
Any Web Dynpro component may act as the child of any other Web Dynpro component. In such cases, the lifespan of the child component may either be controlled automatically by the Web Dynpro framework, or it may be controlled by coding written by the application developer in the parent component.
The faceless Component
Should you require it, it is possible to create a Web Dynpro component that has no visual interface. In other words, it is a component with zero views and zero windows. Such a component is known as a u201Cfacelessu201D component and is useful when a complex unit of functionality requiring no direct user interaction needs to be encapsulated.
A good example of a faceless component is the creation of something called a model component. This is not actually a specific Web Dynpro component type; rather it is a standard Web Dynpro component that has been written specifically for the task of interacting with a model object.
Web Dynpro Architecture Version 645 14
SAP Online Help 14.03.2006
Often, a model object could have large or complex interface. Since model objects are completely reusable, it does not make sense to have to reimplement the functionality required to interact with the model object every time it is reused. Therefore, SAP recommends that when a model objectu2019s interface requires any type of additional processing or simplification, that the model object be encapsulated within a component in order to be able to reuse the associated interface coding. Very often (though not exclusively) a model component will have no visual interface, thus making it a faceless component.
The model component then becomes the unit of reuse rather than the model object.
Web Dynpro Architecture Version 645 15
SAP Online Help 14.03.2006
A quick overview
By referring to the diagram in Figure 3, you can see that a Web Dynpro component is not just a single program. Instead, it is composed of several programs that interact with each other to fulfil the required task. Before we look at the details of how all these different units of code function within the component, it is worth showing the end result first.
On the right of Figure 4 below is a table that will be seen on the client. The data displayed in this table is obtained from a data storage area in the view controller known as the context. The view controller, in turn, obtains its data from the component controlleru2019s context.
The beauty of the Web Dynpro programming model is that the relationships between the different controllers are created declaratively. It is not necessary to write any code to transfer data from one controller to another. The only code that does need to be written is that which populates the context of the component controller; everything else happens automatically.
So, using nothing more than a declared chain of relationships, it is possible to display data held in the context of a component controller without having to write a single line of code to transport the data anywhere.
Figure 4: Displaying data held in the component controlleru2019s context using a combination of context mapping and UI element binding.
Figure 4 above shows that the data held in the context of the component controller (on the left) can be made available to the context of the view controller, which in turn, makes the data available to the various UI elements.
Thus, data will automatically appear on the screen. The only manual coding necessary is that required to place the data into the component controlleru2019s context. The Web Dynpro framework handles everything else for you based on your design time declarations.
We will now take a closer look at the controllers found within a Web Dynpro component.
Web Dynpro Architecture Version 645 16
SAP Online Help 14.03.2006
Web Dynpro Controllers
Definition
Controllers are the active parts of a Web Dynpro component. In the design of Web Dynpro controllers, SAP has made a significant modification to the original MVC concept of a controller. In broad terms, SAP has defined two categories of Web Dynpro controller. The difference between them is simply this: A controller either
u2022 Has a visual interface, or
u2022 Does not have a visual interface.
SAP has introduced this difference in order to maintain a strict separation between those parts of the business application that display data (typically data consumers), and those parts of the business application that process data (typically data generators).
Controllers having no visual interface
The red ovals in Figure 5 below show the controllers in a Web Dynpro component that have no visual interface. As is to be expected, all these controllers are located entirely on the u201CProgrammatic Entitiesu201D side of the diagram.
Figure 5: Web Dynpro Controllers with no visual interface
Controllers that have no visual interface are generically known as custom controllers. At a basic level, the component controller and the interface controller can be thought of as special cases of custom controllers. This statement is a somewhat simplistic, but at an introductory level it serves well to illustrate the general behaviour. Web Dynpro Architecture Version 645 17
SAP Online Help 14.03.2006
Structure of custom controllers
All custom controllers have the following structure:
Figure 6: Web Dynpro Controllers that have no visual interface All controllers lacking a visual interface are primarily responsible for generating data that will ultimately be supplied to a view controller for display.
In order to gain access to the data and functionality found in other Web Dynpro coding entities, usage declarations must be made. These declarations are represented by the three boxes down the left of Figure 6 entitled u201COther WD Controllersu201D, u201COther WD Componentsu201D, and u201CModelsu201D.
Required Controllers
All Web Dynpro controllers are independent programs in their own right; therefore, if access is required to data or functionality found in another controller (within the same component), then a specific usage declaration must be made. Only after this declaration has been made is it possible to access the data and functionality found in the other controller. Data is shared between controllers by means of a mechanism known as u201Ccontext mappingu201D.
There are two important points to be made about the usage declarations between custom controllers. A custom controller is only permitted to:
u2022 Declare the use of another custom controller.
u2022 Declare the use another custom controller within the same component.
It is not permitted to declare the use of a view controller as a required controller as this would violate the principle that view controllers are only permitted to act as consumers of data, not generators.
Model Usage
Model objects are created independently from Web Dynpro components. However, once a model object has been declared for use (at the Web Dynpro component level), all controllers within the component have implicit access to the data and functionality found within it.
Web Dynpro Architecture Version 645 18
SAP Online Help 14.03.2006
Be careful here! It is technically possible for a view controller to interact directly with a model object. But would this violate any known principles of Web Dynpro design? The answer is most definitely u201CYes!u201D
A view controller is not responsible for generating the data it displays; therefore, whilst it is technically possible, a view controller should not interact directly with a model object.10
Component Usage
In order to maximise code reuse, atomic units of business functionality should be packaged into components. Then, in order to make use of these reusable units of code, one component can declare the use of another component. This forms a Parent-Child relationship between the two components, with the childu2019s interface controller being the point of interaction.
As soon as the component acting as the parent, declares the use of the child component, the parent component controller has access to all the data and functionality found in the child componentu2019s interface controller.
Implementation
The implementation of any Web Dynpro controller will always contain a standard framework of generated code, within which are sections of code written by the developer at design time.
Standard Hook Methods
The standard hook methods act as a static interface between the Web Dynpro framework and the coding written by the application developer. These hook methods may not be renamed or modified in any way; however, the Web Dynpro developer will frequently need to insert their own coding into these methods.
The Web Dynpro developer is not responsible for explicitly calling any of the hook methods; that job is performed by the Web Dynpro framework. They will be called automatically by the Web Dynpro framework at predefined points in time such as component initialisation, and just prior to the controlleru2019s end-of-life (to name but a few).
Instance Methods
The Web Dynpro developer may declare the existence of any instance methods they feel necessary for the completion of their business task. Such methods will never be called directly by the Web Dynpro framework, but the developer may insert calls to their instance methods from coding they have added within one of the standard hook methods.
Events
Events are declared runtime objects that represent standard server side triggers for invoking subsequent business processing. An instance method may be declared to act as a handler for such an event.
Context
Irrespective of its type, every Web Dynpro controller has a data storage area known as the context. This is a hierarchical repository within which all runtime data used by the controller is stored. The metadata used to define the structure of the context is typically defined at design time, but can also be defined dynamically at runtime.
As soon as the controller instance reaches the end of its lifecycle, then the all the data in its context is lost. It is incumbent upon the Web Dynpro developer to write the necessary coding to store all required context data before the controller reaches this point.
10 There is one legitimate exception to this rule. In Web Dynpro for Java, a certain type of pop-up help selector can be written called an u201CObject Value Selectoru201D. In this situation, it is permissible for a view controller to interact directly with a model object, and thus generate its own data.
Web
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
Hi Gorkhy,
Is your question answered? If not then post your further doubt else mark your question answered and award points to the helpful answer accordingly.
Regards.
Rajat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
Hello Gorkhy,
1.check the following link for Webdynpro Component Interfaces,
2.Interface controller
http://help.sap.com/saphelp_erp2005/helpdata/en/9c/a5863f455f3417e10000000a114084/content.htm
3.Implementing Interfaces is for the communication among webdynpro components.
Regards,
Jayapriya
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
Hi Gorkhy,
Basically the functionality of both type of controllers (custom and component) is same. The main difference is that there can be only 1 custom controller in a Webdynpro project while there can be multiple custom controllers.
For knowing the difference between custom controller and component controller, check the following link:
These links also throw light how and when one can chose which controller to be used.
For webdynpro component interfaces please check the following blog:
/people/bertram.ganz/blog/2007/01/19/new-web-dynpro-java-tutorial--component-interface-definitions-in-practice
Also refer to following links:
http://help.sap.com/saphelp_nw04/helpdata/en/9c/a5863f455f3417e10000000a114084/frameset.htm
These links will be helpful to you.
I could not understand what do you want to know about implemented interfaces? Please give some more details.
Regards.
Rajat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Report Inappropriate Content
Hi,
the below links may help you,
Custom Controllers :
http://help.sap.com/saphelp_nw70/helpdata/EN/44/0dca942d9d1ca2e10000000a11466f/frameset.htm
Web Dynpro Component Interface Defintions in Practice
Regards,
ramesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
- In NWDS when exporting mapping to spreadsheet the constant values are not visible in Technology Q&A
- import of com.tc.webdynpro cannot be resolved NWDS 7.50 in Technology Q&A
- PGP Encryption/Decryption using Java code inside payload in Technology Blogs by Members
- Need to make a connection to KM repository through JSPDynPage in Technology Q&A
- Help! Sometimes navigation problem in app with dump prevents Golive in Technology Q&A
| User | Count |
|---|---|
| 93 | |
| 10 | |
| 10 | |
| 9 | |
| 9 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.