Nabble - OpenJDK JavaBeans API Development

Approved: 6899147: java.beans.MetaData should not require JDBC to be present

2009-11-10T01:07:48Z

Hi Alan,

The fix looks good for me.
I approve.

Thanks,
SAM

Alan Bateman wrote:

> Sergey,
>
> As we discussed today, the persistent delegate for java.sql.Timestamp in
> java.beans.Metadata creates an undesirable dependency on JDBC. I'd like
> to change this to use reflection so as to eliminate the static
> dependency. This doesn't change anything at runtime in that this
> persistent delegate will only be loaded if the type is a Timestamp. I've
> put the webrev with the change here:
> http://cr.openjdk.java.net/~alanb/6899147/webrev.00/
>
> For testing, I've run the tests in test/java/beans/XMLEncoder - the
> java_sql_Timestamp.java test in particular, provides good coverage.
>
> Thanks,
>
> -Alan.
>

6899147: java.beans.MetaData should not require JDBC to be present

2009-11-09T06:37:48Z

Sergey,

As we discussed today, the persistent delegate for java.sql.Timestamp in
java.beans.Metadata creates an undesirable dependency on JDBC. I'd like
to change this to use reflection so as to eliminate the static
dependency. This doesn't change anything at runtime in that this
persistent delegate will only be loaded if the type is a Timestamp. I've
put the webrev with the change here:
http://cr.openjdk.java.net/~alanb/6899147/webrev.00/

For testing, I've run the tests in test/java/beans/XMLEncoder - the
java_sql_Timestamp.java test in particular, provides good coverage.

Thanks,

-Alan.

FREE Online Test at www.yfrindia.com

2008-09-03T12:20:33Z

http://www.yfrindia.com/
Take FREE online TEST, read FREE articles, download FREE presentation, use FREE source code, useful links, competition updates, free ONLINE TEST TESTS,
http://www.yfrindia.com/resources/Tests
free APTITUDE TEST, English Test, Computer Test, Mechanical Test, Electronics Test, Electrical Test, GATE preparation, CAT preparation, Job preparation, resume.
http://www.yfrindia.com/

FREE Online Test at www.yfrindia.com

2008-09-03T12:15:46Z

[PATCH] Fix compilation problem

2008-04-03T01:38:54Z

Hi,

I posted this some time ago, but I think it may have been forgotten.
This fixes a small problem in MetaData, which can't be compiled
using the Eclipse compiler. Infact, the code is not valid Java and is
only accepted by javac due to a bug in javac:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400189

It would be nice to have this patch integrated.

Cheers, Roman

--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt

[patch.txt]

