NetBeans IDE Dev (Build 200704111800)
1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
Linux version 2.6.5-1.358 running on i386
en_US (nb); UTF-8
When renaming class field it would be nice to have a possibility to rename also
the setter and getter method. There is no way how to do that now, when the Beans
node was removed.
*** Issue 111616 has been marked as a duplicate of this issue. ***
I see it more defect than ehnancement as it brings incosistency to the code
and behaves in unexpected way.
We use DEFECT for issues, which behavior is not according to specification. This is 100% valid issue, but it is an
*** Issue 128858 has been marked as a duplicate of this issue. ***
moving opened issues from TM <= 6.1 to TM=Dev
*** Issue 49485 has been marked as a duplicate of this issue. ***
There is no guidelines for feature so I following my needs and the other users. It should be implemented asap and 'Nice
to have' for 7.0 is not a good option.
Just a little more information. Don't forget that just renaming a field shouldn't necessarily rename the methods. It
seems a better and specific JavaBean rename action is needed. Thinking about the case where the variable name is shorter
for inner private use. What about when the Bean Info references method names not necessarily matching the patterns from
JavaBeans? This is a feature of a property descriptor. So, it really needs to be thought out well to actually encompass
the JavaBeans specifications and not just POJO use cases.
I have really been hoping to get some time to really work on the beans module. This is the module that provides the
support of the Bean Patterns view in the navigator. So, in that panel in the navigator maybe have some actions that can
then tie into refactoring.
So, say I want to rename a property. It can bring up a dialog that lets me tell it to 1) change the name of the field or
leave it alone, 2) change the name of the setter or getter independently (canRead versus isReadable as boolean reader
properties), 3) update the BeanInfo and property descriptors, or is this property not going to affect that, but then
that becomes subjective, because the JavaBeans property rename support needs to alert the user that if a property use a
non-JavaBean pattern name that the BeanInfo property descriptors have to be updated because that is the only way to link
a method of such a name to a property.
I think that the best solution would be a comprehensive javabean editor feature. Such an editor would not only be
generating code, but would understand it's state so it could also edit it. The current code generation features are
nice, but may times inadequate. I think that a full javabean editor wouldn't have to replace them in lightweight tasks
like generating getter/setter methods, but could be used for tasks such as creating a javabean from scratch and
maintaining existing large beans. The javabean pattern is itself a dated and cumbersome thing, especially if you want
to be firing property change events also. I repeatedly have the same problem in our firm of convincing junior
programmers about writing all that boilerplate code. If that code would at least be generated for them (and for me :))
it would make my everyday work much more productive (I user entity beans, and beans binding a lot).
IMO, this issue is a blocker for http://www.netbeans.org/issues/show_bug.cgi?id=106831
What do you think? That issue and wiki page has reference about the content of this issue. IMO, we need to track all
needed refactorings and treat 106831 as a umbrella. I hope this could be the first one.
*** Issue 90941 has been marked as a duplicate of this issue. ***
Author: Jan Becicka <firstname.lastname@example.org>
Date: 2011-05-26 10:55
Issue #100758 - [65cat] Implement beans refactoring (and improve encapsulate fields)
Integrated into 'main-golden', will be available in build *201105270401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jan Becicka <email@example.com>
Log: Issue #100758 - [65cat] Implement beans refactoring (and improve encapsulate fields)