<Beans Dev> Customizer question

[Laird Nelson]

On Dec 10, 2007 6:29 AM, Sergey Malenkov <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/beans-dev/attachments/20071210/e2bb6cba/attachment.html