From Sergey.Malenkov at Sun.COM  Fri Dec  7 06:51:22 2007
From: Sergey.Malenkov at Sun.COM (Sergey Malenkov)
Date: Fri, 07 Dec 2007 17:51:22 +0300
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
Message-ID: <47595DEA.60304@sun.com>

Hi Laird,

 > 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.)

This behavior is not specified, but I think customizers should not 
provide own buttons. The external tool can provide common dialog with 
button bar that supports cancelling, or dialog with bar for direct 
editing, or put them onto special panel. It depends on the tool and if 
we provide the customizer with button bar the tool can't use such 
customizer properly.


 > 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...)?

There are no any plans. The tool should decide how to edit properties. 
The tool should provide workarounds for necessary behavior.


 > 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?

Another kind is a JInternalFrame. It is hard to decide how to show such 
components. So the tool should provide own top-level components that use 
the customizer or property editor. We should not restrict the tool.

Thanks,
SAM


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 
> <mailto: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 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



From ljnelson at gmail.com  Fri Dec  7 10:33:49 2007
From: ljnelson at gmail.com (Laird Nelson)
Date: Fri, 7 Dec 2007 13:33:49 -0500
Subject: <Beans Dev> Customizer question
In-Reply-To: <47595DEA.60304@sun.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
Message-ID: <2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>

Thanks so much for your answers.  For the record I agree with you that
Customizers
should not provide their own buttons, but many problems do result from this
(that could easily be solved with a couple of backwards-compatible
specification clarifications).

For example:

   - If a Customizer does not provide its own buttons, then who would
   add, for example, an "Apply" button (whose action is supposed to commit the
   edits made in the window so far)?  How would the tool, if it supplies the
   button, know how to hook this up in an appropriate way to a Customizer
   ?
   - The example given in the specification says that wizards are good
   examples of Customizers.  But what does a buttonless wizard look
   like?  Are wizards actually not good examples of Customizers?  If not,
   then why did the specification say they are?  This example is why I said
   that I suspected that someone had some thoughts in mind on these issues
   (Graham Hamilton?) and just never wrote them down.
   - It sounds like what you are saying is that the contract really is
   that a Customizer/custom editor should be a *non-Window* Component
subclass.
   Is that correct?  Should the specification be amended to clarify this?
   - You say that the tool is responsible for editing properties.
   Suppose as a tool author I want my tool to provide the ability to batch up
   and defer edits and then apply them, when the user requests it, to
the Object
   that was set on the Customizer.  How would I accomplish this in a
   user-friendly way without my Customizer providing buttons, or without
   my Customizer indicating in a specification-guided way how the tool
   should apply buttons?

For what it's worth (almost assuredly nothing) I would prefer a
backwards-compatible way to allow a Customizer component to indicate that,
effectively, it wishes to function as the contentPane (or sole occupant of
the contentPane) of a Window, or not, and if it does not, then I would like
a specification-defined way for that Customizer to indicate that it has
certain Actions that should be wired up to a tool-supplied button bar.  I
propose a solution below.

I've written all my Customizer-supporting tools to follow the following
algorithm (in the case of what the spec refers to as "popping up" in a
Window, as opposed to the "embedding" case) because I believe that the
specification is very deficient in this area (I have another algorithm for
the embedded case).  Also, I use the term Customizer, but I also mean by it
the custom editors returned by PropertyEditors.

   1. If the Customizer is null, throw an appropriate Exception.
   2. If the Customizer is a Window, pack() it and show() it directly.
   End.
   3. (TODO: handle Applet case)
   4. If the Customizer is a JComponent and we haven't handled it in the
   steps above:
      1. If the Customizer is a JInternalFrame and the tool is
      launching it from "within" a JDesktopPane, pack() and show() it
      directly.  End.
      2. If the Customizer has indicated in some way (currently via a boolean
      client property "contentPane") that it wishes to be the sole
      citizen (as much as possible) of a Window, then add it to a new
      tool-supplied Window, pack() it, and show() it.  End.
      3. If the Customizer has an "applyChanges" Action in its
      ActionMap, or an applyChangesAction JavaBeans property:
         1. Create an Action that will close the Window (call it
         the Close Action).
         2. See if the Customizer has a "cancel" Action.  If it
         does, create a JButton (the Cancel button) that fires that
         Action, then the Close Action.  If it does not, create a JButton
         wired to the Close Action.
         3. Create a JButton wired to the applyChanges Action (the
         Apply button).
         4. Create a JButton that fires the Apply Action and then
         the Close Action.  Call this button the OK button.
         5. Create an OK/Cancel/Apply button bar with the JButtons created
         above.
         6. Add the Customizer to the BorderLayout.CENTER of a new
         JPanel, and the button bar to that panel's
         BorderLayout.SOUTH.
         7. Add the JPanel to the tool-supplied Window, pack() it,
         and show() it.  End.
         5. Since the Customizer is either a non-Window, non-
   JComponent Component, or a JComponent that did not get handled in step
   4:
      1. All we can do is add() it to the tool-supplied Window, pack()it and
      show() it.  End.

