Your Ad Here

Saturday, November 8, 2008

Webdynpro for JAVA

WebDynpro Frame work helps to create applications using declarative programming techniques based on the Model View Controller (MVC) design paradigm. That is, you specify what user interface elements you wish to have on the client, and where those elements will get their data from. All the code to create the user interface is then generated automatically within a standard runtime framework. This relieves you from the repetitive coding tasks involved in writing HTML and then making it interactive with JavaScript.


The WebDynpro technology provides a development and runtime environment for Web applications and enhances classical Web development to build easily adaptable user interfaces. SAP's Web Dyn-pro technology closes significant gaps between typical Web development tools and the needs of cost-effective, responsive, easy-to-use, maintainable, and professional browser-based user interfaces for business solutions. WebDynpro uses design principles similar to SAP's Dynpro technology, but it is a completely new technology geared exclusively towards Web applications. Its main features include the following:
• Usability
• Abstract modelling
• Personalization and customization
• Separation of presentation layers and business logic
• Generic services
• Portability

WebDynpro applications run in the SAP Enterprise Portal.
The main aims are to avoid coding as far as possible and achieve independence from the back-end platform and front-end technology. Web Dynpro delivers a declarative metamodel to develop user interfaces while writing less programming code. Web Dynpro uses this abstract definition to create a ready-to-run Web application for runtime platforms.
Additionally, WebDynpro has a graphical toolset and an embedded IDE (Integrated Development Environment) that help developers to create the Web Dynpro metadata. Since Web Dynpro is a declarative programming toolset, it handles all the mundane aspects of pro-gramming the UI for you. So you can shift your attention away from the specific details of coding the user interface and onto the flow of data through the business process itself.
For instance, if you want a list of suppliers for a particular product displayed in a dropdown list, you just declare a dropdown list and specify where that UI element will get its data from in a data storage area known as the context. To populate the context you have to write some coding but Web Dynpro will generate the coding for the UI and data transport for you.
The only code you have to write is the implementation of those actions that cannot be described in a declarative manner. Such actions would include silently logging on to an SAP system, executing a BAPI call or implementing an action listener event.

What is the difference between Webdynpro and BSP?
BSP (Business Server Pages) is for creating simple web applications using ABAP, HTML and JavaScript. BSP applications are more flexible as we can do lot of client side activities using JavaScript. Where as Webdynpro is used to create Web applications with strict screen guidelines. It is used to create Web transactions with almost similar UI guidelines as SAP GUI transactions. Webdynpro cannot be used to make flexible applications as the webdynpro Framework follows the strict UI guidelines.
From a developer’s point of view, one of the most fun-damental differences is this: In other web development tools, such as BSP or Java Server Pages for in-stance, the unit of development is the web page, and your application consists of a set of connected pages that together, supply the required business functionality.
Not so with Web Dynpro! In the Web Dynpro world, the unit of development is the “component”. A component is a set of related JAVA Classes that together, form a reusable unit of business function-ality.
A component however, can have multiple views. A view is also a set of ABAP Classes that function as a subordinate unit within a component. A view cannot exist outside the scope of its parent compo-nent, but a component could have many views.

