PortalDataViewer and Tables

When to Use the PortalDataViewer | Building Blocks and Content Distribution | Paging in Tables and PortalDataViewers | Sorting Columns | Links Inside a Table / PortalDataViewer | Displaying Status Information | Implementing the PortalDataViewer

This chapter deals essentially with the PortalDataViewer (the former PortalALV) and the ways of using it in the best possible way. However, the PortalDataViewer is only one specific instance of a table, and many of the issues discussed here are consequently valid for non-ALV based tables as well.

 

When to Use the PortalDataViewer

The Portal Data Viewer (PDV) is a tool, which can be used to present tabular data in in the Java based Enterprise Portal EP 5.0. (SAP Internal Technical Documentation PDV). Main focus has been set to the presentation of data coming from SAP backend systems. The PDV offers generic functionality for user interaction and reduces programming efforts for iViews significantly. It is even possible to create iViews without any programming - just by providing the appropriate properties in a profile.

A PortalDataViewer should not be used if

  • there are only a few sets of data which could easily be displayed in a textual form (e.g. an inbox-overview like: 3 new workitems and 2 unread mails) or as a simple list (see Texts, Links, Lists)
  • values have to be sorted, filtered or processed using complex criteria or methods
  • there are alternative forms of presentation that are more suitable for the content (e.g. displaying numbers as graphics or charts)

Although the PortalDataViewer can be used for many purposes and it is definitely convenient to 'include PortalDataViewer' and get a complete iView for free, there is often a better design solution available.

 

Building Blocks and Content Distribution

Figure 1: An example of a PortalDataViewer

The PortalDataViewer has essentially four different areas in which information can be displayed:

  • The blue table header
  • The column headers
  • The actual 'table' or data area
  • A status line for displaying scrolling buttons (if applicable)

Each of these areas serves a different purpose. While the usage of column headers and the data area is quite clear, it requires a bit more explanation to specify which kind of information should be displayed in the table header or in the status line.

The title area can be used for

  • A description of the table content if the PortalDataViewer is not the only 'grouping' element inside the iView.
  • Dynamic content like the number of retrieved results

The title should not be used

  • If the PortalDataViewer is the major element of an iView and the title would essentially repeat the title of the iView itself.
  • If the title contains no text and would be an empty element

If there is no reasonable title for a PortalDataViewer or table, omit the title element. 

The status line of the PortalDataViewer is used for the paging buttons plus a display of the current page / dataset (this has be defined in detail).

 

Paging in Tables and PortalDataViewers

The PortalDataViewer provides one approach for scrolling through lists of data. The current solution 'pages' through a list, i.e. a new 'page' of data is displayed by clicking one of the buttons in the status-line of a table (see figure 2).

Figure 2: Tables with paging

Sorting, Calculating Totals and even more

The user can personalize the table layout by:

  • changing the order of the columns
  • hiding some columns
  • sorting by one or more fields
  • calculating totals, averages, maxima, minima or setting a counter
  • calculating subtotals for the sort fields
  • choosing a background design or the number of displayed rows per page
The starting point is the "standard" layout defined by the application.
However, if this possibility is not desired (from the application point of view), it can be switched off (even parts of the settings, e.g. only hiding of columns might be supressed).

These personalization settings are be persisted in the PCD (can be disabled).

 

Links Inside a Table / PortalDataViewer

If links are used inside a PortalDataViewer to jump to different locations (e.g. a related IAC), make sure to provide only one jump target. It may be technically possible to provide a different link with a different target for every column, but iViews should be kept as simple and concise as possible.

If you provide a link inside a PortalDataViewer, make sure there is only one column that contains this link. Links with the same location in different columns should be avoided in the same way as links with multiple locations.

The link should always be represented as a text link. Having a link location on an icon always results in a large probability of not finding the links at all. Icons inside the ALV are status icons and should not be used for any kind of interaction.

 

Displaying Status Information

When using status icons in a PortalDataViewer, make sure the status is always displayed in the first column (cf. Figure 3). This is especially important if the status of an element is the primary information in a table (e.g. critical process steps) and the user should be able to quickly perceive the different 'groups' of statuses. An exception from this rule are items which may contain more than one status, and the status overview merely is an additional information and not the primary 'sorting' criterion.

Make sure the title for a status contains an explanatory title, ideally describing the meaning of the status icons (e.g. 'read' or 'Project Status').

You can find more detailed information on status icons and icons and status information in the corresponding chapters.

 

Figure 3: A table displaying status information in the first column.

Implementing the PortalDataViewer

The main part of the PDV is implemented as a portal service. This service itself uses other services of the portal like HTMLB or JCO. The Portal Content Directory (PCD) serves as the persistence layer for the PDV properties, especially for the PDV personalization data.

The PDV service has two kinds of "clients": specific application iViews and the generic PDV iView.
The generic PDV iView covers the "simple" cases, where parameters are sufficient to define the access to a data source. By this, no programming on the middleware is necessary. However, a data source might be a complex program in a SAP system.
Application iViews can use the PDV as a programming API. By this, the application inherits the PDV functionality and can focus on application specific programming (additional interactions and business logic).

When should I use Portal Data Viewer?

  • Is a table the main part of your iView (either only a table or a table together with other elements)?
  • Do you want to use HTMLBusiness for Java in your iView?
  • Do you want to offer interactive functionality (sorting, summing, configuration & personalization of the table layout) for this table?

If your answer to these questions is "yes", your iView may be a canditate for a Portal Data Viewer (PDV) application. Especially, if you are dealing with table content coming from SAP systems, the PDV maybe the tool of your choice.

 

top top

Source:  SAP iView Guidelines for Java