Thanks,
Laird

On Dec 7, 2007 9:51 AM, Sergey Malenkov <Sergey.Malenkov at sun.com> wrote:

> Hi Laird,
>
>  > 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.)
>
> This behavior is not specified, but I think customizers should not
> provide own buttons. The external tool can provide common dialog with
> button bar that supports cancelling, or dialog with bar for direct
> editing, or put them onto special panel. It depends on the tool and if
> we provide the customizer with button bar the tool can't use such
> customizer properly.
>
>
>  > 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...)?
>
> There are no any plans. The tool should decide how to edit properties.
> The tool should provide workarounds for necessary behavior.
>
>
>  > 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?
>
> Another kind is a JInternalFrame. It is hard to decide how to show such
> components. So the tool should provide own top-level components that use
> the customizer or property editor. We should not restrict the tool.
>
> Thanks,
> SAM
>
>
> 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
> > <mailto: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 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/20071207/deb07629/attachment.html 

From Sergey.Malenkov at Sun.COM  Mon Dec 10 03:29:51 2007
From: Sergey.Malenkov at Sun.COM (Sergey Malenkov)
Date: Mon, 10 Dec 2007 14:29:51 +0300
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
	<2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
Message-ID: <475D232F.1020106@sun.com>

Hi Laird,

The JavaBeans specification says that the property editor should not 
directly change the property of the object (section 9.2.4). So it is not 
a problem in the correct implementation.


 > If a Customizer does not provide its own buttons, then who would
 > add, for example, an "Apply" button (whose action is supposed to
 > commit the edits made in the window so far)?

The tool that adds the customizer into separate dialog window.
I think it should be a part of a tool's framework.


 > How would the tool, if it supplies the button, know how to hook
 > this up in an appropriate way to a Customizer?

The tool creates a copy of the bean and allows editing.
To apply changes the new value of the property
should be set from the bean's copy.


 > The example given in the specification says that wizards are good
 > examples of Customizers.  But what does a buttonless wizard look
 > like?  Are wizards actually not good examples of Customizers?

It is a good example. The wizard should contain the customizer component
to edit a copy of some bean and the buttons to apply or cancel changes.
Values of the bean should be set when apply button is pressed.


 > It sounds like what you are saying is that the contract really is
 > that a Customizer/custom editor should be a /non- Window/
 > Component subclass.  Is that correct?  Should the specification be
 > amended to clarify this?

Specification says that the customizer (or property editor component)
will be added into property sheet panel or dialog window.
But our window framework does not allow to add window into container:
The IllegalArgumentException is thrown.
So the customizer should not extend the Window class and subclasses.


 > You say that the tool is responsible for editing properties.

Sure.


 > Suppose as a tool author I want my tool to provide the ability to
 > batch up and defer edits and then apply them, when the user
 > requests it, to the Object that was set on the Customizer.
 > How would I accomplish this in a user-friendly way without my
 > Customizer providing buttons, or without my Customizer indicating
 > in a specification-guided way how the tool should apply buttons?

Provide a copy of the bean to edit.
The specification does not recommend direct changes.
See details in the section 9.2.4.


I don't think that suggested algorithm should be specified,
because it is not backward compatible.
If some old tool like NetBeans get the Window subclass
it will be broken, because unexpected exception is thrown.


Thanks,
SAM

