Would it be feasible to simply remove CustomizeBeanAction and permit the same things to be accomplished in a more data-driven way? Is this desirable for the UI or not?

Suggest:

- remove CustomizeBeanAction

- for SerDataNode, add sheets to its sheet set for Bean Properties (& Bean Expert Properties, maybe). If any of these are changed, reserialize changed version. (Is this noticeably slow? Maybe wait a f
ew seconds to batch up changes, and then serialize them all at once.) Also make sure these properties are tied to the Bean as obtained from InstanceCookie--i.e. hold a single instance associated with
the DO with a weak reference, and use BeanNode.computeProperties to get the properties so they are tied to that instance. Also like BeanNode, if the Bean provides a customizer, make that the customize
r for the node.

- add an action (service action, or just private to SerDataNode), something like DisplayInstanceAction--a CookieAction sensitive to InstanceCookie, which checks whether the instance class is a subclas
s of component, and if so displays the instance as a component (or window).

- make ClassDataObject and JavaDataObject, if they refer to a JavaBean class, provide an InstanceCookie which creates a fresh instance of the class. This will make it possible to copy them and then pa
ste them into a folder with DataFolder.SerializePaste (if the class is also serializable).

Now the effect of CustomizeBeanAction can be gotten by:

1. If starting with a class, copy it and ser-paste it somewhere.


2. Go to the ser data node. If you wish to see live results, first select DisplayInstanceAction to see the example as you work on it.

3. Flip to the sheets containing the Bean properties, and start changing them. The displayed instance will update as you do. In a few moments your changes will be committed to disk with no further act
ion.

4. If the node-customizer button is lit up, click it and customize the Bean that way. The displayed instance can still be