<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