Laird Nelson wrote:
> Thanks so much for your answers.  For the record I agree with you that 
> Customizers should not provide their own buttons, but many problems do 
> result from this (that could easily be solved with a couple of 
> backwards-compatible specification clarifications).
> 
> For example:
> 
>     * If a Customizer does not provide its own buttons, then who would
>       add, for example, an "Apply" button (whose action is supposed to
>       commit the edits made in the window so far)?  How would the tool,
>       if it supplies the button, know how to hook this up in an
>       appropriate way to a Customizer?
>     * The example given in the specification says that wizards are good
>       examples of Customizer s.  But what does a buttonless wizard look
>       like?  Are wizards actually not good examples of Customizers?  If
>       not, then why did the specification say they are?  This example is
>       why I said that I suspected that someone had some thoughts in mind
>       on these issues (Graham Hamilton?) and just never wrote them down.
>     * It sounds like what you are saying is that the contract really is
>       that a Customizer/custom editor should be a /non- Window/
>       Component subclass.  Is that correct?  Should the specification be
>       amended to clarify this?
>     * You say that the tool is responsible for editing properties. 
>       Suppose as a tool author I want my tool to provide the ability to
>       batch up and defer edits and then apply them, when the user
>       requests it, to the Object that was set on the Customizer.  How
>       would I accomplish this in a user-friendly way without my
>       Customizer providing buttons, or without my Customizer indicating
>       in a specification-guided way how the tool should apply buttons?
> 
> For what it's worth (almost assuredly nothing) I would prefer a 
> backwards-compatible way to allow a Customizer component to indicate 
> that, effectively, it wishes to function as the contentPane (or sole 
> occupant of the contentPane) of a Window, or not, and if it does not, 
> then I would like a specification-defined way for that Customizer to 
> indicate that it has certain Actions that should be wired up to a 
> tool-supplied button bar.  I propose a solution below.
> 
> I've written all my Customizer-supporting tools to follow the following 
> algorithm (in the case of what the spec refers to as "popping up" in a 
> Window, as opposed to the "embedding" case) because I believe that the 
> specification is very deficient in this area (I have another algorithm 
> for the embedded case).  Also, I use the term Customizer, but I also 
> mean by it the custom editors returned by PropertyEditors.
> 
>    1. If the Customizer is null, throw an appropriate Exception.
>    2. If the Customizer is a Window, pack() it and show() it directly.  End.
>    3. (TODO: handle Applet case)
>    4. If the Customizer is a JComponent and we haven't handled it in the
>       steps above:
>          1. If the Customizer is a JInternalFrame and the tool is
>             launching it from "within" a JDesktopPane, pack() and show()
>             it directly.  End.
>          2. If the Customizer has indicated in some way (currently via a
>             boolean client property "contentPane") that it wishes to be
>             the sole citizen (as much as possible) of a Window, then add
>             it to a new tool-supplied Window, pack() it, and show() it. 
>             End.
>          3. If the Customizer has an " applyChanges" Action in its
>             ActionMap, or an applyChangesAction JavaBeans property:
>                1. Create an Action that will close the Window (call it
>                   the Close Action).
>                2. See if the Customizer has a "cancel " Action.  If it
>                   does, create a JButton (the Cancel button) that fires
>                   that Action, then the Close Action.  If it does not,
>                   create a JButton wired to the Close Action.
>                3. Create a JButton wired to the applyChanges Action (the
>                   Apply button).
>                4. Create a JButton that fires the Apply Action and then
>                   the Close Action .  Call this button the OK button.
>                5. Create an OK/Cancel/Apply button bar with the JButtons
>                   created above.
>                6. Add the Customizer to the BorderLayout.CENTER of a new
>                   JPanel, and the button bar to that panel's
>                   BorderLayout.SOUTH.
>                7. Add the JPanel to the tool-supplied Window, pack() it,
>                   and show() it.  End.
>    5. Since the Customizer is either a non- Window, non-JComponent
>       Component, or a JComponent that did not get handled in step 4:
>          1. All we can do is add() it to the tool-supplied Window ,
>             pack() it and show() it.  End.
> 
> Thanks,
> Laird
> 
> On Dec 7, 2007 9:51 AM, Sergey Malenkov < Sergey.Malenkov at sun.com 
> <mailto:Sergey.Malenkov at sun.com>> wrote:
> 
>     Hi Laird,
> 
>      > 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.)
> 
>     This behavior is not specified, but I think customizers should not
>     provide own buttons. The external tool can provide common dialog with
>     button bar that supports cancelling, or dialog with bar for direct
>     editing, or put them onto special panel. It depends on the tool and if
>     we provide the customizer with button bar the tool can't use such
>     customizer properly.
> 
> 
>      > 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...)?
> 
>     There are no any plans. The tool should decide how to edit properties.
>     The tool should provide workarounds for necessary behavior.
> 
> 
>      > 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?
> 
>     Another kind is a JInternalFrame. It is hard to decide how to show such
>     components. So the tool should provide own top-level components that use
>     the customizer or property editor. We should not restrict the tool.
> 
>     Thanks,
>     SAM
> 
> 
>     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
>     <mailto:java-beans at java.sun.com>
>      > <mailto:java-beans at java.sun.com <mailto: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
>     <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
>     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



From ljnelson at gmail.com  Mon Dec 10 06:42:09 2007
From: ljnelson at gmail.com (Laird Nelson)
Date: Mon, 10 Dec 2007 09:42:09 -0500
Subject: <Beans Dev> Customizer question
In-Reply-To: <475D232F.1020106@sun.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
	<2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
	<475D232F.1020106@sun.com>
Message-ID: <2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>

On Dec 10, 2007 6:29 AM, Sergey Malenkov <Sergey.Malenkov at sun.com> wrote:

> The JavaBeans specification says that the property editor should not
> directly change the property of the object (section 9.2.4). So it is not
> a problem in the correct implementation.


I'm talking about Customizers, not PropertyEditors.  Customizers have no
requirement to work on a copy of the bean.  Section 9.2 and following deal
with PropertyEditors; section 9.3 and following deal with Customizers.

 > If a Customizer does not provide its own buttons, then who would
>  > add, for example, an "Apply" button (whose action is supposed to
>  > commit the edits made in the window so far)?
>
> The tool that adds the customizer into separate dialog window.
> I think it should be a part of a tool's framework.


