-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@BoundSetter - clarification and delombok #108
Comments
For now this would create a new PropertyChangeSupport field since @BoundSetter only looks for an a existing getPropertyChangeSupport() method in the source file. So nothing super smart is happening.
Delombok just prints the AST, so there is no need for a special delombok aspect. |
How about changing it so it takes a parameter to decide whether a PropertyChangeSupport is created or if the method is used instead? The J2SE pattern might actually be to expose convenience methods for the fire events, not to expose the PCS itself. I'm extending JFrame because that's how the Netbeans GUI Editor likes to create the main application. (A moot point because the PCS is from Component, IIRC) I'm playing with a new design pattern that Lombok enables, which is to register visual components with themselves as change listeners, and then do all the MVC listener/handler registering in one place (if-else ing on the property name). e.g. setting the JFrame's controller will then pass the reference down to all sub components that need it, and register all the relevant views as listeners. MVC is great but I've always found the setup to be tricky and full of boilerplate. Kind regards, Sent from my iPhone On 20 Jul 2012, at 07:09, Philipp Eichhornreply@reply.github.com wrote:
|
Thinking about it closely @BoundSetter does not work with inheritance at all right now, so I've created a new issue for this. Issue #109 @BoundSetter should work with inheritance |
I am using @BoundSetter within a JFrame (which already has bound property support).
However, I do not know if this is resulting in a new PropertyChangeSupport field being created or if it is simply using the existing firePropertyChange() method.
Furthermore, I tried to look at the code produced by delombok (I'm using maven-lombok-plugin 0.11.0.0 and lombok-pg 0.11.3-SNAPSHOT) but the @BoundSetter annotations are still there. Has the delombok aspect of @BoundSetter been implemented yet?
The text was updated successfully, but these errors were encountered: