<Beans Dev> Customizer question
Sergey Malenkov
Sergey.Malenkov at Sun.COM
Mon Dec 10 03:29:51 PST 2007
Hi Laird,
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.
> 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.
> 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.
To apply changes the new value of the property
should be set from the bean's copy.
> 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.
Values of the bean should be set when apply button is pressed.
> It sounds like what you are saying is that the contract really is
> that a Customizer/custom editor should be a /non- Window/
> Component subclass. Is that correct? Should the specification be
> amended to clarify this?
Specification says that the customizer (or property editor component)
will be added into property sheet panel or dialog window.
But our window framework does not allow to add window into container:
The IllegalArgumentException is thrown.
So the customizer should not extend the Window class and subclasses.
> You say that the tool is responsible for editing properties.
Sure.
> 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.
I don't think that suggested algorithm should be specified,
because it is not backward compatible.
If some old tool like NetBeans get the Window subclass
it will be broken, because unexpected exception is thrown.
Thanks,
SAM
Laird Nelson wrote:
> Thanks so much for your answers. For the record I agree with you that
> Customizers should not provide their own buttons, but many problems do
> result from this (that could easily be solved with a couple of
> backwards-compatible specification clarifications).
>
> For example:
>
> * 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)? How would the tool,
> if it supplies the button, know how to hook this up in an
> appropriate way to a Customizer?
> * The example given in the specification says that wizards are good
> examples of Customizer s. But what does a buttonless wizard look
> like? Are wizards actually not good examples of Customizers? If
> not, then why did the specification say they are? This example is
> why I said that I suspected that someone had some thoughts in mind
> on these issues (Graham Hamilton?) and just never wrote them down.
> * It sounds like what you are saying is that the contract really is
> that a Customizer/custom editor should be a /non- Window/
> Component subclass. Is that correct? Should the specification be
> amended to clarify this?
> * You say that the tool is responsible for editing properties.
> 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?
>
> For what it's worth (almost assuredly nothing) I would prefer a
> backwards-compatible way to allow a Customizer component to indicate
> that, effectively, it wishes to function as the contentPane (or sole
> occupant of the contentPane) of a Window, or not, and if it does not,
> then I would like a specification-defined way for that Customizer to
> indicate that it has certain Actions that should be wired up to a
> tool-supplied button bar. I propose a solution below.
>
> I've written all my Customizer-supporting tools to follow the following
> algorithm (in the case of what the spec refers to as "popping up" in a
> Window, as opposed to the "embedding" case) because I believe that the
> specification is very deficient in this area (I have another algorithm
> for the embedded case). Also, I use the term Customizer, but I also
> mean by it the custom editors returned by PropertyEditors.
>
> 1. If the Customizer is null, throw an appropriate Exception.
> 2. If the Customizer is a Window, pack() it and show() it directly. End.
> 3. (TODO: handle Applet case)
> 4. If the Customizer is a JComponent and we haven't handled it in the
> steps above:
> 1. If the Customizer is a JInternalFrame and the tool is
> launching it from "within" a JDesktopPane, pack() and show()
> it directly. End.
> 2. If the Customizer has indicated in some way (currently via a
> boolean client property "contentPane") that it wishes to be
> the sole citizen (as much as possible) of a Window, then add
> it to a new tool-supplied Window, pack() it, and show() it.
> End.
> 3. If the Customizer has an " applyChanges" Action in its
> ActionMap, or an applyChangesAction JavaBeans property:
> 1. Create an Action that will close the Window (call it
> the Close Action).
> 2. See if the Customizer has a "cancel " Action. If it
> does, create a JButton (the Cancel button) that fires
> that Action, then the Close Action. If it does not,
> create a JButton wired to the Close Action.
> 3. Create a JButton wired to the applyChanges Action (the
> Apply button).
> 4. Create a JButton that fires the Apply Action and then
> the Close Action . Call this button the OK button.
> 5. Create an OK/Cancel/Apply button bar with the JButtons
> created above.
> 6. Add the Customizer to the BorderLayout.CENTER of a new
> JPanel, and the button bar to that panel's
> BorderLayout.SOUTH.
> 7. Add the JPanel to the tool-supplied Window, pack() it,
> and show() it. End.
> 5. Since the Customizer is either a non- Window, non-JComponent
> Component, or a JComponent that did not get handled in step 4:
> 1. All we can do is add() it to the tool-supplied Window ,
> pack() it and show() it. End.
>
> Thanks,
> Laird
>
> On Dec 7, 2007 9:51 AM, Sergey Malenkov < Sergey.Malenkov at sun.com
> <mailto:Sergey.Malenkov at sun.com>> wrote:
>
> Hi Laird,
>
> > What implicit assumptions were there when the specification was
> > written? What implicit unspecified contract should Customizer
> > Components adhere to? Should they provide their own button bars
> > in all cases (i.e. is the "embedding in a panel" case just
> > silly)? Or should they /not/ provide their own button bars?
> > (Note: "button bar" here is a stand-in for any visual component
> > that provides the user a direct ability to apply or cancel changes.)
>
> This behavior is not specified, but 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, or put them onto special panel. It depends on the tool and if
> we provide the customizer with button bar the tool can't use such
> customizer properly.
>
>
> > What, if any, plans exist going forward to tighten this
> > specification up a little? Will there be any...any...annotations
> > or something to indicate to a container how a Customizer should be
> > displayed? Perhaps some kind of convention (i.e. if the
> > Customizer discovers that its parent has a Component named
> > "buttonBar" then...)?
>
> There are no any plans. The tool should decide how to edit properties.
> The tool should provide workarounds for necessary behavior.
>
>
> > One kind of Component is a Window. Is it understood (or not) that
> > if the Customizer "is a" Window it will not need to be embedded in
> > any way, shape or form?
>
> Another kind is a JInternalFrame. It is hard to decide how to show such
> components. So the tool should provide own top-level components that use
> the customizer or property editor. We should not restrict the tool.
>
> Thanks,
> SAM
>
>
> Laird Nelson wrote:
> > Hello; I hope this is the right place to ask this question. I
> > originally tried to ask it of the java-beans at java.sun.com
> <mailto:java-beans at java.sun.com>
> > <mailto:java-beans at java.sun.com <mailto:java-beans at java.sun.com>>
> email address--the address listed in
> > the Java Beans specification
> > < http://java.sun.com/products/javabeans/docs/spec.html> as being
> > appropriate for specification questions--but it bounced. Chet Haase
> > referred me here.
> >
> > My question concerns Customizers (which must, as well, be
> Components)
> > and the intention of the specification.
> >
> > The specification
> > <http://java.sun.com/products/javabeans/docs/spec.html
> <http://java.sun.com/products/javabeans/docs/spec.html>> talks about
> > Customizers being "full-fledged" editors that may be embedded in a
> > java.awt.Panel or somehow placed into a java.awt.Window.
> >
> > It strikes me that the requirements for each of these cases are very
> > different, but are not addressed by the specification.
> >
> > For example, suppose I have a PersonCustomizer that provides
> fields for
> > first and last name. If I know in advance that this Component
> will be
> > "embedded" in a Panel, then from a UI perspective I would not want to
> > saddle it with an Apply button, or an OK button, or, for that matter,
> > really any button at all.
> >
> > On the other hand, if somehow I know that my PersonCustomizer
> will be
> > the only citizen of a Window, I very much would like it to have a
> > system-appropriate button bar at the bottom (OK/Apply/Cancel/Help
> etc.).
> >
> > In both cases my Customizer would need to know when the user
> wants his
> > changes to be applied. Obviously if I supply my own button bar,
> I can
> > accomplish this. But in the "embedding" case, I may not want to do
> > this. In such a case I might want to simply provide Actions (if my
> > Customizer is also a JComponent), but it may /not/ be a JComponent.
> >
> > All of this leads me to believe that the original authors of the
> > specification (Graham Hamilton /et al/.) had something in mind that
> > wasn't committed to the specification.
> >
> > Perhaps, for example, they had in their heads that Customizer
> Components
> > would always be the sole resident of a window supplied by the
> > container. Or perhaps they assumed that at the very least
> Customizer
> > Components would always provide their own apply/cancel mechanics
> (so it
> > would not be a "violation", even in the embedding case, despite
> what the
> > specification suggests, for a Customizer to be embedded into a Panel
> > alongside other such Customizers with its own button bar).
> >
> > Now, NetBeans and if I recall correctly the old BeanBox and some
> other
> > Customizer-aware containers actually do embed Customizers inside a
> > Window of some kind (usually a JDialog ), but they also provide a
> "Done"
> > button or something similar. That strikes me--no offense
> intended--as
> > the /worst/ possible move: now, even if my Customizer provides
> its own
> > button bar to manage its commits and cancels, it looks stupid,
> because
> > there's /another/ button bar supplied by the container.
> >
> > So:
> >
> > * What implicit assumptions were there when the specification
> was
> > written? What implicit unspecified contract should Customizer
> > Components adhere to? Should they provide their own button
> bars
> > in all cases (i.e. is the "embedding in a panel" case just
> > silly)? Or should they /not/ provide their own button bars?
> > (Note: "button bar" here is a stand-in for any visual component
> > that provides the user a direct ability to apply or cancel
> changes.)
> > * What, if any, plans exist going forward to tighten this
> > specification up a little? Will there be
> any...any...annotations
> > or something to indicate to a container how a Customizer
> should be
> > displayed? Perhaps some kind of convention (i.e. if the
> > Customizer discovers that its parent has a Component named
> > "buttonBar" then...)?
> > * One kind of Component is a Window. Is it understood (or
> not) that
> > if the Customizer "is a" Window it will not need to be
> embedded in
> > any way, shape or form?
> > * These issues can (and do) also apply to the custom editors
> > returned by PropertyEditors . Is there any reason why any
> > solution here would not reasonably apply to those cases as
> well?
> >
> > Thanks for your time,
> > Laird
More information about the beans-dev
mailing list