Hello; I hope this is the right place to ask this question.&nbsp; I originally tried to ask it of the <a href="mailto:java-beans@java.sun.com">java-beans@java.sun.com</a> email address--the address listed in <a href="http://java.sun.com/products/javabeans/docs/spec.html">
the Java Beans specification</a> as being appropriate for specification questions--but it bounced.&nbsp; Chet Haase referred me here.<br><br>My question concerns <span style="font-family: courier new,monospace;">Customizers </span>
(which must, as well, be <span style="font-family: courier new,monospace;">Components</span>) and the intention of the specification.<br><br><a href="http://java.sun.com/products/javabeans/docs/spec.html">The specification
</a> talks about <span style="font-family: courier new,monospace;">Customizers </span>being &quot;full-fledged&quot; editors that may be embedded in a <span style="font-family: courier new,monospace;">java.awt.Panel</span>
 or somehow placed into a <span style="font-family: courier new,monospace;">java.awt.Window</span>.<br><br>It strikes me that the requirements for each of these cases are very different, but are not addressed by the specification.
<br><br>For example, suppose I have a <span style="font-family: courier new,monospace;">PersonCustomizer </span>that provides fields for first and last name.&nbsp; If I know in advance that this <span style="font-family: courier new,monospace;">
Component </span>will be &quot;embedded&quot; in a <span style="font-family: courier new,monospace;">Panel</span>, then from a UI perspective I would not want to saddle it with an Apply button, or an OK button, or, for that matter, really any button at all.
<br><br>On the other hand, if somehow I know that my <span style="font-family: courier new,monospace;">PersonCustomizer </span>will be the only citizen of a <span style="font-family: courier new,monospace;">Window</span>, I very much would like it to have a system-appropriate button bar at the bottom (OK/Apply/Cancel/Help etc.).
<br><br>In both cases my <span style="font-family: courier new,monospace;">Customizer </span>would need to know when the user wants his changes to be applied.&nbsp; Obviously if I supply my own button bar, I can accomplish this.&nbsp; But in the &quot;embedding&quot; case, I may not want to do this.&nbsp; In such a case I might want to simply provide 
<span style="font-family: courier new,monospace;">Actions </span>(if my <span style="font-family: courier new,monospace;">Customizer </span>is also a <span style="font-family: courier new,monospace;">JComponent</span>), but it may 
<i>not</i> be a <span style="font-family: courier new,monospace;">JComponent</span>.<br><br>All of this leads me to believe that the original authors of the specification (Graham Hamilton <i>et al</i>.) had something in mind that wasn&#39;t committed to the specification.
<br><br>Perhaps, for example, they had in their heads that <span style="font-family: courier new,monospace;">Customizer Components</span> would always be the sole resident of a window supplied by the container.&nbsp; Or perhaps they assumed that at the very least 
<span style="font-family: courier new,monospace;">Customizer Components</span> would always provide their own apply/cancel mechanics (so it would not be a &quot;violation&quot;, even in the embedding case, despite what the specification suggests, for a 
<span style="font-family: courier new,monospace;">Customizer </span>to be embedded into a <span style="font-family: courier new,monospace;">Panel </span>alongside other such <span style="font-family: courier new,monospace;">
Customizers </span>with its own button bar).<br><br>Now, NetBeans and if I recall correctly the old BeanBox and some other <span style="font-family: courier new,monospace;">Customizer</span>-aware containers actually do embed 
<span style="font-family: courier new,monospace;">Customizers </span>inside a <span style="font-family: courier new,monospace;">Window </span>of some kind (usually a <span style="font-family: courier new,monospace;">JDialog
</span>), but they also provide a &quot;Done&quot; button or something similar.&nbsp; That strikes me--no offense intended--as the <i>worst</i> possible move: now, even if my <span style="font-family: courier new,monospace;">Customizer 
</span>provides its own button bar to manage its commits and cancels, it looks stupid, because there&#39;s <i>another</i> button bar supplied by the container.<br><br>So:<br><ul><li>What implicit assumptions were there when the specification was written?&nbsp; What implicit unspecified contract should 
<span style="font-family: courier new,monospace;">Customizer Components </span>adhere to?&nbsp; Should they provide their own button bars in all cases (i.e. is the &quot;embedding in a panel&quot; case just silly)?&nbsp; Or should they 
<i>not</i> provide their own button bars?&nbsp; (Note: &quot;button bar&quot; here is a stand-in for any visual component that provides the user a direct ability to apply or cancel changes.)<br></li><li>What, if any, plans exist going forward to tighten this specification up a little?&nbsp; Will there be any...any...annotations or something to indicate to a container how a 
<span style="font-family: courier new,monospace;">Customizer </span>should be displayed?&nbsp; Perhaps some kind of convention (i.e. if the <span style="font-family: courier new,monospace;">Customizer </span>discovers that its parent has a 
<span style="font-family: courier new,monospace;">Component </span>named &quot;<span style="font-family: courier new,monospace;">buttonBar</span>&quot; then...)?</li><li>One kind of <span style="font-family: courier new,monospace;">
Component </span>is a <span style="font-family: courier new,monospace;">Window</span>.&nbsp; Is it understood (or not) that if the <span style="font-family: courier new,monospace;">Customizer </span>&quot;is a&quot; <span style="font-family: courier new,monospace;">
Window </span>it will not need to be embedded in any way, shape or form?</li><li>These issues can (and do) also apply to the custom editors returned by <span style="font-family: courier new,monospace;">PropertyEditors</span>
.&nbsp; Is there any reason why any solution here would not reasonably apply to those cases as well?</li></ul>Thanks for your time,<br>Laird<br>