<Beans Dev> Customizer question
Sergey Malenkov
Sergey.Malenkov at Sun.COM
Mon Dec 10 10:25:18 PST 2007
> 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
More information about the beans-dev
mailing list