|
Lines 39-47
Link Here
|
| 39 |
import javax.swing.event.ChangeListener; |
39 |
import javax.swing.event.ChangeListener; |
| 40 |
|
40 |
|
| 41 |
|
41 |
|
| 42 |
/** A visual component for editing individual properties. It takes an instance of |
42 |
/** <p>PropertyPanel is a generic GUI component for displaying and editing a JavaBeans™ |
|
|
43 |
* property or any compatible getter/setter pair for which there is a property editor |
| 44 |
* available, in accordance with the JavaBeans specification. It makes it possible to |
| 45 |
* instantiate an appropriate GUI component for a property and provides the plumbing |
| 46 |
* between user interation with the gui component and calls to the getter/setter pair |
| 47 |
* to update the value.</p> |
| 48 |
* |
| 49 |
* <p>The simplest way to use PropertyPanel is by driving it from an instance of |
| 50 |
* <code>PropertySupport.Reflection</code>. To do that, simply pass the name of the |
| 51 |
* property and an object with a getter/setter pair matching that property to the |
| 52 |
* PropertySupport.Reflection's constructor, and pass the resulting instance of |
| 53 |
* PropertySupport.Reflection to the PropertyPanel constructor.</p> |
| 54 |
* |
| 55 |
* <p>A more efficient approach is to implement Node.Property or pass an existing Node.Property |
| 56 |
* object to the PropertyPanel's constructor or PropertyPanel.setProperty - thus |
| 57 |
* bypassing the use of reflection to locate the getter and setter.</p> |
| 58 |
* |
| 59 |
* <p><b>A note on uses of Node.Property and PropertyModel</b>: PropertyPanel was |
| 60 |
* originally designed to work with instances of PropertyModel, and has since been |
| 61 |
* rewritten to be driven by instances of Node.Property. The main reason for this |
| 62 |
* is simplification - there is considerable overlap between PropertyModel and |
| 63 |
* Node.Property; particularly, DefaultPropertyModel and PropertySupport.Reflection |
| 64 |
* effectively are two ways of doing exactly the same thing.</p> |
| 65 |
* |
| 66 |
* <p>Use of PropertyModel is still supported, but discouraged except under special |
| 67 |
* circumstances. The one significant difference between <code>Node.Property</code> |
| 68 |
* and PropertyModel is that PropertyModel permits listening for changes.</p> |
| 69 |
* <p>It is generally accepted that GUI components whose contents unexpectedly change |
| 70 |
* due to events beyond their control does not tend to lead to quality, usable user |
| 71 |
* interfaces. However, there are cases where a UI will, for example, contain several |
| 72 |
* components and modification to one should immediately be reflected in the other. |
| 73 |
* For such a case, use of PropertyModel is still supported. For other cases, |
| 74 |
* it makes more sense to use <code>BeanNode</code> and for the designer of the UI |
| 75 |
* to make a design choice as to how to handle (if at all) unexpected changes happening to |
| 76 |
* properties it is displaying. If all you need to do is display or edit a |
| 77 |
* property, use one of the constructors that takes a Node.Property object or |
| 78 |
* use <code>setProperty</code>. PropertyModel will be deprecated at some point |
| 79 |
* in the future, when a suitable replacement more consistent with |
| 80 |
* <code>Node.Property</code> is created.</p> |
| 81 |
* |
| 43 |
* PropertyModel and displays an editor component for it. |
82 |
* PropertyModel and displays an editor component for it. |
| 44 |
* @author Jaroslav Tulach, Petr Hamernik, Jan Jancura, David Strupl |
83 |
* @author Jaroslav Tulach, Petr Hamernik, Jan Jancura, David Strupl, Tim Boudreau |
| 45 |
*/ |
84 |
*/ |
| 46 |
public class PropertyPanel extends JComponent implements javax.accessibility.Accessible { |
85 |
public class PropertyPanel extends JComponent implements javax.accessibility.Accessible { |
| 47 |
|
86 |
|
|
Lines 607-615
Link Here
|
| 607 |
/** Get the property model associated with this property panel. Note that |
646 |
/** Get the property model associated with this property panel. Note that |
| 608 |
* while the PropertyModel usages of PropertyPanel are not yet deprecated, |
647 |
* while the PropertyModel usages of PropertyPanel are not yet deprecated, |
| 609 |
* the preferred and more efficient use of PropertyPanel is directly with |
648 |
* the preferred and more efficient use of PropertyPanel is directly with |
| 610 |
* a Node.Property instance rather than a PropertyModel. |
649 |
* a Node.Property instance rather than a PropertyModel. <p><strong><b>Note:</b> |
|
|
650 |
* This method is primarily here for backward compatibility, and the single |
| 651 |
* use case where it is truly desirable to have a GUI component which reflects |
| 652 |
* changes made by some source other than itself. If you have used one |
| 653 |
* of the constructors which takes a <code>Node.Property</code> instance |
| 654 |
* or the <code>setProperty</code> method, this method will return a |
| 655 |
* PropertyModel instance generated for the underlying Node.Property object. |
| 656 |
* In such a case, the PropertyModel instance thus obtained <u>will not |
| 657 |
* fire changes</u> due to changes made by calling <code>setValue</code> |
| 658 |
* on the <code>Node.Property</code>. For details on why this is the case, |
| 659 |
* see <a href="http://www.netbeans.org/issues/show_bug.cgi?id=37779">issue |
| 660 |
* 37779</code>.</strong> |
| 611 |
* |
661 |
* |
| 612 |
* @return Value of property model. |
662 |
* @return Either the PropertyModel set in the constructor or via <code>setModel</code>, |
|
|
663 |
* or a generated instance of PropertyModel which wraps the <code>Node.Property</code> |
| 664 |
* which was set in the constructor or via <code>setProperty</code>. |
| 613 |
*/ |
665 |
*/ |
| 614 |
public PropertyModel getModel() { |
666 |
public PropertyModel getModel() { |
| 615 |
return model; |
667 |
return model; |