Version 8.2 (2013-03-18)
 —  Special Development Topics  —

Customized Layout - Concepts

This document covers the following topics:


Overview

Let us approach the framework from the result side. The following screen is a simple address maintenance:

graphics/image243.png

You see that in the right top corner there is a special icon directly to left of the close icon. This "personalization icon" is not always visible. It is only visible, if a certain parameter is defined inside the session context (e.g. when an administrator logs on).

When choosing the icon, a window appears:

graphics/image244.png

The window shows on the left a tree of personalizable aspects. When selecting a node, the aspect can be edited on the right. In our example, we set the "Street (2)" aspect and the "Check ZIP Code" aspect to be invisible. Make sure that the personalization is done within a certain scenario (in this example, the scenario has the name "customer").

After choosing the Save and Close button, the address page now looks as follows:

graphics/image245.png

You see that two lines have disappeared. This definition and the corresponding screen layout are now automatically valid for all users that work in the personalization scenario "customer". Maybe other users work in a different scenario and thus see a different screen layout.

The framework basics will be explained below, and the implementation of the above address example will be shown in detail.

Top of page

Dynamic Controls

The basis of all personalization is the possibility to define a control's rendering and behavior dynamically via the adapter. Each BUTTON control, for example, provides for a visibleprop property by which the adapter can specify whether the button is shown or not.

The control of visibility was much extended for personalization purposes. It is possible to control visibility for all major controls including:

By defining the visibleprop properties in the controls, you can - without using the next framework parts - already control the page layout dynamically in a detailed way. It is up to you to specify where and how to use the visibleprop definitions. Sometimes it is useful to use the definitions on single elements (e.g. BUTTON controls). Sometimes it is useful to define the visibility on row level (ITR, TR control). If inside your screen there is the combination of "label and field in one row", then it makes sense to define visibility on row level.

Top of page

Using Filters

Having defined the visibleprop definitions inside the page, the question now is how to provide for the corresponding property values at runtime.

The concept of filters offers a flexible and efficient way to provide for the values in front of the adapter logic - without even letting the adapter logic know about.

Filters

After the Application Designer framework has collected the property values from the adapter, it passes them to a filter that may be assigned to an adapter. The filter can now manipulate the values. This means it can

What does this mean for personalization? It means that the adapter does not need to implement all the visibleprop properties on its own but can "outsource" this task to a generic filter.

Top of page

Personalization Filter

The personalization filter is a concrete filter implementation that is responsible for providing personalization data values. On the one hand, the personalization filter is kept well apart from the Application Designer framework; i.e. you will not find any specific personalization aspects inside the base framework of Application Designer (e.g. there are no personalization methods inside the Adapter class). On the other hand, it is tightly integrated into the Application Designer framework - being a concrete implementation of open interfaces that are offered.

The main aspects of the personalization filter are:

Top of page

Personalization Scenario Sequence

It is possible to define a sequence of personalization scenarios at runtime. Maybe a user is assigned after having logged on to the scenarios "Department 12", "Business Unit1". In this case, the personalization filter first tries to find filter information for "Department 12"; if filter information is not defined, then it tries to find filter information for "Business Unit1".

Consequently, you can set up a flexible way to try to provide for the most detailed personalization definition for specific screens - and referencing to a general personalization definition (or none at all) for other screens.

Top of page

Maintaining Personalization Data

Personalization data is maintained through a specific page. The maintenance page may be accessed directly from a personalized page via a certain control - a certain icon in the title bar. This icon is only visible when a certain context parameter is set. It should not be visible during normal user sessions, but should only be available for administrative sessions.

Top of page

Persisting Personalization Data

The personalization data is stored in the local file system, inside the directory /pers of an Application Designer project.

Caution:
Filter information is runtime information, not design time information. This means: filter information is not part, for example, of a WAR file that you deliver, it is maintained within a delivered system by your customer.

Top of page