Re: valueForKey(...) from within takeStoredValueForKey(...) = infinite loop
Re: valueForKey(...) from within takeStoredValueForKey(...) = infinite loop
- Subject: Re: valueForKey(...) from within takeStoredValueForKey(...) = infinite loop
- From: Fabian Peters <email@hidden>
- Date: Wed, 16 Jan 2008 23:52:38 +0100
Hi Florijan,
Am 16.01.2008 um 22:08 schrieb Florijan Stamenkovic:
Sorry for the confusion...
My current setup is to have a common superclass that only provides
the capability to fire events, but does not do it. It requires
subclasses to define setter methods that do fire events.
What I want is an EOGenericRecord record subclass that will fire
events by itself, without the need for setters to do it... I hoped
this could be achieved by overriding:
public void takeStoredValueForKey(Object value, String key)
protected void includeObjectIntoPropertyWithKey(Object eo, String key)
protected void excludeObjectFromPropertyWithKey(Object eo, String key)
That way I would not even need to have subclasses of it for every
entity, if I didn't want to. I am just not sure this is at all
possible.
Ok, I see. That's what I wanted as well - but once I ran into EOF
doing its magic via takeStoredValueForKey I looked elsewhere. I'm not
sure whether there'd be a way to do what you want. I decided it'd be a
lot less risky to go the setter route, given my very limited knowledge
of EOF innards. :-)
cheers,
Fabian
My best,
Flor
On Jan 16, 2008, at 16:54, Fabian Peters wrote:
Hi Florijan,
Am 16.01.2008 um 21:08 schrieb Florijan Stamenkovic:
Hi Fabian,
Thanks for the reply. This is (more or less) what I am doing now.
I have a method provided in the common superclass that fires the
event, the only difference from your approach is that I do it
after the change has occurred. What I wanted to do was get rid of
the EOGenerator / custom setter dependancy... End goal being event
firing without the need for per-entity subclasses that keep doing
the same thing anyway.
I think I don't really get your point? As I understand this, you
would need a common superclass anyway, even if overriding
takeStoredValueForKey would be ok. If you've got a requirement
shared by all your EOs to react on the change of any attribute, you
could handle it in the superclass?
From your post I assume this didn't work for you?
Well, I'm happy with the current setup, it served me well.
Fabian
On Jan 16, 2008, at 15:31, Fabian Peters wrote:
I've been down that road as well. storedValueForKey is used
behind the scenes by EOF. I ended up putting a method in a common
superclass:
public void willChange(Object oldValue, Object newValue, String
key) {
// to be used by subclasses
}
And then placing this in the setters created by EOGenerator:
willChange(storedValueForKey("theKey"), value, "theKey");
When I need this fine-grained change tracking on an EO, I fill in
the willChange() method.
HTH,
Fabian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden