This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 69671 - Refactoring should be able to create bound properties
Summary: Refactoring should be able to create bound properties
Status: RESOLVED DUPLICATE of bug 69498
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker with 2 votes (vote)
Assignee: Jan Becicka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-01 02:09 UTC by kitfox
Modified: 2011-01-18 15:02 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kitfox 2005-12-01 02:09:05 UTC
At the moment, the refactoring mechanism only generates getter and setter
methods when it encapsulates fields.  It would be very useful to extend this so
that it can generate bound and vetoable properties as well.  At the moment, I
need to go back and hand edit my encapsulated fields to make them bean compliant.
Comment 1 Jan Lahoda 2006-01-23 11:53:32 UTC
refactoring?
Comment 2 kitfox 2006-01-23 19:21:32 UTC
When you encapsulate fields.  Instead of simply generating:

class MyClass
{
    private int top;

    public int getTop()
    {
        return top;
    }

    public void setTop(int top)
    {
        this.top = top;
    }
}

it would be nice if an option for something like the following could be done:

class MyClass
{
    PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);

    private int top;

    public int getTop()
    {
        return top;
    }

    public void setTop(int top)
    {
        int old = this.top;
        this.top = top;
        propertyChangeSupport.firePropertyChange("top", old, top);
    }
}

The above code makes 'top' a bound field.  Something that also provides the
option of making a vetoable field would also be useful.
Comment 3 kitfox 2006-01-23 20:52:16 UTC
An even better way to do this would be to first check if the current class
contains a memeber which is a PropertyChangeSupport.  If not, create one,
including the add and remove listener methods.

Also, setting a static final String to be the property name would be a good idea.

class MyClass
{
    PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);

    private int top;

    public static final PROP_top = "top";

    public void addPropertyChangeListener(PropertyChangeListener l)
    {
        propertyChangeSupport.addPropertyChangeListener(l);
    }

    public void removePropertyChangeListener(PropertyChangeListener l)
    {
        propertyChangeSupport.removePropertyChangeListener(l);
    }

    public int getTop()
    {
        return top;
    }

    public void setTop(int top)
    {
        int old = this.top;
        this.top = top;
        propertyChangeSupport.firePropertyChange(PROP_top, old, top);
    }
}
Comment 4 Jan Becicka 2011-01-18 15:02:17 UTC

*** This bug has been marked as a duplicate of bug 69498 ***