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 [EMAIL PROTECTED] 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