diff -r 37a05a11f281 -r 2b6c2ce8cd88 src/share/classes/java/beans/MetaData.java --- a/src/share/classes/java/beans/MetaData.java Sat Dec 01 00:00:00 2007 +0000 +++ b/src/share/classes/java/beans/MetaData.java Tue Dec 18 15:30:58 2007 +0100 @@ -1563,7 +1563,7 @@ class MetaData { return names; } - private static String[] getAnnotationValue(Constructor constructor) { + private static String[] getAnnotationValue(Constructor<?> constructor) { ConstructorProperties annotation = constructor.getAnnotation(ConstructorProperties.class); return (annotation != null) ? annotation.value()

Re: jmx-dev

2007-12-19T09:34:16Z

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@...>
>> Date:
>> Tue, 18 Dec 2007 15:32:06 +0100
>> To:
>> Core-Libs-Dev <core-libs-dev@...>
>>
>> To:
>> Core-Libs-Dev <core-libs-dev@...>
>>
>>
>> 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
>>
>>

Re: jmx-dev

2007-12-18T10:09:16Z

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(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@...

Date:
Tue, 18 Dec 2007 15:32:06 +0100

To:
Core-Libs-Dev core-libs-dev@...

To:
Core-Libs-Dev core-libs-dev@...
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

  

2007-12-18T06:37:01Z

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

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

--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt

[openjdk-compile.patch]

# HG changeset patch # User Roman Kennke <kennke@...> # Date 1197988258 -3600 # Node ID 2b6c2ce8cd88445d9e3ea709069bf26d53039223 # Parent 37a05a11f281b4d238e2f9e7ebb67c63f64d0e77 Fix compiler problem. diff -r 37a05a11f281 -r 2b6c2ce8cd88 src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java --- a/src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java Sat Dec 01 00:00:00 2007 +0000 +++ b/src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java Tue Dec 18 15:30:58 2007 +0100 @@ -1152,7 +1152,7 @@ public abstract class OpenConverter { // Also remember the set of properties in that constructor // so we can test unambiguity. Set<BitSet> getterIndexSets = newSet(); - for (Constructor constr : annotatedConstrList) { + for (Constructor<?> constr : annotatedConstrList) { String[] propertyNames = constr.getAnnotation(propertyNamesClass).value(); diff -r 37a05a11f281 -r 2b6c2ce8cd88 src/share/classes/java/beans/MetaData.java --- a/src/share/classes/java/beans/MetaData.java Sat Dec 01 00:00:00 2007 +0000 +++ b/src/share/classes/java/beans/MetaData.java Tue Dec 18 15:30:58 2007 +0100 @@ -1563,7 +1563,7 @@ class MetaData { return names; } - private static String[] getAnnotationValue(Constructor constructor) { + private static String[] getAnnotationValue(Constructor<?> constructor) { ConstructorProperties annotation = constructor.getAnnotation(ConstructorProperties.class); return (annotation != null) ? annotation.value()

Re: Customizer question

2007-12-10T10:25:18Z

> 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

Re: Customizer question

2007-12-10T10:25:11Z

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@...
> <mailto:Sergey.Malenkov@...>> 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

Re: Customizer question

2007-12-10T07:39:21Z

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

Re: Customizer question

2007-12-10T06:42:09Z

On Dec 10, 2007 6:29 AM, Sergey Malenkov <Sergey.Malenkov@...> 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:

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

Re: Customizer question

2007-12-10T03:29:51Z

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@...
> <mailto:Sergey.Malenkov@...>> 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@...
> <mailto:java-beans@...>
> > <mailto:java-beans@... <mailto:java-beans@...>>
> 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

Re: Customizer question

2007-12-07T10:33:49Z

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.

If the Customizer is null, throw an appropriate Exception.
If the Customizer is a Window, pack() it and show() it directly. End.
(TODO: handle Applet case)
If the Customizer is a JComponent and we haven't handled it in the steps above:

If the Customizer is a JInternalFrame and the tool is launching it from "within" a JDesktopPane, pack() and show() it directly. End.
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.
If the Customizer has an " applyChanges" Action in its ActionMap, or an applyChangesAction JavaBeans property:

Create an Action that will close the Window (call it the Close Action).
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.
Create a JButton wired to the applyChanges Action (the Apply button).
Create a JButton that fires the Apply Action and then the Close Action . Call this button the OK button.
Create an OK/Cancel/Apply button bar with the JButtons created above.
Add the Customizer to the BorderLayout.CENTER of a new JPanel, and the button bar to that panel's BorderLayout.SOUTH.
Add the JPanel to the tool-supplied Window, pack() it, and show() it. End.

Since the Customizer is either a non- Window, non-JComponent Component, or a JComponent that did not get handled in step 4:

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@...> 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@...
> <mailto:java-beans@...> 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

Re: Customizer question

2007-12-07T06:51:22Z

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@...
> <mailto:java-beans@...> 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

Re: Customizer question

2007-11-29T08:11:42Z

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

Customizer question

2007-11-29T08:06:56Z

Hello; I hope this is the right place to ask this question. I originally tried to ask it of the java-beans@... email address--the address listed in the Java Beans specification 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 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