12.6. 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: 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.

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

• The viewing user must be authenticated by having logged so that the user ID can be read from the user cookie.

• The ACSObject ID must be in the page state as a global parameter (current implementation to support URL redirects and URL referencing in WAF 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 this to build permissions tables with a privilege array customized for your application:

PermissionsPane(PrivilegeDescriptor[] privs)

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 the PermissionsPane class directly, you get a UI layout equivalent to what you see at http://yourhost.com/permissions/, using 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 showFoo 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, meaning 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.