On 6/5/06, Marcin Skladaniec <poldwusmoko..mail.com> wrote:
> I'm not sure how overriding getters and setters could stop cayenne
> from working. We are doing that too, and there are no problem (but we
> are using remote persistence).
On a side note, I hope to use remote persistence as well.
> In the first post you mentioned that getting related object does not
> work, now you are mentioning that set method is not running at all.
> What about get method, is it executed ?
The getter is called explicitly, that's not an issue: I placed a
breakpoint in the setter to try and detect how/why my objects get
annulled. The test only proved it doesn't happen the regular way, via
setSomething(null).
> From what I understand your code when you set a value it shall fire
> an event to every listener, but not when you get value. I don't know
> why you would do it this way, what kinds of objects are listening to
> those changes ?
The jgoodies binding framework depends on those kinds of event hooks
and if you think about it, to bind two properties of two beans you
need only be able to hook into their setters - if each bean monitors
the other's property for changes, you can effectively have
synchronized properties, also known as bound properties. Of course,
all the gory details and a lot more is taken care of the binding
framework - you just provide it with beans, controls, whatever.
> > (so
> > that I can bind the beans to my GUI via jgoodies binding).
> I'm probably wrong, but shouldn't you be firing events in DataObjects
> on get() to notify GUI on changes, and listen for events fired in GUI
> to set the values ?
> Marcin
I hope the above explanation covers these other questions, as well.
Basically, a theoretical minimum to enable two-way data-binding is
just a couple of hooks into the methods through which all changes to
the values occur. Nothing more, nothing less.
t.n.a.
> On 06/06/2006, at 1:34 AM, Tomi NA wrote:
>
> > On 6/5/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> >>
> >> On Jun 5, 2006, at 5:00 PM, Tomi NA wrote:
> >>
> >> > However, the complex event sequences, usage of a databinding
> >> framework
> >> > coupled with classes generated with a modifed superclass template
> >> > create a fairly hard to follow interaction. The breakpoint in the
> >> > setToObjectGroup() method never catches anything, for instance.
> >> It is
> >> > the usage environment that somehow nullifies parts of the object
> >> > graph...
> >>
> >> You can go one step down - override 'DataObject.writeProperty' and
> >> log the output when the property is 'toObjectGroup' and value is
> >> 'null' (or even call Thread.dumpStack() to get the full stack trace
> >> of the call).
> >
> > How would this provide more information than monitoring
> > setToObjectGroup() execution? Where is writeProperty used outside of
> > the setters?
> > Still, I tried it and it isn't called. I just still receive null
> > values. And it very amusing: I set the wanted object group in a
> > dropdown, start the search for all object of the group and get the
> > objects, but they can't reach back to the group (which they try to do
> > when they display information about themselves).
> > I overrid it like so (my break point on the "if" statement never
> > caught anything):
> >
> > public void writeProperty(String propName, Object val) {
> > super.writeProperty(propName, val);
> > if (val == null) {
> > Thread.dumpStack();
> > }
> > }
> >
> >
> >> If you still don't see any suspect invocations, this is probably
> >> something related to serialization.
> >
> > Funny you should mention that: this is the first project I'm using
> > serialization and plan to use it much more. To that end, I extended
> > DataObject with a custom readResolve method:
> >
> > protected Object readResolve() throws ObjectStreamException {
> > DataContext dc = Util.getDataContext();
> > return dc == null ? this : dc.localObject(getObjectId(), this);
> > }
> >
> > Still, judging from the wheres and hows I got null values, this does
> > not seem to be the problem.
> >
> > I appreciate the help.
> > t.n.a.
>
>
This archive was generated by hypermail 2.0.0 : Mon Jun 05 2006 - 18:14:55 EDT