Red Hat Web Application Framework Developer Guide
Prev		Next

Chapter 9. UI Tutorial

The permissions UI provides reusable components for building customized permission administration interfaces.

The default implementation of it resides under /permissions/. It supports a standard set of permissions, namely, READ, WRITE, CREATE, DELETE, ADMIN. A user or group with admin privilege on an object can share the privileges with other parties using this interface.

How to create a custom permissions UI

There are two requirements to show an object's permission tables.

The viewing user must be authenticated, that is, logged in recently so that his userID can be read from the user cookie.
The ACSObject's ID must be in the page state as a global parameter (current implementation to support URL redirects and URL referencing in Red Hat Web Application Framework Tcl style).

The first step is to create the embedding bebop Page for the permissions UI. A simple example is ObjectPermissionsPage.java. This only has a UserAuthenticationListener in the constructor and builds a PermissionsPane using the default constructor. Note, that the default constructor will give you the permissions table with READ, WRITE, CREATE, DELETE, ADMIN privileges (as defined in PermissionsConstants.java). You can use
PermissionsPane(PrivilegeDescriptor[] privs)
to build permissions tables with a privilege array customized for your application. The main class that provides components for the permissions UI is PermissionsPane. It has dual functionality:

(1) it implements the generic permissions UI for ACSObjects,
(2) it provides getter methods to retrieve only parts of the interface.

If you use PermissionsPane class directly, you get an UI layout equivalent to what you see at http://yourhost.com/permissions/ only with your privileges instead. If you want to use only certain components of PermissionsPane, you must subclass it and overwrite the following public methods:

public void register(Page p),
public void showAdmin(PageState s),
public void showGrant(PageState s),
public void showNoResults(PageState s).

The register determines which and how many components you are going to use. The showXXX methods manage visibility of components. You can also write your own "visibility manager" in the subclass in a similar way, and just use that. You could also overwrite the other public methods, for example, to provide alternative or static components for faster testing, or to save a member variable in the subclass. Also, consider the reset() function. The components that can be extracted from PermissionsPane are:

public Party getRequestingUser(PageState s)
public ACSObject getObject(PageState s)
public Label getTitle()
public String[] getPrivileges()
private PermissionsTables getPermissionsTables()
public SimpleContainer getDirectPermissionsPanel()
public SimpleContainer getInheritedPermissionsPanel()
public Form getUserSearchForm()
public SimpleContainer getPermissionGrantPanel()
public SimpleContainer getPermissionsHeader()
public SimpleContainer getNoSearchResultPanel()
public SimpleComponent getContextPanel()

These functions all use lazy instantiators, that is, they are not constructed until they are needed. Therefore instantiating PermissionsPane alone is not expensive, the components are computed only once and on the fly.

Note, if you want the same HTML style as in the default implementation, you MUST import the permissions.xsl stylesheet in the application's stylesheet, for example:
<xsl:import href="../../content-section/xsl/permissions.xsl"/>
Otherwise the bebop components are rendered in their default style.

Prev	Home	Next
Logging	Up	Categorization