Community
Participate
Working Groups
The new data binding support requires creating bound properties in order to work well with Java beans. The following two templates make this job much easier: boundGetSet: (a bound JavaBeans getter/setter pair) ------------------------ /** * Method get${Uppercase_name}. Getter for "${Lowercase_name}" property. * * @return ${Type_name} returns the value of the "${Lowercase_name}" property. */ public ${Type_name} get${Uppercase_name}() { return ${Lowercase_name}; } /** * Method set${Uppercase_name}. Setter for "${Lowercase_name}" property. * * @param newValue the new ${Type_name} value for the "${Lowercase_name}" property. */ public void set${Uppercase_name}(${Type_name} newValue) { ${Type_name} oldValue = this.${Lowercase_name}; this.${Lowercase_name} = newValue; firePropertyChange("${Lowercase_name}", oldValue, newValue); } ${cursor} ------------------------ boundProp: A bound property (requires property change support) ------------------------ ${Type_name} ${Lowercase_name}; /** * Method get${Uppercase_name}. Getter for "${Lowercase_name}" property. * * @return ${Type_name} returns the value of the "${Lowercase_name}" property. */ public ${Type_name} get${Uppercase_name}() { return ${Lowercase_name}; } /** * Method set${Uppercase_name}. Setter for "${Lowercase_name}" property. * * @param newValue the new ${Type_name} value for the "${Lowercase_name}" property. */ public void set${Uppercase_name}(${Type_name} newValue) { ${Type_name} oldValue = this.${Lowercase_name}; this.${Lowercase_name} = newValue; firePropertyChange("${Lowercase_name}", oldValue, newValue); } ${cursor} ------------------------
Since we already have a 'Generate Getters and Setters' dialog it should be added there.
The code templates of the getter/setter wizard can be defined on the 'code templates' page, but they are not too flexible, e.g. missing the field type. But the question is, would you create all getters and setters like this? The alternative is to have what you're suggesting as one big editor template. I don't think Eclipse should offer something like that by default. But users are free to add usch a template. Suggest to set to WON'T FIX. Speak up if adding the field type as getter/setter variable would be useful.
Right now you can create getters/setters either through the dialog or by creating the field, then typing something like: getFirstName| and hitting ctrl-space. The "get method" template will be an element in the list. The problem with this is that it doesn't include firePropertyChange(...) calls if the property is supposed to be a bound property. For getters and setters, it also is possible to generate complete and correct JavaDoc--ie: more then the generic method JavaDoc we generate right now. So it would be nice for the dialog to have a check box for including the firePropertyChange calls and for the code templates that are used be able to generate complete JavaDoc. Also, I'd like to see the editor templates pasted in below included by default. I think this should be a part of the default distribution because JavaBeans is a Java language standard, and because it's something that is very useful to have if you are building a POJO-based model. About your question, I'm not sure I understand what you're asking about the field type? Right now, the property type is inferred from the underlying field's data type. Please help me understand your question?
If you have a look at the code templates (Java > Code Style > Code Teamplates), you can already define getter and setter bodies and comments. You can change them to what you suggets, but we're missing the variable ${Type_name}. We could add it. But it would still require that users change them. We can't set that as default, as not everybody is doing beans development. But extending the getter/setter wizard with a extra checkbox, 'add method firePropertyChange' would be doable. But I guess that would also mean to manage listeners ect ect. Then I would rather prefer that an extra 'Beans' plugin offers this support.
(In reply to comment #4) > If you have a look at the code templates (Java > Code Style > Code Teamplates), > you can already define getter and setter bodies and comments. You can change > them to what you suggets...</snip> I could. But I don't want to because sometimes I need just a plain getter or setter. What I really want is both. :-) >, but we're missing the variable ${Type_name}. We could > add it. But it would still require that users change them. We can't set that as > default, as not everybody is doing beans development. True enough. But if you provided both the plain vanilla getter and the bound property getter (for example), maybe this is moot? > But extending the getter/setter wizard with a extra checkbox, 'add method > firePropertyChange' would be doable. But I guess that would also mean to manage > listeners ect ect. Then I would rather prefer that an extra 'Beans' plugin > offers this support. There are enough different ways of actually writing the addPropertyChangeListener() type methods that I don't see tooling for that part. A lot of times you just have a ModelObject that defines it once and just inherit from that. I personally find that the repetitive part is the getter/setter pairs. That's where I'd experience the most benefit from having tool support.
I think the only way to implement this is to add a checkbox to the getter/setter wizard: Create setter with notification. If selected, all setters are created with the call to fire (not using the setter code template anymore). The fire method is created in not yet existing. The problem with this is that this asks for more configurability with the fire and add/remove listener methods. It would be a special support for beans. I'm close to set this to WONTFIX as we normally avoid all specialized support. But I see that this could be handy.
(In reply to comment #6) > I think the only way to implement this is to add a checkbox to the > getter/setter wizard: Create setter with notification. > If selected, all setters are created with the call to fire (not using the > setter code template anymore). The fire method is created in not yet existing. A second way to implement this is to simply include the code templates I contributed in the original request in the default Eclipse distribution. Although I'd love to have the additional capabilities in the "Generate Getter/Setter Pair" dialog that we have discussed, I would be happy enough with just the templates I contributed above. It's almost no work to include them, requires zero unit tests, zero ongoing maintanence, conforms to the JavaBean Java standard, and makes bean developers happy. What could be better? :-) > The problem with this is that this asks for more configurability with the fire > and add/remove listener methods. It would be a special support for beans. > > I'm close to set this to WONTFIX as we normally avoid all specialized support. > But I see that this could be handy. It seems that you're responding to the suggestion to add bound property support to the "Generate Getter/Setter pair" dialog box. Please note that this is not the request I made when I opened this bug. I have opened bug 148534 to track that idea. Let's please address the original request I made--complete with a patch to make your life as easy as possible. :-)
Do you mean code templates or editor templates? Code templates like the getter body is used by the setter/getter dialog. Changing these templates would result that every setter created is created with a 'fire'. The fire method itself couldn't be created like that. If it's an editor template, yes, that's easy to add. The only problem is that its hard to find for the user.
ok, from bug 148534 I think you meant 'editor template'. Bug 148534 covers the request for the getter/setter dialog.
Sorry--I mean editor templates. :-) Thanks!
*** Bug 165896 has been marked as a duplicate of this bug. ***
This would be possible in Java editor templates if a variable were provided for capitalizing another variable: private ${elemType:nv} ${nv:newName(Object)}; public ${elemType:nv} get${capitalize:nv}() { return ${nv}; } public void set${capitalize:nv}( ${elemType:nv} ${nv}) { ${cursor}firePropertyChange("${nv}", this.${nv}, this.${nv} = ${nv}); } See http://eclipse.dzone.com/news/effective-eclipse-custom-templ#comment-1511
Hi Matthew > This would be possible in Java editor templates if a variable were provided for > capitalizing another variable: We have no plans for this, but if you want and if you have time you can provide a patch which will add such a variable. It's quite simple to do, have a look at our blog to see how: http://dev.eclipse.org/blogs/jdtui/2007/12/04/text-templates-2/ Instead of a variable 'capitalize' you could also provide two variables: 'newGetterName', 'newSetterName', both taking a variable as parameter. 'capitalize' would be more flexible though. Benno
