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      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to