The different parts of a Webdynpro Component are,
WebDynpro Component
A component is the unit of a project that contains actual functionality, and if written carefully, can ei-ther be reused by other projects or within other components of the same project.
Web Dynpro has two types of controller:
• View controllers
• Custom controllers: component controller is a type of custom controller.
Component Controller
The component controller is the main controller for the entire component and never has a visual inter-face. This controller is the main repository for the entire component’s data and is the heart of the component's processing logic. Different subsets of the data held within the component controller can be supplied to view controllers for visualization or custom controllers for some specific processing task.
Custom Controller
A custom controller is a special type of controller of a Web Dynpro application, which the Web Dynpro application developer can create explicitly if required. Like all other controller types, the custom controller contains a context class, which is automatically generated when the custom controller is defined. Furthermore, the custom controller contains imported packages and methods that are then relevant to all classes in a Web Dynpro application. The custom controller is also the part of an application that implements the event handlers and validators that react to actions.
Model
A model is any layer of code that encapsulates some business functionality external to the Web Dyn-pro environment. A model provides access to functionality such as BAPI calls or Web services, and can be implemented as a set of proxy objects or Enterprise Java Beans and so on. You create mod-els at project level and each component in the project uses them as needed.
Component Interface
The Web Dynpro component interface consists of two parts: a visual one and a programmatic one, and defines the set of publicly accessible entry points to the component.
You can implement coding to validate user parameters received in the component interface controller.
Underneath the component interface is a controller. The methods and attributes of this controller provide the only publicly accessible entry point into the component. The methods and attributes of all the other controllers making up this component are completely encapsulated, and so invisible to the outside world.
If the functionality of your component is embedded in another Web Dynpro component, the parent component only has access to those methods declared in the interface controller.
The interface controller will, by default, have a view automatically defined. This is because compo-nents usually have a graphical user interface. The implementation of the interface view does not normally require any work beyond simply declaring the existence of the component. Unless you say otherwise, whatever view you first embed into the component’s window will become the default com-ponent interface view.
All controllers can have defined entry and exit points known as plugs. Plugs are the standard entry and exit points to and from all controllers. This means that when the Web Dynpro runtime environ- ment invokes a controller for the very first time, a special inbound plug must be present that acts as the standard entry point. This plug must be of type startup, and is normally called Default.
You may change the name of plug Default if you wish, but if you change its type to something other than startup, then when the Web Dynpro runtime fires the event to start the application, an unhan-dled event exception occurs.
Since you have a standalone component that does not embed any other components, and is not em-bedded in another component, you can ignore the interface controller.
Default Window
The default window is usually needed since almost all components have some sort of visual interface. However, if you are creating a faceless component, the default window will still be present, but just unimplemented.
Window
Whenever you create a component, a window is automatically created for that component. Normally, this window will have at least one view embedded within it, and becomes the default interface with which the user interacts. However, you can create what is known as a faceless component, that is, a component that has no user interaction. Such faceless components will only work in combination with normal components that contain views, since the whole point of the Web Dynpro toolset is to provide a browser-based user interface to business functionality.
View
A view is the visual component inside a window with which a user interacts. To be visible a compo-nent, it must have at least one view. A window can have multiple views arranged in different layouts, for example grid-, flow- or matrix layout, or even have views nested within views.
Application
An application defines an entry point into a Web Dynpro component. Components, in themselves, cannot be accessed directly by the client software. Instead, they must be accessed via an applica-tion. The application associates a URL with a standard entry point in the component interface known as a plug. There is a one-to-one relationship between an application and a component entry point. Therefore, if you wish to give your component multiple entry points, you must define multiple applica-tions.
What is a Context?
All controllers, whether view controllers, custom controllers or component controllers, have a dynamic data storage area known as a context. The context consists of a basic static structure, to which you can add both data and metadata at runtime. The actual context structure obtained at runtime is de-pendent upon the declarations you make at design time.
The context holds both metadata and actual data. However, the context is not a passive data storage area; rather it is a highly dynamic, hierarchical data storage class whose metadata is defined at de-sign time, but whose actual contents (and possibly even extra metadata) are not known until runtime.3
You can think of the context as the central, dynamic class that supplies a controller with both the ac-tual data upon which it acts, and the metadata to describe that data.
Context Structure
The context is a hierarchy consisting of two basic types of entity – nodes and attributes. The only difference between the two is that a node may have children, and an attribute may not.
Nodes and attributes that have the context root node as their immediate parent are referred to as independent. Nodes and attributes that have some other node as their parent are referred to as de-pendent.
The difference between independent and dependent nodes does not feature in this example. But in complex situations where a child component must map one of its context nodes to a node living in a parent component, the difference becomes significant.

Cardinality
Cardinality represents the number of elements a node has at the start of the application and maximum number of elements it could have. It has two parts, Mandatory and Maximum. Mandatory represents the number of elements a node has at the start of the application and Maximum represents the maximum number of elements it could have during its life time.

Cardinality
Meaning
1:1
The node contains only one element instance; this instance is instantiated automatically.
0:1
The node contains only one element instance; this instance must not be instantiated.
1:n
The node can contain multiple element instances of which at least one must always be instantiated (and is instantiated automatically).
0:n
The node can contain multiple element instances of which none have to be instantiated.
What are the Standard Hook Methods For?
When a controller class is created, there are certain standard hook methods that are always present irrespective of whether or not you implement them.
The methods WDDOINIT and WDDOEXIT are always present in all controllers and serve the fol-lowing purposes.
• The method WDDOINIT is called immediately after the controller has been instantiated. Preparatory work should be performed in this method.
• The method WDDOEXIT is called immediately before the controller is garbage collected. You should write code to perform clean up tasks in this method.
What are Singleton and Non-Singleton Nodes?
In general, dependent nodes are represented by a single node instance, whose content – that is, its node collection - changes each time the lead selection of the parent node changes. Such context nodes are known as single nodes. The existence of a single node instance considerably reduces the resources that are required at runtime. This improves the performance of the application significantly. However, the use of singleton nodes also results in programming restrictions. This means that the user can only access data of the child nodes that belong to the code element (lead selection) currently selected in the parent node. Consequently, you cannot read - for example - the address fields of a business partner X if business partner Y is currently selected. Each modification of the parent node lead selection causes a data modification of the singleton child node.
Therefore, Web Dynpro allows you to define additional non-singleton nodes. Each non-singleton node has one node instance for each node element of the parent collection at runtime. The advantage is that each instance can be accessed directly. When using non-singleton nodes, the nodes are only created when the node values are retrieved. This can save resources that otherwise would slow down the performance of the application.

Supply Function is used to populate the values in a node on demand. The supply function is called by the runtime when the data of the context node is used. This is the case when a UI element is to be displayed for the first time with the data of the corresponding context.

No comments:

 

Copyright © 2008 SAP nxt. All Rights Reserved.
All product names are trademarks of their respective companies. This blog is in no way affiliated with SAP AG or any of its subsidiaries.
Every effort is made to ensure the content integrity. Information used from this blog is at your own risk.

Free Domain & Hosting