Re: [Somewhat OT] Code organization question
Re: [Somewhat OT] Code organization question
- Subject: Re: [Somewhat OT] Code organization question
- From: Stamenkovic Florijan <email@hidden>
- Date: Sat, 28 Mar 2009 12:15:45 -0400
Hi Lachlan,
On Mar 28, 2009, at 06:55, Lachlan Deck wrote:
You've described how they're used, which is all cool, but the
particular problem you're trying to solve sounds like it's more to
do with how they're initialised.
Yes, it does. Read on...
So the normal EOClassDescription, for example, is usually derived
from the model and is therefore loaded at runtime from the plist
definitions.
In a JC situation a class description is loaded from the server, which
loads it from the model. The model itself is not available on the
client.
I'm guess that you have something else happening (e.g., definitions
in code rather than plist?)
Definitions of what? Derived properties? Yes, they only are in code. I
do not define my derived properties in the model because EOF's derived
prop system is not capable of doing what I need done. As for
manipulating the class descriptions in code, nope, I don't do that.
DataType interface (JBND equivalent of EOClassDescription) among
other things defines some method:
<...>
public void addDerivedProp(String key, PropType type, Class<?>
propClass,
String... derivedFromProps);
<...> public Set<String> propsDerivedFrom(String key);
Then this info is queried by EOs, which use it in the following way:
- the constructor of EOFDataObject (EO superclass) checks the info
in it's DataType to see if there are derived properties that depend
on keypaths. If there are, it schedules the creation of
KeyPathChangeManagers. Those are objects made to observe changes
happening on trees of inter-related objects, defined by a keypath.
EOFDataObject uses a specialized KeyPathChangeManager subclass that
reports the changes on the path back to the EO that created it.
When a relevant change is detected, a change event is fired for the
property that is derived from the keypath, resulting in the
clearing of it's cache.
Aha. This is the crux of the problem: the need to observe changes of
derived properties destinations.
Perhaps DataType - which is the conceptual representation of the
type - is not the right place for initialising keypath observance
implementations.
Well, the DataType stores this information. It does not initialize it.
Please see below.
This could be trigged, for example, from the first
awakeFrom[Insertion|Fetch] for each entity perhaps?
Yes! This is exactly what I am doing :) I inform the DataType of the
derived props for that DataType, on the first init of an EO of that
type. I do it from the constructor. It is safe to do in the
constructor as this process does not involved any EOF work in the EO
itself.
You might thing that awakeFromFetch could be a better option because
it would enable me to immediately initialize keypath change observers.
This would be ideal, but unfortunately it does not work, I tried it
out. For some convoluted reason that my hung-over head can't exactly
remember... The initialization of observing the object graph that
defines a derived property works properly only if done at a later
point, such as valueForKey, which is why I do it there.
I believe now you can see exactly what I meant in the first post... In
essence we came up with the same solution to the problem... Now, my
first post also describes why I don't like it too much, even though
it's fully functional. Which brings us back to the original question:
any thoughts on improving this?
Thanks,
F
_______________________________________________
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