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