<Beans Dev> Customizer question

[Sergey Malenkov]

Hi Laird,

 > I'm talking about Customizers, not PropertyEditors.

You said "I use the term Customizer, but I also mean by it the custom 
editors returned by PropertyEditors". Property editor was intended for 
*one* property of the bean, but customizer was intended for *all* 
properties of the bean. It is the difference. That is why the customizer 
does not implement property editor interface. It is too hard to 
implement methods like getAsText, paintValue and others.

 >> The tool that adds the customizer into separate dialog window.
 >> I think it should be a part of a tool's framework.
 > What?!  Really?  Wow...

8)

 > Could you tell me which buttons, therefore, a
 > tool is guaranteed--and required--to provide?

It depends on a tool.

 > Is "Apply" one of them?

You can call it "OK".

 > Is it localized?

It depends on a tool.

 > What does it do?

It sets all properties of the bean.

 > How does it do it?

It copies them from the bean's copy.

 > Could you give me an example of a specification-compliant tool
 > that provides an "Apply" button when it launches a Customizer?

No. You should contact with NetBeans team for details.

 > What about Next and Previous buttons?

Why you need these buttons?
For customizer-specific behavior?
So they should be inside the customizer.

Do you want to mix Ok/Cancel buttons with Next/Previous ones?
It is impossible in current specification.

 > How on earth does the tool know what my Customizer is going to do?

The customizer changes the state of the object
that is set with the setObject method.

 > Please reference the area of the specification where you believe
 > that Customizers must work on a copy of the bean.

