<Beans Dev> Customizer question

[Jeff Dinkins]

On Nov 29, 2007, at 8:06 AM, Laird Nelson wrote:

> Hello; I hope this is the right place to ask this question.  I  
> originally tried to ask it of the java-beans at java.sun.com email  
> address--the address listed in the Java Beans specification as being  
> appropriate for specification questions--but it bounced.

  Hi Laird, sorry about the bounce -- we're working on fixing that now.

  Hopefully one of the Beans engineer's can answer the below.

jeff



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071129/0d04edb1/attachment.html