> 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
