Feature Requests item #682592, was opened at 2003-02-07 23:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=428711&aid=682592&group_id=40712
Category: codegen
Group: None
Status: Open
Priority: 5
Submitted By: Max R. Andersen (maxcsaucdk)
Assigned to: Max R. Andersen (maxcsaucdk)
Summary: Have hbm2java generate support for veto and change listeners
Initial Comment:
How about adding somemore JavaBeans Functionality,
namely the PropertyChange- and
VetoableChangeMechanism.
I envision something like
<property ... changeType="[bound|constraint]" />
which would lead to the incorporation of the appropriate
SupportClass and the Eventfiring code to the setter
Methods.
Specifically I am refering to
1) the hibernate codegenerator
2) JavaBeans Spec. 1.0.1 Sect. 7.4
Thus the SupportClass is given by the appropriate classes
in the beans package;
the code should look somewhat like this:
import java.awt.*;
import java.beans.*;
public class JellyBean {
public Color getColor() {
return ourColor;
}
public void setColor(Color newColor) {
Color oldColor = ourColor;
ourColor = newColor;
changes.firePropertyChange( color , oldColor, newColor);
}
public int getPriceInCents() {
return ourPriceInCents;
}
public void setPriceInCents(int newPriceInCents) throws
PropertyVetoException {
int oldPriceInCents = ourPriceInCents; // First tell the
vetoers about the change. If anyone objects, we
// let the PropertyVetoException propagate back to our
caller.
vetos.fireVetoableChange( priceInCents , new
Integer(oldPriceInCents), new Integer(newPriceInCents));
// No one vetoed, so go ahead and make the change.
ourPriceInCents = newPriceInCents;
changes.firePropertyChange( priceInCents , new
Integer(oldPriceInCents), new Integer(newPriceInCents));
}
public void
addPropertyChangeListener(PropertyChangeListener l) {
changes.addPropertyChangeListener(l);
}
public void
removePropertyChangeListener(PropertyChangeListener l)
{
changes.removePropertyChangeListener(l);
}
public void
addVetoableChangeListener(VetoableChangeListener l) {
vetos.addVetoableChangeListener(l);
}
public void
removeVetoableChangeListener(VetoableChangeListener l)
{
vetos.removeVetoableChangeListener(l);
}
private PropertyChangeSupport changes = new
PropertyChangeSupport(this);
private VetoableChangeSupport vetos = new
VetoableChangeSupport(this);
private Color ourColor = Color.orange;
private int ourPriceInCents = 2;
}
See
https://sourceforge.net/forum/forum.php?thread_id=8097
53&forum_id=128638
for the glory details :)
----------------------------------------------------------------------
Comment By: Klaus Zimmermann (zklaus)
Date: 2003-02-10 23:21
Message:
Logged In: YES
user_id=171184
I'm done.
How shall I submit the Patch?
----------------------------------------------------------------------
Comment By: Max R. Andersen (maxcsaucdk)
Date: 2003-02-08 13:39
Message:
Logged In: YES
user_id=18119
It should be done in Hibernate2.
<meta> is only in Hibernate2.
----------------------------------------------------------------------
Comment By: Klaus Zimmermann (zklaus)
Date: 2003-02-08 13:11
Message:
Logged In: YES
user_id=171184
thanks.
I'll give it a try.
One more question:
Should such development take place
in hibernate2 or is there still active development
in hibernate(1)?
----------------------------------------------------------------------
Comment By: Max R. Andersen (maxcsaucdk)
Date: 2003-02-08 13:01
Message:
Logged In: YES
user_id=18119
You are right - it should not affect Hibernate's construction of
the objects as long as you do not assign veto-listeners that
would complain to it in Interceptor.newInstance()...
so, it is probably no problem....and if you want to submit a
patch then please do :)
Tips for the patch: use <meta> tag's and remember that
<meta> tag's are structurally "inherited" from the viewpoint of
hbm2java. Meaning that if you put in <meta
attribute="bean-changetype">constrained</meta> in <class>,
all properties will have this meta value (unless they of course
overload it :)....just mentioning it .....
----------------------------------------------------------------------
Comment By: Klaus Zimmermann (zklaus)
Date: 2003-02-08 12:39
Message:
Logged In: YES
user_id=171184
P.S.: I saw this assigned to you.
However I'd like to work on it, of course. ;)
----------------------------------------------------------------------
Comment By: Klaus Zimmermann (zklaus)
Date: 2003-02-08 12:38
Message:
Logged In: YES
user_id=171184
Correct me if I'm wrong but I thought the lifecycle of a
typical perstistence Object was something like this:
1) [load|instatiate]
2) work with it
3) [update|save]
4) [goto 2|destruct]
That's why I thought that it was safe to extent the
setFoo(FooType a)
Method to something like
public void setFoo(FooType a) {
vetos.fire(...);
foo=a;
change.fire(...);
}
So I don't really understand where hibernate might get
disturbed.
----------------------------------------------------------------------
Comment By: Max R. Andersen (maxcsaucdk)
Date: 2003-02-07 23:23
Message:
Logged In: YES
user_id=18119
Will probably be done via <meta>'s if at all doable.
As I remember hibernate is not that fund of being "disturbed"
while setting properties on an object! Thus is it at all valid to
have veto-support ? (changelisteners is also arguable since
hibernate "changes" the properties on each construction of an
object....maybe not an problem since no listeners can be
"online" before after the creation of the object.....
comments ?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=428711&aid=682592&group_id=40712
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
