From ljnelson at gmail.com  Thu Nov 29 08:06:56 2007
From: ljnelson at gmail.com (Laird Nelson)
Date: Thu, 29 Nov 2007 11:06:56 -0500
Subject: <Beans Dev> Customizer question
Message-ID: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>

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<http://java.sun.com/products/javabeans/docs/spec.html>as
being appropriate for specification questions--but it bounced.  Chet
Haase referred me here.

My question concerns Customizers (which must, as well, be Components) and
the intention of the specification.

The specification
<http://java.sun.com/products/javabeans/docs/spec.html>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
Componentswould 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/382bb0c8/attachment.html 

From Jeff.Dinkins at Sun.COM  Thu Nov 29 08:11:42 2007
From: Jeff.Dinkins at Sun.COM (Jeff Dinkins)
Date: Thu, 29 Nov 2007 08:11:42 -0800
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
Message-ID: <9A980116-2110-4F46-B884-AC00EF97206A@sun.com>


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