User Interface 
You can use many different UI elements when designing the user interface of a Web Dynpro ABAP application, and you can combine and nest these elements in many different ways. The latter aspect of UI design can, however, cause overly complex views to be created that not only tax the user but are also bad for the application's performance. For these reasons, always try to avoid making the structures in your views overly complex.
Matrix Layout
In a view layout with a standard level of complexity, always use the matrix layout even if the default setting of the View Editor is a flow layout. A matrix layout benefits you by providing several formatting utilities that are otherwise very difficult to design. A matrix layout is not, however, suitable if you want your view to have a very simple layout. In this case, use a flow layout or grid layout for performance reasons.
In a matrix layout, properties strechedHorizontally and strechedVertically are set by default. Disable the strechedVertically property, since it can often cause browser errors at runtime. For UI elements embedded in matrix layout, you can define vaues for height and width under LayoutData. The values you enter here are defined as pixel values ("px") by default. You can change this unit from "px" to "em" or "ex" (see the CSS Standards).
Tree Versus Table
We recommend you use the Tree only for a small number of entries, since it does not support server scrolling (<100 entries). For performance reasons the table with TreeByNestingColumn of TreeByKeyColumn should be used in preference.
Server performance is on a linear scale to the number of expanded tree entries, since with every round trip the whole tree must be expanded. A scaling factor is added that behaves linearly to the visible size of the table UI element, that is, to the number of visible rows and columns. Client performance is proportional to the size of the table UI element.
The table without a tree is only dependent on the size of the table UI element.
Dynamic Programming
Web Dynpro ABAP enables you to manipulate the view layout dynamically, which means you can create, modify, or remove specific UI elements at runtime. The user of the application can personalize some properties of UI elements though, making the application developer unaware of the values of these properties.
Example
The property visibleRowCount of the table element of a view was set to 10 at design time. At runtime, however, a user set a personalized value of 15. This produces two aspects that need to be handled by dynamic maniputlation:
You cannot program a dynamic modification of the table element for which the personalized value of the visibleRowCount property is required, since runtime cannot access this value. If you retrieve the value of visibleRowCount here, runtime always produces the initial value 10 and not the personalized value 15. To avoid errors, you must never base the dynamic manipulation of a UI element on a value that can be personalized.
If you modify an element property, the modification is valid only if the user does not personalize the property. In our example, it is possible that the visibleRowCount property is raised dynamically to 12. All users that have not personalized this property are given a table with 12 visible rows. Any user who have personalized this property are given a table with their number of rows, 15 in our example. The personalized values are always given priority.
If you use dynamic methods to create a UI element, make sure that you give each element an element ID. Technically, this is an optional property, but it is a great help when the element is processed. Implicit personalization can work only if an ID is set, since stable assignments of values can only be made to the same UI element. If you do not define an element ID, the elements are given new random IDs each time they are called and the personalized values cannot be assigned.
Note
You often do not know how many elements need to be created at design time. For example, if you want to create a form dynamically, and you do not know its context nodes at design time, you must assign element IDs generically. In this case, ensure that your chosen algorithm provides unique results. Simply numbering the elements sequentially is not enough to ensure that each dynamic UI element appears in the right position in the view. For example, a "Price" attribute may appear as the third attribute in node A, but as the fifth attribute in the structure in node B. In this case, it is more effective to use the attribute name as the element ID.
ALV Component
The ALV component offers application developers a range of integrated services that they can use directly without any additional programming work. These services includes functions such as filters, sort functions, and total functions. However, each additional ALV component you use increases runtime significantly; the table UI control is quicker for displaying simple tables. Use the ALV component only if you are sure you need its extra functions. Always choose a simple Web Dynpro table if sufficient for your application.
When you use an ALV component, you can pass the data for display using either a regular cross-component mapping or an external context mapping.
Configuration Options
Make use of the personalization and configuration options when you develop your applications. When you create generic components, however, remember that subsequent application developers may themselves want to add dynamic UI elements. It is not a good idea to define a maximum set of UI elements at the beginning and assume that many of these elements will be deactivated later. Restrict yourself only to those elements that you actually need when you create your components.
More information: