search

lishunli / projectlombok

Automatically exported from code.google.com/p/projectlombok
0 stars 0 forks source link

Add PropertyChangeSupport to @Data for two-way databinding #27

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
One of the biggest problems in Java is the lack of proper two-way
databinding between POJOs and GUI components. it is possible, but becomes
VERY verbose since every setter needs to fire a firePropertyChange event.

I've tried to tackle this problem in my ClassBuilder utility, but your
approach is *WAY* better.

I've summarized the two-way binding issue here:
http://code.google.com/p/javabuilders/wiki/ClassBuilder 
(see the "What is the problem we're trying to solve?" section)

it would be amazing if @Data had an option to generate all the
PropertyChangeSupport plumbing on the class and setters...this would
singlehandedly fix in Java what Sun was unable to do for 10 years.

P.S. There should be an option to specify the type of PropertyChangeSupport
class you want to use, there are specialized types for Swing that ensure
that firePropertyChange calls are always on the EDT thread, for example.

See the Wiki link for @Bindable (not sure if that is the API you would want
to use) or maybe

@Data(bindableVia=SwingPropertyChangeSupport.class)

Thanks! Amazing project you have here.

Original issue reported on code.google.com by jace...@gmail.com on 12 Aug 2009 at 2:33

GoogleCodeExporter commented 9 years ago 
If you look through some of the discussion sections, I do believe this is in the
works.  From what I can tell, instead of working with the @Data annotation, 
there
will be a @Property annotation instead.

Original comment by warchild...@gmail.com on 16 Aug 2009 at 6:22

GoogleCodeExporter commented 9 years ago 
Correct, it's in the works, there are a few discussion threads in the 
newsgroups about how to get this right, and 
it won't be on Data, it'll be a separate annotation most likely called 
@Property.

Original comment by reini...@gmail.com on 18 Aug 2009 at 12:07

GoogleCodeExporter commented 9 years ago 
Perfect..just a reminder that whatever solution you come up with, it *must* 
allow
overriding which type of PropertyChangeSupport class is used. In Swing apps the
SwingPropertyChangeSupport is necessary, otherwise EDT violations will occur:

http://java.sun.com/javase/6/docs/api/javax/swing/event/SwingPropertyChangeSuppo
rt.html

Original comment by jace...@gmail.com on 18 Aug 2009 at 4:12

GoogleCodeExporter commented 9 years ago 
Don't forget vetoable properties, as per the JavaBeans spec.

(BeanInfo generation via annotations, e.g. for icons, editors etc would be nice 
too!)

Original comment by psc...@gmail.com on 8 Dec 2009 at 11:28

GoogleCodeExporter commented 9 years ago 
Issue 107 has been merged into this issue.

Original comment by reini...@gmail.com on 25 Jul 2010 at 12:24

GoogleCodeExporter commented 9 years ago 
Quick and dirty hack: http://code.google.com/p/lomprop/ - use the @BindableData 
annotation - generates proper getters and setters, methods: 
addPropertyChangeListener, removePropertyChangeListener; and an initialized 
field $propertyChangeSupport. Resulting bean is bindable using JSR-295 (tested 
in NetBeans).

Original comment by Greg.Matoga@gmail.com on 26 Jul 2010 at 5:54