What?!  Really?  Wow.  Could you tell me which buttons, therefore, a tool is
guaranteed--and required--to provide?  Is "Apply" one of them?  Is it
localized?  What does it do?  How does it do it?  Could you give me an
example of a specification-compliant tool that provides an "Apply" button
when it launches a Customizer?  What about Next and Previous buttons?  How
on earth does the tool know what my Customizer is going to do?

Remember, we're talking about Customizers, not PropertyEditors!


>  > How would the tool, if it supplies the button, know how to hook
>  > this up in an appropriate way to a Customizer?
>
> The tool creates a copy of the bean and allows editing.


Oops; you are talking about PropertyEditors.  There is no such requirement
for Customizers (only for PropertyEditors).  Please reference the area of
the specification where you believe that Customizers must work on a copy of
the bean--I couldn't find such a reference.

To apply changes the new value of the property
> should be set from the bean's copy.


No, there is no requirement for a Customizer to work on a copy of a bean
that I'm aware of.

What I'm really trying to figure out is that the specification says:

The customizer has
*complete discretion how it chooses to represent itself*, and may redraw its
appearance as the
user navigates/moves through different stages of customization.

...but you say:

*I think customizers should not
provide own buttons*. The external tool can provide common dialog with
button bar that supports cancelling, or dialog with bar for direct
editing