I agreed. It is not specified.
But it is specified for property editors.

 > With respect, I don't see how you can reconcile your thought here
 > ("customizers should not provide own buttons") with the (fairly
 > explicit) statement in the specification ("The customizer has complete
 > discretion how it chooses to represent itself").

I mean the Ok/Cancel buttons.
You can add Next/Previous button into the customizer.

 > Which buttons will the tool supply?

It depends on a tool.
The customizer can be added into the panel to direct editing.
So the Ok/Cancel buttons are not necessary.

 > Why aren't they in the specification?

Because it is a tool's behaviour.

 > What will they do?

It depends on a tool.

 > Will they be localized?

It depends on a tool.

 > How will my Customizer know when one button has been pressed instead 
of another?

The customizer should not know about it.
It should change the state of the object
that is set with the setObject method.
Nothing else.

 > Will that button set be the same from tool to tool?

No.


 > If you're right, and Customizers must not supply their own buttons,
 > what buttons will a specification-compliant tool supply instead
 > when that tool launches a component-writer-supplied Customizer?

The specification says nothing about buttons.

 > If the tool must supply certain buttons (as you state (and I think
 > you're quite wrong :-))), why are they not spelled out in the
 > specification, if that is indeed the specification's intention?

The tool should decide how to use the customizer.

 > Could you provide a list of such buttons, and indicate
 > which are required and which are optional?

No. It depends on a tool.


Stay tuned,
SAM


Laird Nelson wrote:
> On Dec 10, 2007 6:29 AM, Sergey Malenkov <Sergey.Malenkov at sun.com 
> <mailto:Sergey.Malenkov at sun.com>> wrote:
> 
>     The JavaBeans specification says that the property editor should not
>     directly change the property of the object (section 9.2.4). So it is not
>     a problem in the correct implementation.
> 
> 
> I'm talking about Customizers, not PropertyEditors.  Customizers have no 
> requirement to work on a copy of the bean.  Section 9.2 and following 
> deal with PropertyEditors; section 9.3 and following deal with Customizers.
> 
>      > If a Customizer does not provide its own buttons, then who would
>      > add, for example, an "Apply" button (whose action is supposed to
>      > commit the edits made in the window so far)?
> 
>     The tool that adds the customizer into separate dialog window.
>     I think it should be a part of a tool's framework.
> 
> 
> What?!  Really?  Wow.  Could you tell me which buttons, therefore, a 
> tool is guaranteed--and required--to provide?  Is "Apply" one of them?  
> Is it localized?  What does it do?  How does it do it?  Could you give 
> me an example of a specification-compliant tool that provides an "Apply" 
> button when it launches a Customizer?  What about Next and Previous 
> buttons?  How on earth does the tool know what my Customizer is going to 
> do?
> 
> Remember, we're talking about Customizers, not PropertyEditors!
>  
> 
>      > How would the tool, if it supplies the button, know how to hook
>      > this up in an appropriate way to a Customizer?
> 
>     The tool creates a copy of the bean and allows editing. 
> 
> 
> Oops; you are talking about PropertyEditors.  There is no such 
> requirement for Customizers (only for PropertyEditors).  Please 
> reference the area of the specification where you believe that 
> Customizers must work on a copy of the bean--I couldn't find such a 
> reference.
> 
>     To apply changes the new value of the property
>     should be set from the bean's copy.
> 
> 
> No, there is no requirement for a Customizer to work on a copy of a bean 
> that I'm aware of.
> 
> What I'm really trying to figure out is that the specification says:
> 
> 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.
> 
> ...but you say:
> 
> _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
> 
> With respect, I don't see how you can reconcile your thought here 
> ("customizers should not provide own buttons") with the (fairly 
> explicit) statement in the specification ("The customizer has complete 
> discretion how it chooses to represent itself").
> 
> (But suppose you're right, which I am certain you are not :-), and the 
> specification really meant to say that the tool may be relied upon to 
> supply certain buttons.  Here are my questions that would follow from 
> this interpretation:
> 
>     * Which buttons will the tool supply?  Why aren't they in the
>       specification?
>     * What will they do?
>     * Will they be localized?
>     * How will my Customizer know when one button has been pressed
>       instead of another?
>     * Will that button set be the same from tool to tool?
> 
> I don't think this is what the specification intended at all.)
> 
>      > The example given in the specification says that wizards are good
>      > examples of Customizers.  But what does a buttonless wizard look
>      > like?  Are wizards actually not good examples of Customizers?
> 
>     It is a good example. The wizard should contain the customizer component
>     to edit a copy of some bean and the buttons to apply or cancel changes.
> 
> 
> This sounds to me like you think "the wizard" is something that the 
> /tool /supplies to "contain the customizer component to edit a copy of 
> some bean", but of course (a) the wizard as mentioned in the 
> specification is supplied entirely by the component writer, not the tool 
> and (b) Customizers do not have to be supplied with copies of beans.
> 
> The specification says this:
> 
> 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.
> 
> That tells me unequivocally that a wizard is something that a component 
> writer supplies.  And since the specification also says this:
> 
> 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.
> 
> ...then it simply follows that a "customization 'wizard'" has "complete 
> discretion how it chooses to represent itself", i.e. that it supplies 
> its own buttons.
> 
> But /you're/ saying that Customizers must not provide their own buttons?
>  
> 
>     So the customizer should not extend the Window class and subclasses.
> 
> 
> Thanks; that is helpful.  Please consider amending the specification to 
> explicitly spell this out.
>  
> 
>      > Suppose as a tool author I want my tool to provide the ability to
>      > batch up and defer edits and then apply them, when the user
>      > requests it, to the Object that was set on the Customizer.
>      > How would I accomplish this in a user-friendly way without my
>      > Customizer providing buttons, or without my Customizer indicating
>      > in a specification-guided way how the tool should apply buttons?
> 
>     Provide a copy of the bean to edit.
>     The specification does not recommend direct changes.
>     See details in the section 9.2.4.
> 
> 
> Section 9.2.4 deals with PropertyEditors, not Customizers.  I'm aware of 
> the requirement for PropertyEditors that you need to edit a copy.  There 
> is no such requirement for Customizers.
>  
> 
>     I don't think that suggested algorithm should be specified,
>     because it is not backward compatible. 
> 
> 
> Which part?  I see from reading ahead you mean the "if the customizer is 
> a Window subclass" part--do you mean any other part?
>  
> 
>     If some old tool like NetBeans get the Window subclass
>     it will be broken, because unexpected exception is thrown.
> 
> 
> Sure; thanks.
> 
> So, my questions still stand:
> 
>     * If you're right, and Customizers must not supply their own
>       buttons, what buttons will a specification-compliant tool supply
>       instead when that tool launches a component-writer-supplied
>       Customizer?
>     * If the tool must supply certain buttons (as you state (and I think
>       you're quite wrong :-))), why are they not spelled out in the
>       specification, if that is indeed the specification's intention? 
>       Could you provide a list of such buttons, and indicate which are
>       required and which are optional?
> 
> Thanks for the discussion,
> Laird