|
UIDescriptorAn entry for a factory must contain the factory, itself, hidden in a MarshalledObject and some string representation of the factory's class(es). It may also need other descriptive information about the factory. The UIDescriptor captures all this: package net.jini.lookup.entry; public class UIDescriptor extends AbstractEntry { public String role; public String toolkit; public Set attributes; public MarshalledObject factory; public UIDescriptor(); public UIDescriptor(String role, String toolkit, Set attributes, MarshalledObject factory); public final Object getUIFactory(ClassLoader parentLoader) throws IOException, ClassNotFoundException; } There are several features in the UIDescriptor that we haven't mentioned yet, and the factory type appears to be missing (it is one of the attributes ). ToolkitA user interface will typically require a particular package to be present or it will not function. For example, a factory that creates a JFrame will require the javax.swing package. These requirements can provide a quick filter for whether or not to accept a factory ”if it is based on a package the client doesn't have, then it can just reject this factory. This isn't a bulletproof means of selection. For example, the Java Media Framework is a fixed- size package designed to handle lots of different media types, so if your user interface is a QuickTime movie, you might specify the JMF package. However, the media types handled by the JMF package are not fixed, and they can depend on native code libraries. For example, the current Solaris version of the JMF package has a native code library to handle MPEG movies, which is not present in the Linux version. Having the package specified by the toolkit does not guarantee that the class files for this user interface will be present. It is primarily intended to narrow lookups based on the UIs offered . RoleThere are many possible roles for a user interface. For example, a typical user may be using the service, in which case the UI plays the "main" role. Alternatively, a system administrator may be managing the service, and he or she might require a different user interface, in which case the UI then plays the "admin" role. The role field in a UIDescriptor is intended to describe these possible variations in the use of a user interface. The value of this field is a string, and to reduce the possibility of spelling errors that are not discovered until runtime, the value should be one of several constant string values. These string constants are defined in a set of type interfaces known as role interfaces. There are currently three role interfaces:
A service will specify a role for each of the user interfaces it supplies . This role is given in a number of ways for different objects:
The service must ensure that the UIDescriptors it produces follows these rules. How it actually does so is not specified. There are several possibilities, including these:
The factory could perform some sanity checking if desired; since all roleObjects are (presently) the service items, it could search through these items for the UIDescriptor , and then check that its role matches what the factory expects. There has been much discussion about "flavors" of roles, such as an "expert" role or a "learner" role. This has been deferred because it is too complicated, at least for the first version of the specification. AttributesThe attributes section of a UIDescriptor can carry any other information about the user interface object that the service thinks might be useful to clients trying to decide which user interface to choose. Currently this includes the following:
|