With respect, I don't see how you can reconcile your thought here
("customizers should not provide own buttons") with the (fairly explicit)
statement in the specification ("The customizer has complete discretion how
it chooses to represent itself").

(But suppose you're right, which I am certain you are not :-), and the
specification really meant to say that the tool may be relied upon to supply
certain buttons.  Here are my questions that would follow from this
interpretation:

   - Which buttons will the tool supply?  Why aren't they in the
   specification?
   - What will they do?
   - Will they be localized?
   - How will my Customizer know when one button has been pressed instead
   of another?
   - Will that button set be the same from tool to tool?

I don't think this is what the specification intended at all.)

 > The example given in the specification says that wizards are good
>  > examples of Customizers.  But what does a buttonless wizard look
>  > like?  Are wizards actually not good examples of Customizers?
>
> It is a good example. The wizard should contain the customizer component
> to edit a copy of some bean and the buttons to apply or cancel changes.


This sounds to me like you think "the wizard" is something that the
*tool *supplies
to "contain the customizer component to edit a copy of some bean", but of
course (a) the wizard as mentioned in the specification is supplied entirely
by the component writer, not the tool and (b) Customizers do not have to be
supplied with copies of beans.

The specification says this:

For example, we would like to allow *component writers to provide
customization "wizards"* that guide users through the different steps of
customizing a bean,
rather than simply facing them with property sheet choices.

That tells me unequivocally that a wizard is something that a component
writer supplies.  And since the specification also says this:

The customizer has
*complete discretion how it chooses to represent itself*, and may redraw its
appearance as the
user navigates/moves through different stages of customization.

...then it simply follows that a "customization 'wizard'" has "complete
discretion how it chooses to represent itself", i.e. that it supplies its
own buttons.

But *you're* saying that Customizers must not provide their own buttons?


> So the customizer should not extend the Window class and subclasses.
>

Thanks; that is helpful.  Please consider amending the specification to
explicitly spell this out.


>  > Suppose as a tool author I want my tool to provide the ability to
>  > batch up and defer edits and then apply them, when the user
>  > requests it, to the Object that was set on the Customizer.
>  > How would I accomplish this in a user-friendly way without my
>  > Customizer providing buttons, or without my Customizer indicating
>  > in a specification-guided way how the tool should apply buttons?
>
> Provide a copy of the bean to edit.
> The specification does not recommend direct changes.
> See details in the section 9.2.4.


Section 9.2.4 deals with PropertyEditors, not Customizers.  I'm aware of the
requirement for PropertyEditors that you need to edit a copy.  There is no
such requirement for Customizers.


> I don't think that suggested algorithm should be specified,
> because it is not backward compatible.
>

Which part?  I see from reading ahead you mean the "if the customizer is a
Window subclass" part--do you mean any other part?


> If some old tool like NetBeans get the Window subclass
> it will be broken, because unexpected exception is thrown.
>

Sure; thanks.

So, my questions still stand:

   - If you're right, and Customizers must not supply their own buttons,
   what buttons will a specification-compliant tool supply instead when that
   tool launches a component-writer-supplied Customizer?
   - If the tool must supply certain buttons (as you state (and I think
   you're quite wrong :-))), why are they not spelled out in the
   specification, if that is indeed the specification's intention?  Could you
   provide a list of such buttons, and indicate which are required and which
   are optional?

Thanks for the discussion,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071210/e2bb6cba/attachment.html 

From ljnelson at gmail.com  Mon Dec 10 07:39:21 2007
From: ljnelson at gmail.com (Laird Nelson)
Date: Mon, 10 Dec 2007 10:39:21 -0500
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
	<2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
	<475D232F.1020106@sun.com>
	<2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>
Message-ID: <2c0ebf0c0712100739x78e6152ax34e8b58d61d9b58@mail.gmail.com>

I have been thinking about this more, and here is as concise a summary as I
can present, with quotes from the specification.  The subject of this
summary is Customizers, not PropertyEditors.

The specification says:

For example, we would like to allow component writers to provide
customization "wizards" that guide users through the different steps of
customizing a bean, rather than simply facing them with property sheet
choices.  We therefore allow each Java Bean to be accompanied by a
customizer class that controls the customization of the bean. This
customizer class should be an AWT component that can be run to customize a
target bean. It can provide ***whatever GUI behaviour it wishes*** to
control the customization of the target bean.

And:

***Normally*** each Customizer ***will be run in a separate AWT dialog
window***. The customizer ***has complete discretion how it chooses to
represent itself***, and may redraw its appearance as the user
navigates/moves through different stages of customization.

And then on page 87 it says (additionally):

A customizer class provides a complete custom GUI for customizing a target
Java Bean.  Each customizer should inherit from the java.awt.Component class
so it can be instantiated inside an AWT dialog ***or panel***.

So a Customizer is a non-Window Component that "provides a complete custom
GUI for customizing a target Java Bean", may perform "whatever GUI behaviour
it wishes", "has complete discretion how it chooses to represent itself", is
"normally...run in a separate...window", but may also be instantiated
"inside an AWT...panel".

That *sounds* to me like the specification wants the tool to provide the
window, add the Customizer to it, and that's it (i.e. the customizer is in
charge of closing the window, providing any buttons and other widgets to do
its job, etc.).  But because there's that little bit about
instantiating a Customizer
"inside an AWT dialog ***OR PANEL***", suddenly things get more
complicated.  If my Customizer is embedded inside a panel alongside, say,
another customizer that is embedded inside the same panel, then it would be
*nice* not to, say, duplicate button bars.

And finally, you, as the specification maintainer, are claiming that the
tool should provide all buttons, not the Customizer (which I see no evidence
for in the specification--so now I'm *really* confused).

Does that help you understand why I'm writing for specification
clarification?

(Also, is anyone else on this list?  I don't mean to monopolize it.)

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071210/93306bdb/attachment.html 

From Sergey.Malenkov at Sun.COM  Mon Dec 10 10:25:11 2007
From: Sergey.Malenkov at Sun.COM (Sergey Malenkov)
Date: Mon, 10 Dec 2007 21:25:11 +0300
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
	<2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
	<475D232F.1020106@sun.com>
	<2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>
Message-ID: <475D8487.4020707@sun.com>

Hi Laird,

 > I'm talking about Customizers, not PropertyEditors.

You said "I use the term Customizer, but I also mean by it the custom 
editors returned by PropertyEditors". Property editor was intended for 
*one* property of the bean, but customizer was intended for *all* 
properties of the bean. It is the difference. That is why the customizer 
does not implement property editor interface. It is too hard to 
implement methods like getAsText, paintValue and others.

 >> The tool that adds the customizer into separate dialog window.
 >> I think it should be a part of a tool's framework.
 > What?!  Really?  Wow...

8)

 > Could you tell me which buttons, therefore, a
 > tool is guaranteed--and required--to provide?

It depends on a tool.

 > Is "Apply" one of them?

You can call it "OK".

 > Is it localized?

It depends on a tool.

 > What does it do?

It sets all properties of the bean.

 > How does it do it?

It copies them from the bean's copy.

 > Could you give me an example of a specification-compliant tool
 > that provides an "Apply" button when it launches a Customizer?

No. You should contact with NetBeans team for details.

 > What about Next and Previous buttons?

Why you need these buttons?
For customizer-specific behavior?
So they should be inside the customizer.

Do you want to mix Ok/Cancel buttons with Next/Previous ones?
It is impossible in current specification.

 > How on earth does the tool know what my Customizer is going to do?

The customizer changes the state of the object
that is set with the setObject method.

 > Please reference the area of the specification where you believe
 > that Customizers must work on a copy of the bean.

I agreed. It is not specified.
But it is specified for property editors.

 > With respect, I don't see how you can reconcile your thought here
 > ("customizers should not provide own buttons") with the (fairly
 > explicit) statement in the specification ("The customizer has complete
 > discretion how it chooses to represent itself").

I mean the Ok/Cancel buttons.
You can add Next/Previous button into the customizer.

 > Which buttons will the tool supply?

It depends on a tool.
The customizer can be added into the panel to direct editing.
So the Ok/Cancel buttons are not necessary.

 > Why aren't they in the specification?

Because it is a tool's behaviour.

 > What will they do?

It depends on a tool.

 > Will they be localized?

It depends on a tool.

 > How will my Customizer know when one button has been pressed instead 
of another?

The customizer should not know about it.
It should change the state of the object
that is set with the setObject method.
Nothing else.

 > Will that button set be the same from tool to tool?

No.


 > If you're right, and Customizers must not supply their own buttons,
 > what buttons will a specification-compliant tool supply instead
 > when that tool launches a component-writer-supplied Customizer?

The specification says nothing about buttons.

 > If the tool must supply certain buttons (as you state (and I think
 > you're quite wrong :-))), why are they not spelled out in the
 > specification, if that is indeed the specification's intention?

The tool should decide how to use the customizer.

 > Could you provide a list of such buttons, and indicate
 > which are required and which are optional?

No. It depends on a tool.


Stay tuned,
SAM


Laird Nelson wrote:
> On Dec 10, 2007 6:29 AM, Sergey Malenkov <Sergey.Malenkov at sun.com 
> <mailto:Sergey.Malenkov at sun.com>> wrote:
> 
>     The JavaBeans specification says that the property editor should not
>     directly change the property of the object (section 9.2.4). So it is not
>     a problem in the correct implementation.
> 
> 
> I'm talking about Customizers, not PropertyEditors.  Customizers have no 
> requirement to work on a copy of the bean.  Section 9.2 and following 
> deal with PropertyEditors; section 9.3 and following deal with Customizers.
> 
>      > If a Customizer does not provide its own buttons, then who would
>      > add, for example, an "Apply" button (whose action is supposed to
>      > commit the edits made in the window so far)?
> 
>     The tool that adds the customizer into separate dialog window.
>     I think it should be a part of a tool's framework.
> 
> 
> What?!  Really?  Wow.  Could you tell me which buttons, therefore, a 
> tool is guaranteed--and required--to provide?  Is "Apply" one of them?  
> Is it localized?  What does it do?  How does it do it?  Could you give 
> me an example of a specification-compliant tool that provides an "Apply" 
> button when it launches a Customizer?  What about Next and Previous 
> buttons?  How on earth does the tool know what my Customizer is going to 
> do?
> 
> Remember, we're talking about Customizers, not PropertyEditors!
>  
> 
>      > How would the tool, if it supplies the button, know how to hook
>      > this up in an appropriate way to a Customizer?
> 
>     The tool creates a copy of the bean and allows editing. 
> 
> 
> Oops; you are talking about PropertyEditors.  There is no such 
> requirement for Customizers (only for PropertyEditors).  Please 
> reference the area of the specification where you believe that 
> Customizers must work on a copy of the bean--I couldn't find such a 
> reference.
> 
>     To apply changes the new value of the property
>     should be set from the bean's copy.
> 
> 
> No, there is no requirement for a Customizer to work on a copy of a bean 
> that I'm aware of.
> 
> What I'm really trying to figure out is that the specification says:
> 
> The customizer has
> _complete discretion how it chooses to represent itself_, and may redraw 
> its appearance as the
> user navigates/moves through different stages of customization.
> 
> ...but you say:
> 
> _I think customizers should not
> provide own buttons_. The external tool can provide common dialog with
> button bar that supports cancelling, or dialog with bar for direct
> editing
> 
> With respect, I don't see how you can reconcile your thought here 
> ("customizers should not provide own buttons") with the (fairly 
> explicit) statement in the specification ("The customizer has complete 
> discretion how it chooses to represent itself").
> 
> (But suppose you're right, which I am certain you are not :-), and the 
> specification really meant to say that the tool may be relied upon to 
> supply certain buttons.  Here are my questions that would follow from 
> this interpretation:
> 
>     * Which buttons will the tool supply?  Why aren't they in the
>       specification?
>     * What will they do?
>     * Will they be localized?
>     * How will my Customizer know when one button has been pressed
>       instead of another?
>     * Will that button set be the same from tool to tool?
> 
> I don't think this is what the specification intended at all.)
> 
>      > The example given in the specification says that wizards are good
>      > examples of Customizers.  But what does a buttonless wizard look
>      > like?  Are wizards actually not good examples of Customizers?
> 
>     It is a good example. The wizard should contain the customizer component
>     to edit a copy of some bean and the buttons to apply or cancel changes.
> 
> 
> This sounds to me like you think "the wizard" is something that the 
> /tool /supplies to "contain the customizer component to edit a copy of 
> some bean", but of course (a) the wizard as mentioned in the 
> specification is supplied entirely by the component writer, not the tool 
> and (b) Customizers do not have to be supplied with copies of beans.
> 
> The specification says this:
> 
> For example, we would like to allow _component writers to provide
> customization "wizards"_ that guide users through the different steps of 
> customizing a bean,
> rather than simply facing them with property sheet choices.
> 
> That tells me unequivocally that a wizard is something that a component 
> writer supplies.  And since the specification also says this:
> 
> The customizer has
> _complete discretion how it chooses to represent itself_, and may redraw 
> its appearance as the
> user navigates/moves through different stages of customization.
> 
> ...then it simply follows that a "customization 'wizard'" has "complete 
> discretion how it chooses to represent itself", i.e. that it supplies 
> its own buttons.
> 
> But /you're/ saying that Customizers must not provide their own buttons?
>  
> 
>     So the customizer should not extend the Window class and subclasses.
> 
> 
> Thanks; that is helpful.  Please consider amending the specification to 
> explicitly spell this out.
>  
> 
>      > Suppose as a tool author I want my tool to provide the ability to
>      > batch up and defer edits and then apply them, when the user
>      > requests it, to the Object that was set on the Customizer.
>      > How would I accomplish this in a user-friendly way without my
>      > Customizer providing buttons, or without my Customizer indicating
>      > in a specification-guided way how the tool should apply buttons?
> 
>     Provide a copy of the bean to edit.
>     The specification does not recommend direct changes.
>     See details in the section 9.2.4.
> 
> 
> Section 9.2.4 deals with PropertyEditors, not Customizers.  I'm aware of 
> the requirement for PropertyEditors that you need to edit a copy.  There 
> is no such requirement for Customizers.
>  
> 
>     I don't think that suggested algorithm should be specified,
>     because it is not backward compatible. 
> 
> 
> Which part?  I see from reading ahead you mean the "if the customizer is 
> a Window subclass" part--do you mean any other part?
>  
> 
>     If some old tool like NetBeans get the Window subclass
>     it will be broken, because unexpected exception is thrown.
> 
> 
> Sure; thanks.
> 
> So, my questions still stand:
> 
>     * If you're right, and Customizers must not supply their own
>       buttons, what buttons will a specification-compliant tool supply
>       instead when that tool launches a component-writer-supplied
>       Customizer?
>     * If the tool must supply certain buttons (as you state (and I think
>       you're quite wrong :-))), why are they not spelled out in the
>       specification, if that is indeed the specification's intention? 
>       Could you provide a list of such buttons, and indicate which are
>       required and which are optional?
> 
> Thanks for the discussion,
> Laird



From Sergey.Malenkov at Sun.COM  Mon Dec 10 10:25:18 2007
From: Sergey.Malenkov at Sun.COM (Sergey Malenkov)
Date: Mon, 10 Dec 2007 21:25:18 +0300
Subject: <Beans Dev> Customizer question
In-Reply-To: <2c0ebf0c0712100739x78e6152ax34e8b58d61d9b58@mail.gmail.com>
References: <2c0ebf0c0711290806l18b7d0feva23f84539eb106da@mail.gmail.com>
	<47595DEA.60304@sun.com>
	<2c0ebf0c0712071033l52b732c3xa4ec91e06d028f48@mail.gmail.com>
	<475D232F.1020106@sun.com>
	<2c0ebf0c0712100642x699ae50g604a52d2ded0cc19@mail.gmail.com>
	<2c0ebf0c0712100739x78e6152ax34e8b58d61d9b58@mail.gmail.com>
Message-ID: <475D848E.8080900@sun.com>

 > That /sounds/ to me like the specification wants the tool
 > to provide the window, add the Customizer to it, and that's it
 > (i.e. the customizer is in charge of closing the window,
 > providing any buttons and other widgets to do its job, etc.).

You can do it for direct editing of the bean.

 > But because there's that little bit about
 > instantiating a Customizer "inside an AWT dialog **_OR PANEL_**",
 > suddenly things get more complicated.  If my Customizer is embedded
 > inside a panel alongside, say, another customizer that is embedded
 > inside the same panel, then it would be /nice/ not to, say, duplicate
 > button bars.

The specification says that a customizer may choose to include property 
editors, but it does not say that it can include other customizers.

 > And finally, you, as the specification maintainer,
 > are claiming that the tool should provide all buttons,
 > not the Customizer (which I see no evidence for in the specification
 > --so now I'm /really/ confused).

I agree that the specification is not obvious here,
but we can't ask the author (Graham Hamilton) because he left Sun.

 > Does that help you understand why I'm writing
 > for specification clarification?

I understood. But we should not add something that can break
existing tools because of backward compatibility.

Thanks,
SAM

Laird Nelson wrote:
> I have been thinking about this more, and here is as concise a summary 
> as I can present, with quotes from the specification.  The subject of 
> this summary is Customizers , not PropertyEditors.
> 
> The specification says:
> 
> For example, we would like to allow component writers to provide 
> customization "wizards" that guide users through the different steps of 
> customizing a bean, rather than simply facing them with property sheet 
> choices.  We therefore allow each Java Bean to be accompanied by a 
> customizer class that controls the customization of the bean. This 
> customizer class should be an AWT component that can be run to customize 
> a target bean. It can provide ** _whatever GUI behaviour it wishes_** to 
> control the customization of the target bean.
> 
> And:
> 
> **_Normally_** each Customizer **_will be run in a separate AWT dialog 
> window _**. The customizer **_has complete discretion how it chooses to 
> represent itself_**, and may redraw its appearance as the user 
> navigates/moves through different stages of customization.
> 
> And then on page 87 it says (additionally):
> 
> A customizer class provides a complete custom GUI for customizing a 
> target Java Bean.  Each customizer should inherit from the 
> java.awt.Component class so it can be instantiated inside an AWT dialog 
> ** _or panel_**.
> 
> So a Customizer is a non-Window Component that "provides a complete 
> custom GUI for customizing a target Java Bean", may perform "whatever 
> GUI behaviour it wishes", "has complete discretion how it chooses to 
> represent itself", is "normally...run in a separate...window", but may 
> also be instantiated "inside an AWT...panel".
> 
> That /sounds/ to me like the specification wants the tool to provide the 
> window, add the Customizer to it, and that's it (i.e. the customizer is 
> in charge of closing the window, providing any buttons and other widgets 
> to do its job, etc.).  But because there's that little bit about 
> instantiating a Customizer "inside an AWT dialog **_OR PANEL_**", 
> suddenly things get more complicated.  If my Customizer is embedded 
> inside a panel alongside, say, another customizer that is embedded 
> inside the same panel, then it would be /nice/ not to, say, duplicate 
> button bars.
> 
> And finally, you, as the specification maintainer, are claiming that the 
> tool should provide all buttons, not the Customizer (which I see no 
> evidence for in the specification--so now I'm /really/ confused).
> 
> Does that help you understand why I'm writing for specification 
> clarification?
> 
> (Also, is anyone else on this list?  I don't mean to monopolize it.)
> 
> Thanks,
> Laird



From Alan.Bateman at Sun.COM  Tue Dec 18 06:37:01 2007
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 18 Dec 2007 14:37:01 +0000
Subject: <Beans Dev> [Fwd: Fix compiler problem]
Message-ID: <4767DB0D.7010309@sun.com>


I don't know if the JMX  team or the JavaBeans maintainers are on the 
core-libs-dev mailing list.

-------------- next part --------------
An embedded message was scrubbed...
From: Roman Kennke <roman.kennke at aicas.com>
Subject: Fix compiler problem
Date: Tue, 18 Dec 2007 15:32:06 +0100
Size: 8249
Url: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071218/7caefa4a/attachment.nws 

From Eamonn.McManus at Sun.COM  Tue Dec 18 10:09:16 2007
From: Eamonn.McManus at Sun.COM (Eamonn McManus)
Date: Tue, 18 Dec 2007 19:09:16 +0100
Subject: <Beans Dev> jmx-dev [Fwd: Fix compiler problem]
In-Reply-To: <4767DB0D.7010309@sun.com>
References: <4767DB0D.7010309@sun.com>
Message-ID: <47680CCC.2030206@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071218/6df300fc/attachment.html 

From Sergey.Malenkov at Sun.COM  Wed Dec 19 09:34:16 2007
From: Sergey.Malenkov at Sun.COM (Sergey Malenkov)
Date: Wed, 19 Dec 2007 20:34:16 +0300
Subject: <Beans Dev> jmx-dev [Fwd: Fix compiler problem]
In-Reply-To: <47680CCC.2030206@sun.com>
References: <4767DB0D.7010309@sun.com> <47680CCC.2030206@sun.com>
Message-ID: <47695618.9090300@sun.com>

Hi,

Thank you for explanation.
I'll fix it soon.

Thanks,
SAM

Eamonn McManus wrote:
> Thanks for bringing this to our attention, Alan. Roman is right - the 
> code in question should not compile and we should change it as he 
> suggests so that it is correct.
> 
> (For people interested in the gory details, the method
> <T extends Annotation> T getAnnotation 
> <http://java.sun.com/javase/6/docs/api/java/lang/reflect/Constructor.html#getAnnotation%28java.lang.Class%29>(Class<T> 
> annotationClass)
> returns T only if it is called on a properly generic variable, such as a 
> Constructor<?> or Constructor<? extends Foo> or Constructor<E>. If it is 
> called on a plain Constructor with no type parameter, then that is a 
> "raw type", and the return type is "erased" to Annotation. So something like
> ConstructorProperties annotation = 
> constructor.getAnnotation(ConstructorProperties.class)
> should not compile if constructor is declared as Constructor rather than 
> Constructor<?> or whatever.)
> 
> ?amonn McManus   JMX Spec Lead   http://weblogs.java.net/blog/emcmanus/
> 
> 
> 
> Alan Bateman wrote:
>>
>> I don't know if the JMX  team or the JavaBeans maintainers are on the 
>> core-libs-dev mailing list.
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Fix compiler problem
>> From:
>> Roman Kennke <roman.kennke at aicas.com>
>> Date:
>> Tue, 18 Dec 2007 15:32:06 +0100
>> To:
>> Core-Libs-Dev <core-libs-dev at openjdk.java.net>
>>
>> To:
>> Core-Libs-Dev <core-libs-dev at openjdk.java.net>
>>
>>
>> When trying to compile OpenJDK with the Eclipse compiler, I noticed two
>> compiler errors related to generics. It turned out that the code there
>> is invalid and only javac (incorrectly) accepts it. See the following
>> bug reports for details:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=212147
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400189
>>
>> The attached changeset fixes the problem. Could this be included?
>>
>> /Roman
>>
>>