Home » Archived » Visual Editor (VE) » Property change event not persisting its value?
| Property change event not persisting its value? [message #90748] |
Thu, 12 May 2005 06:48  |
Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In my customizer, I have an "Apply" button that I use to do a
firePropertyChange(...) to update of the bean.
My log shows that it is the WindowLaucher that is registering on the
customizer for property change events:
2005-05-11 21:46:20,793 [Connection Thread] DEBUG
net.certiv.swing.GradientCustomizer - Adding property change listener
for: org.eclipse.ve.internal.java.remotevm.WindowLauncher$5
When I click the apply button, VE *does* repaint the bean in the design
view to conform to the changed value provided by the customizer. VE
does not, however, update the property sheet or the code.
If I then click VE's "OK" button, the code and property sheet update
correctly (the customizer also closes, which is not the desired
behavior).
If, instead, I click VE's "Cancel" button, the bean repaints back to its
original state; the property sheet and code are unchanged.
While the display and code/property sheet are out of sync, the getter
methods do appear to return the displayed values, rather than the
code/property sheet values. So, it appears that VE is imposing state on
the operation of the customizer.
My customizer handles its own checkpoint state issues - it is a rather
complete JTable-based form designer for the JGoodies form layout manager
that supports visual prototyping with checkpoint saves as the user
progresses through the design. Closing and reopening the customizer
just to persist changes is not desirable.
Is there a way to have VE simply persist a changed property value
whenever its property change event is fired? The alternative is for me,
and others similarly situated, to modify the customizer to dig into the
BeanPropertyEditorJFrame to access notifySavePropertyValue() and other
methods directly. Is there a better approach?
Thanks.
|
|
|
| Re: Property change event not persisting its value? [message #90837 is a reply to message #90748] |
Thu, 12 May 2005 11:52  |
 Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald Rosenberg,
> In my customizer, I have an "Apply" button that I use to do a
> firePropertyChange(...) to update of the bean.
> When I click the apply button, VE *does* repaint the bean in the design
> view to conform to the changed value provided by the customizer. VE
> does not, however, update the property sheet or the code.
That's right. What you're doing is changing the JavaBean and firing a
change so the VE refreshes the live bean. We don't update the code
until the customizer closes - at that point we compare the property
values going in and the ones returned and then update the code.
> If I then click VE's "OK" button, the code and property sheet update
> correctly (the customizer also closes, which is not the desired
> behavior).
Why is closing not the desired behavior ? On most dialogs an "OK"
button means "confirm and close" and cancel means "do not confirm and
close". I'd be more astonished if an OK buton didn't close the dialog.
> If, instead, I click VE's "Cancel" button, the bean repaints back to its
> original state; the property sheet and code are unchanged.
How cool is that. Even though you have altered the JavaBean in your
customizer the VE has managed to do magic to roll it back to the
previous state. Surely this is a piece of welcome magic ??
> While the display and code/property sheet are out of sync, the getter
> methods do appear to return the displayed values, rather than the
> code/property sheet values. So, it appears that VE is imposing state on
> the operation of the customizer.
Not sure what you mean about imposing state. The property sheet shows
the value of a property which either comes from its internal model of
what the bean looks like if it is explicitly set - there will be a
little > next to the property and a set method as well. If there is no
explicit set method then we go to the live bean to show the value. Your
live bean and the code are out of sync although I do not understand how
unless you changed a property of a property without swopping out the top
level property.
One thing I think we could do better is allow for this kind of change
where someone chops a branch off a tree without chopping down the tree
and cause it's not noisy enough for us as we are looking for trees only
we don't see it. We could make it so if you fire a property change with
a property we then assume that said property has changed whatever and we
burn code for.
> My customizer handles its own checkpoint state issues - it is a rather
> complete JTable-based form designer for the JGoodies form layout manager
> that supports visual prototyping with checkpoint saves as the user
> progresses through the design. Closing and reopening the customizer
> just to persist changes is not desirable.
Cool. We have always always wanted to get into JGoodies. Please tell
me more about what you are doing. One thing the VE can do is support
new layout managers and all the stuff that occurs in the VE viewers
where you get grids and feedback and stuff is part of an API that we'd
love other layout managers to leverage.
It sounds like your customizer is more intelligent that the ones we
built the VE for so we need to find a way to deal with it properly however.
> Is there a way to have VE simply persist a changed property value
> whenever its property change event is fired?
My suggestion would be that we change VE so we listen for a property
change and if we see one that specifically names a property then we
record it. I am not sure we should update the code immediately as the
customizer should be modal so we can just remember this and then update
the code when it shuts. However this brings us back to the question of
cancel versus OK and knowing when the customizer closes whether it wants
us to persist or not. Your customizer is smart and does its own
management of this, however not all will. If we listened to the changes
and remembered them and you cancelled what could we do then. We need
some flag that says "please apply changes" and also a way of knowing
what properties have changed.
> The alternative is for me,
> and others similarly situated, to modify the customizer to dig into the
> BeanPropertyEditorJFrame to access notifySavePropertyValue() and other
> methods directly. Is there a better approach?
Yikes - don't start digging there. You know it's gonna be a hack and
all we need to do is solve two problems:
1 - have the customizer tell the VE that a property has changed
2 - have the customizer tell the VE that it will handle its own rollback
and also tell the VE when it has done a rollback
Best regards,
Joe Winchester
|
|
|
| Re: Property change event not persisting its value? [message #90931 is a reply to message #90837] |
Thu, 12 May 2005 22:46 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
Joe,
There is no doubt that what you are doing with VE is really cool, and I
appreciate the obviously hard work that goes into it. Please accept my
comments purely in the context of constructive dialog.
I am really hesitant to propose changes to the Customizer interface due
to the affect on portability. Even if it could be changed, there is the
problem with legacy beans. Thus, I am hesitant to endorse what are
otherwise really nice features.
My belief is that VE should implement the customizer interface as
minimally/conservatively as possible consistent with the spec and
provide any other behaviors as VE enhancements.
So, what is minimum. The spec, at section 9.3.1, states "The customizer
has complete discretion how it chooses to represent itself ...".
Therefore, the customizer must be able to control what if any buttons
are to be provided and what their operational semantics are supposed to
be. Button appearance and function cannot be imposed by the container.
The only other relevant hint is given in the JavaDoc for the
Customizer#addPropertyChangeListener: "The customizer should fire a
PropertyChange event whenever it changes the target bean in a way that
might require the displayed properties to be refreshed." This indicates
that a property change event is supposed to change the target bean, not
just the transient display of the bean.
Is this consistent with how others have interpreted the spec?
The beanbox (I cannot find anything that says it is a reference
implementation) does provide OK and Close buttons as part of the
customizer container. The buttons do not seem to impose any state
transaction/rollback logic. Property change events appear to
immediately modify the code of the target bean. Looks like in some
cases, focus lost events are used to fire property change events and
updates to other customizer fields based on getter calls - changes are
applied independent of any button use.
Jigloo, JDeveloper 9 and 10 (if memory serves), JBuilder 7, and
VisualCafe (at least it is newer than the beanbox) all provide a
container without any buttons and respond to property change events by
immediately updating the target bean.
From its documentation, NetBeans also appears not to provide buttons.
Finally, Sun's Rave product provides a single default "Done" button that
simply closes the customizer container - no commit or rollback logic
implemented. Property change events are recognized and the value
changed is applied immediately to the target bean.
What is also interesting about Rave is that it presents a Customizer2
interface
http://developers.sun.com/prodtech/javatools/jscreator/refer ence/apis/de
signtime/com/sun/rave/designtime/Customizer2.html
that adds optional button and state management features. Note that
clicking the container provided Apply or Ok button actually delegates
the firing property change events back to the customizer.
My guess is that Rave checks a customizer panel to see if it implements
the Customizer2 interface and, if so, tailors the otherwise minimum
default container appropriately.
Now, I think Rave got it right by supporting additional behaviours only
as options. Rave go it wrong, however, in allowing the container to add
buttons. And here is why. My customizer implements a Lnf, with custom
UIs, that is different from that of the IDE. The result is very bad
aesthetically. (VE has the same problem; if you want I can grab a screen
shot of my customizer to illustrate the problem.)
Unfortunately, there is no easy way to delegate the creation of a button
bar from the container and automatically pick up the Lnf of the
customizer.
VE does, however, contain the seeds of the fix. VE actively sets the
container button bar to use the IDE's look and feel. The proper choice
would be to check for and use the customizer's Lnf.
So what should VE's optional customizer interface be? Here is a first
shot at it:
import java.awt.Image;
import java.beans.PropertyChangeListener;
/**
* Optional customizer panel handler. Adds enhanced support for three
primary
* modes of operation:
* <ol>
* <li> Complete customizer: the customizer is responsible for handling
all
* aspects of its operaton, including providing whatever buttons are
needed and
* handling any and all transactional aspects of updating the target
bean.
* Expects no container provided buttons and property change events to
complete
* entirely and immediately. </li>
* <li> Container provided buttons: container provides a customizer
defined
* button bar. Expects property change events to complete entirely and
* immediately. </li>
* <li> Container managed state: container provides a customizer defined
button
* bar (OK and Cancel required). Expects the effects of property change
events
* to display immediately, but only commit on OK or rollback on Cancel.
</li>
* </ol>
*
* @license EPL
* @author Gbr
*/
interface Customizer3 {
/**
* Adds a property change listener to this customizer. Named
property change
* events will be fired by the customizer whenever a property
value changes.
* A 'null' named event will be fired to request an update,
typically a
* refresh, of the target bean.
* <p>
* The default behavior is to have the container or a proxy listen
for
* property change events and to propogate and apply the changed
value to
* the target bean effective immediately. The customizer may
direct the
* container to defer application of the changes to the target
bean. In this
* case the container will commit changes on OK and rollback
changes on
* Cancel.
*
* @param listener
* the target property listener
* @see Customizer3#containerManagedState()
*/
public void addPropertyChangeListener(PropertyChangeListener
listener);
/**
* Removes the given listener from the list of property change
event
* receipients.
*
* @param listener
* the target property listener
*/
public void removePropertyChangeListener
(java.beans.PropertyChangeListener listener);
/**
* Provides the container with a short string intended to be
applied as the
* title of this container. Should be retrieved once by the
container after
* instantiating the customizer object. Not intended for use as a
status
* message. The string should be descriptive of the function of
the
* customizer.
*
* @return a text string suitable for use as a container title.
*/
public String getCustomizerTitle();
/**
* Provides the container with a small icon image representing this
* customizer.
*
* @return an icon image or null; default is null.
*/
public Image getCustomizerIcon();
/**
* Defines how the container should treat a window close decorator
click.
* The allowed values are:
* <ol>
* <li> Denied - must use a button, provided at least one button
is defined.
* </li>
* <li> Treat equivalent to a cancel button click. </li>
* <li> Treat equivalent to a close button click. </li>
* </ol>
*
* @return the desired window close decorator behavior.
*/
public int onDecoratorClose();
/**
* Determines whether the closing of the customizer/container also
has the
* side-effect of commiting any outstanding container transacton.
*
* @return true causes the container to invoke apply; false is a
simple
* container close; default is false.
*/
public boolean onCloseCommit();
/**
* Determines whether the customizer chooses to have the container
manage
* property change state on behalf of the customizer. If true, it
is the
* responsibility of the container to manage the display of the
target bean
* consistent with the changed value, but not commit changes
signaled by
* property change events. If false, the container must cause the
commit of
* property changes immediately.
*
* @return true to have the container manage state; default is
false.
*/
public boolean containerManagedState();
/**
* Defines whether and how the container is to display a button
bar. If the
* return value is null, then no bar will be displayed. The button
bar
* should be created using the look and feel, if any, specified by
the
* customizer. The allowed values, in any order, are:
* <ol>
* <li> Apply </li>
* <li> OK </li>
* <li> Cancel </li>
* <li> Close </li>
* <li> Help </li>
* </ol>
*
* @return the desired customizer button bar behavior; null for no
button
* bar.
*/
public int[] containerButtonBar();
/**
* Called by the container when the Apply button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Apply
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doApply();
/**
* Called by the container when the OK button is clicked. Allows
the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
OK
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doOK();
/**
* Called by the container when the Close button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Close
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doClose();
/**
* Called by the container when the Cancel button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Cancel
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doCancel();
/**
* Called by the container when the Help button is clicked. Allows
the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Help
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doHelp();
/**
* Called by the container to determine the displayable button
state. A null
* return value indicates all buttons enabled. Button identifiers
in the
* returned array signify a disabled state.
*
* @return null or an empty array for all buttons enabled; a valid
button
* identifier signals the button to be disabled.
*/
public int[] getState();
}
|
|
| |
| Re: Property change event not persisting its value? [message #90961 is a reply to message #90837] |
Fri, 13 May 2005 00:37 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d5vgij$tsa$1@news.eclipse.org>, winchest@uk.ibm.com says...
> > My customizer handles its own checkpoint state issues - it is a rather
> > complete JTable-based form designer for the JGoodies form layout manager
> > that supports visual prototyping with checkpoint saves as the user
> > progresses through the design. Closing and reopening the customizer
> > just to persist changes is not desirable.
>
> Cool. We have always always wanted to get into JGoodies. Please tell
> me more about what you are doing. One thing the VE can do is support
> new layout managers and all the stuff that occurs in the VE viewers
> where you get grids and feedback and stuff is part of an API that we'd
> love other layout managers to leverage.
>
> It sounds like your customizer is more intelligent that the ones we
> built the VE for so we need to find a way to deal with it properly however.
My customizer is fairly complex, but not more so than I thought would be
common for customizers.
While it is nice that VE supports the addition of "other" layout
managers, I long ago decided not to depend on such proprietary IDE
features. A right decision? Good thing I did not try to build it
native into VisualCafe!
My experience has been that there are always rather fundamental problems
trying to incorporate something as different as the forms layout manager
and builders into a general purpose IDE. Clash of design philosophies
or with other features that cannot be changed just to accommodate a
third-party layout-manager. Winds up being too much effort for
something non-portable and ultimately not completely functional. For
example, the forms layout manager does not have a default constructor -
not sure if that is fatal, but at first glance it is at odds to what VE
expects.
To make a long story short, I decided to design for portability: my
JForms bean is a JPanel extension that is hardwired to use the forms
layout manager. The customizer provides a complete, free floating
design view that, whenever you click Apply, codes the layout design into
a couple of fairly complex strings and sets them on the JFormPanel.
The neat thing is that IDE's design display immediately updates to
match! While the customizer provides a representational view - it is
basically a JTable, the IDE view is "real" with real components
positioned as determined by the actual forms layout manager.
Would this all be better if done natively in the design view,
portability aside? Actually not I think. A customizer based designer
feels far more functional than working with grids displayed directly in
the design view. My customizer based JTable is supported by a complete,
tailored set of JComboBoxes, JSpinners, etc. that directly show and
enable quick modification of layout parameters.
Anyway, if you are interested in trying it out, let me know. The core
functions of the customizer and JFormPanel are all working. The only
problems with the bean are the customizer issues we have been discussing
and figuring out how to key VE to do a complete relayout of its design
view. The only other issue I am having is covered by the 93268 bug.
Thanks again for all your help.
Best,
Gerald
|
|
|
| Re: Property change event not persisting its value? [message #90976 is a reply to message #90946] |
Fri, 13 May 2005 01:43 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d60o0e$ftf$1@news.eclipse.org>, winchest@uk.ibm.com says...
> Hi Gerald,
>
> Thanks for your very detailed note. Please open a bugzilla feature
> request for us to implement the following:
95070
> You have clearly put a lot of thought into this and know a lot about
> customizers. Let me know if you have the cycles to work on this
Some. We first need to figure out the best approach for VE before I can
determine if it is of a scope I can handle.
Best regards,
Gerald
|
|
|
| Re: Property change event not persisting its value? [message #607745 is a reply to message #90748] |
Thu, 12 May 2005 11:52 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald Rosenberg,
> In my customizer, I have an "Apply" button that I use to do a
> firePropertyChange(...) to update of the bean.
> When I click the apply button, VE *does* repaint the bean in the design
> view to conform to the changed value provided by the customizer. VE
> does not, however, update the property sheet or the code.
That's right. What you're doing is changing the JavaBean and firing a
change so the VE refreshes the live bean. We don't update the code
until the customizer closes - at that point we compare the property
values going in and the ones returned and then update the code.
> If I then click VE's "OK" button, the code and property sheet update
> correctly (the customizer also closes, which is not the desired
> behavior).
Why is closing not the desired behavior ? On most dialogs an "OK"
button means "confirm and close" and cancel means "do not confirm and
close". I'd be more astonished if an OK buton didn't close the dialog.
> If, instead, I click VE's "Cancel" button, the bean repaints back to its
> original state; the property sheet and code are unchanged.
How cool is that. Even though you have altered the JavaBean in your
customizer the VE has managed to do magic to roll it back to the
previous state. Surely this is a piece of welcome magic ??
> While the display and code/property sheet are out of sync, the getter
> methods do appear to return the displayed values, rather than the
> code/property sheet values. So, it appears that VE is imposing state on
> the operation of the customizer.
Not sure what you mean about imposing state. The property sheet shows
the value of a property which either comes from its internal model of
what the bean looks like if it is explicitly set - there will be a
little > next to the property and a set method as well. If there is no
explicit set method then we go to the live bean to show the value. Your
live bean and the code are out of sync although I do not understand how
unless you changed a property of a property without swopping out the top
level property.
One thing I think we could do better is allow for this kind of change
where someone chops a branch off a tree without chopping down the tree
and cause it's not noisy enough for us as we are looking for trees only
we don't see it. We could make it so if you fire a property change with
a property we then assume that said property has changed whatever and we
burn code for.
> My customizer handles its own checkpoint state issues - it is a rather
> complete JTable-based form designer for the JGoodies form layout manager
> that supports visual prototyping with checkpoint saves as the user
> progresses through the design. Closing and reopening the customizer
> just to persist changes is not desirable.
Cool. We have always always wanted to get into JGoodies. Please tell
me more about what you are doing. One thing the VE can do is support
new layout managers and all the stuff that occurs in the VE viewers
where you get grids and feedback and stuff is part of an API that we'd
love other layout managers to leverage.
It sounds like your customizer is more intelligent that the ones we
built the VE for so we need to find a way to deal with it properly however.
> Is there a way to have VE simply persist a changed property value
> whenever its property change event is fired?
My suggestion would be that we change VE so we listen for a property
change and if we see one that specifically names a property then we
record it. I am not sure we should update the code immediately as the
customizer should be modal so we can just remember this and then update
the code when it shuts. However this brings us back to the question of
cancel versus OK and knowing when the customizer closes whether it wants
us to persist or not. Your customizer is smart and does its own
management of this, however not all will. If we listened to the changes
and remembered them and you cancelled what could we do then. We need
some flag that says "please apply changes" and also a way of knowing
what properties have changed.
> The alternative is for me,
> and others similarly situated, to modify the customizer to dig into the
> BeanPropertyEditorJFrame to access notifySavePropertyValue() and other
> methods directly. Is there a better approach?
Yikes - don't start digging there. You know it's gonna be a hack and
all we need to do is solve two problems:
1 - have the customizer tell the VE that a property has changed
2 - have the customizer tell the VE that it will handle its own rollback
and also tell the VE when it has done a rollback
Best regards,
Joe Winchester
|
|
|
| Re: Property change event not persisting its value? [message #607751 is a reply to message #90837] |
Thu, 12 May 2005 22:46 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Joe,
There is no doubt that what you are doing with VE is really cool, and I
appreciate the obviously hard work that goes into it. Please accept my
comments purely in the context of constructive dialog.
I am really hesitant to propose changes to the Customizer interface due
to the affect on portability. Even if it could be changed, there is the
problem with legacy beans. Thus, I am hesitant to endorse what are
otherwise really nice features.
My belief is that VE should implement the customizer interface as
minimally/conservatively as possible consistent with the spec and
provide any other behaviors as VE enhancements.
So, what is minimum. The spec, at section 9.3.1, states "The customizer
has complete discretion how it chooses to represent itself ...".
Therefore, the customizer must be able to control what if any buttons
are to be provided and what their operational semantics are supposed to
be. Button appearance and function cannot be imposed by the container.
The only other relevant hint is given in the JavaDoc for the
Customizer#addPropertyChangeListener: "The customizer should fire a
PropertyChange event whenever it changes the target bean in a way that
might require the displayed properties to be refreshed." This indicates
that a property change event is supposed to change the target bean, not
just the transient display of the bean.
Is this consistent with how others have interpreted the spec?
The beanbox (I cannot find anything that says it is a reference
implementation) does provide OK and Close buttons as part of the
customizer container. The buttons do not seem to impose any state
transaction/rollback logic. Property change events appear to
immediately modify the code of the target bean. Looks like in some
cases, focus lost events are used to fire property change events and
updates to other customizer fields based on getter calls - changes are
applied independent of any button use.
Jigloo, JDeveloper 9 and 10 (if memory serves), JBuilder 7, and
VisualCafe (at least it is newer than the beanbox) all provide a
container without any buttons and respond to property change events by
immediately updating the target bean.
From its documentation, NetBeans also appears not to provide buttons.
Finally, Sun's Rave product provides a single default "Done" button that
simply closes the customizer container - no commit or rollback logic
implemented. Property change events are recognized and the value
changed is applied immediately to the target bean.
What is also interesting about Rave is that it presents a Customizer2
interface
http://developers.sun.com/prodtech/javatools/jscreator/refer ence/apis/de
signtime/com/sun/rave/designtime/Customizer2.html
that adds optional button and state management features. Note that
clicking the container provided Apply or Ok button actually delegates
the firing property change events back to the customizer.
My guess is that Rave checks a customizer panel to see if it implements
the Customizer2 interface and, if so, tailors the otherwise minimum
default container appropriately.
Now, I think Rave got it right by supporting additional behaviours only
as options. Rave go it wrong, however, in allowing the container to add
buttons. And here is why. My customizer implements a Lnf, with custom
UIs, that is different from that of the IDE. The result is very bad
aesthetically. (VE has the same problem; if you want I can grab a screen
shot of my customizer to illustrate the problem.)
Unfortunately, there is no easy way to delegate the creation of a button
bar from the container and automatically pick up the Lnf of the
customizer.
VE does, however, contain the seeds of the fix. VE actively sets the
container button bar to use the IDE's look and feel. The proper choice
would be to check for and use the customizer's Lnf.
So what should VE's optional customizer interface be? Here is a first
shot at it:
import java.awt.Image;
import java.beans.PropertyChangeListener;
/**
* Optional customizer panel handler. Adds enhanced support for three
primary
* modes of operation:
* <ol>
* <li> Complete customizer: the customizer is responsible for handling
all
* aspects of its operaton, including providing whatever buttons are
needed and
* handling any and all transactional aspects of updating the target
bean.
* Expects no container provided buttons and property change events to
complete
* entirely and immediately. </li>
* <li> Container provided buttons: container provides a customizer
defined
* button bar. Expects property change events to complete entirely and
* immediately. </li>
* <li> Container managed state: container provides a customizer defined
button
* bar (OK and Cancel required). Expects the effects of property change
events
* to display immediately, but only commit on OK or rollback on Cancel.
</li>
* </ol>
*
* @license EPL
* @author Gbr
*/
interface Customizer3 {
/**
* Adds a property change listener to this customizer. Named
property change
* events will be fired by the customizer whenever a property
value changes.
* A 'null' named event will be fired to request an update,
typically a
* refresh, of the target bean.
* <p>
* The default behavior is to have the container or a proxy listen
for
* property change events and to propogate and apply the changed
value to
* the target bean effective immediately. The customizer may
direct the
* container to defer application of the changes to the target
bean. In this
* case the container will commit changes on OK and rollback
changes on
* Cancel.
*
* @param listener
* the target property listener
* @see Customizer3#containerManagedState()
*/
public void addPropertyChangeListener(PropertyChangeListener
listener);
/**
* Removes the given listener from the list of property change
event
* receipients.
*
* @param listener
* the target property listener
*/
public void removePropertyChangeListener
(java.beans.PropertyChangeListener listener);
/**
* Provides the container with a short string intended to be
applied as the
* title of this container. Should be retrieved once by the
container after
* instantiating the customizer object. Not intended for use as a
status
* message. The string should be descriptive of the function of
the
* customizer.
*
* @return a text string suitable for use as a container title.
*/
public String getCustomizerTitle();
/**
* Provides the container with a small icon image representing this
* customizer.
*
* @return an icon image or null; default is null.
*/
public Image getCustomizerIcon();
/**
* Defines how the container should treat a window close decorator
click.
* The allowed values are:
* <ol>
* <li> Denied - must use a button, provided at least one button
is defined.
* </li>
* <li> Treat equivalent to a cancel button click. </li>
* <li> Treat equivalent to a close button click. </li>
* </ol>
*
* @return the desired window close decorator behavior.
*/
public int onDecoratorClose();
/**
* Determines whether the closing of the customizer/container also
has the
* side-effect of commiting any outstanding container transacton.
*
* @return true causes the container to invoke apply; false is a
simple
* container close; default is false.
*/
public boolean onCloseCommit();
/**
* Determines whether the customizer chooses to have the container
manage
* property change state on behalf of the customizer. If true, it
is the
* responsibility of the container to manage the display of the
target bean
* consistent with the changed value, but not commit changes
signaled by
* property change events. If false, the container must cause the
commit of
* property changes immediately.
*
* @return true to have the container manage state; default is
false.
*/
public boolean containerManagedState();
/**
* Defines whether and how the container is to display a button
bar. If the
* return value is null, then no bar will be displayed. The button
bar
* should be created using the look and feel, if any, specified by
the
* customizer. The allowed values, in any order, are:
* <ol>
* <li> Apply </li>
* <li> OK </li>
* <li> Cancel </li>
* <li> Close </li>
* <li> Help </li>
* </ol>
*
* @return the desired customizer button bar behavior; null for no
button
* bar.
*/
public int[] containerButtonBar();
/**
* Called by the container when the Apply button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Apply
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doApply();
/**
* Called by the container when the OK button is clicked. Allows
the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
OK
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doOK();
/**
* Called by the container when the Close button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Close
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doClose();
/**
* Called by the container when the Cancel button is clicked.
Allows the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Cancel
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doCancel();
/**
* Called by the container when the Help button is clicked. Allows
the
* customizer to either veto the user requested action or perform
any
* appropriate functions prior to the container completion of the
Help
* function.
*
* @return true if the function is permitted; default is true.
*/
public boolean doHelp();
/**
* Called by the container to determine the displayable button
state. A null
* return value indicates all buttons enabled. Button identifiers
in the
* returned array signify a disabled state.
*
* @return null or an empty array for all buttons enabled; a valid
button
* identifier signals the button to be disabled.
*/
public int[] getState();
}
|
|
| |
| Re: Property change event not persisting its value? [message #607753 is a reply to message #90837] |
Fri, 13 May 2005 00:37 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
In article <d5vgij$tsa$1@news.eclipse.org>, winchest@uk.ibm.com says...
> > My customizer handles its own checkpoint state issues - it is a rather
> > complete JTable-based form designer for the JGoodies form layout manager
> > that supports visual prototyping with checkpoint saves as the user
> > progresses through the design. Closing and reopening the customizer
> > just to persist changes is not desirable.
>
> Cool. We have always always wanted to get into JGoodies. Please tell
> me more about what you are doing. One thing the VE can do is support
> new layout managers and all the stuff that occurs in the VE viewers
> where you get grids and feedback and stuff is part of an API that we'd
> love other layout managers to leverage.
>
> It sounds like your customizer is more intelligent that the ones we
> built the VE for so we need to find a way to deal with it properly however.
My customizer is fairly complex, but not more so than I thought would be
common for customizers.
While it is nice that VE supports the addition of "other" layout
managers, I long ago decided not to depend on such proprietary IDE
features. A right decision? Good thing I did not try to build it
native into VisualCafe!
My experience has been that there are always rather fundamental problems
trying to incorporate something as different as the forms layout manager
and builders into a general purpose IDE. Clash of design philosophies
or with other features that cannot be changed just to accommodate a
third-party layout-manager. Winds up being too much effort for
something non-portable and ultimately not completely functional. For
example, the forms layout manager does not have a default constructor -
not sure if that is fatal, but at first glance it is at odds to what VE
expects.
To make a long story short, I decided to design for portability: my
JForms bean is a JPanel extension that is hardwired to use the forms
layout manager. The customizer provides a complete, free floating
design view that, whenever you click Apply, codes the layout design into
a couple of fairly complex strings and sets them on the JFormPanel.
The neat thing is that IDE's design display immediately updates to
match! While the customizer provides a representational view - it is
basically a JTable, the IDE view is "real" with real components
positioned as determined by the actual forms layout manager.
Would this all be better if done natively in the design view,
portability aside? Actually not I think. A customizer based designer
feels far more functional than working with grids displayed directly in
the design view. My customizer based JTable is supported by a complete,
tailored set of JComboBoxes, JSpinners, etc. that directly show and
enable quick modification of layout parameters.
Anyway, if you are interested in trying it out, let me know. The core
functions of the customizer and JFormPanel are all working. The only
problems with the bean are the customizer issues we have been discussing
and figuring out how to key VE to do a complete relayout of its design
view. The only other issue I am having is covered by the 93268 bug.
Thanks again for all your help.
Best,
Gerald
|
|
| |
Goto Forum:
Current Time: Sat Nov 09 03:02:21 GMT 2024
Powered by FUDForum. Page generated in 0.03613 seconds |
] 
Search
Help
Register
Login
Home
