LS.2. Human Access to Attributes

LS.2.1. Providing a Single View of an Attribute’s Value

Consider the following entry class:

public class Foo implements net.jini.core.entry.Entry {
    public Bar baz; 
} 

public class Bar {
    int quux; 
    boolean zot; 
} 

A visual search tool is going to have a difficult time rendering the value of an instance of class Bar in a manner that is comprehensible to humans. Accordingly, to avoid such situations, entry class implementors should use the following guidelines when designing a class that is to act as a value for an attribute:

• Provide a property editor class of the appropriate type, as described in Section 9.2 of the JavaBeans Specification.
  
  
• Extend the java.awt.Component class; this allows a value to be represented by a JavaBeans component or some other “active” object.
  
  
• Provide either a non-default implementation of the Object.toString method or inherit directly or indirectly from a class that does so (since the default implementation of Object.toString is not useful).
  
  

One of the above guidelines should be followed for all attribute value classes. Authors of entry classes should assume that any attribute value that does not satisfy one of these guidelines will be ignored by some or all user interfaces.