Re: [Somewhat OT] Code organization question
Re: [Somewhat OT] Code organization question
- Subject: Re: [Somewhat OT] Code organization question
- From: Lachlan Deck <email@hidden>
- Date: Sat, 28 Mar 2009 21:55:02 +1100
Hi Florijan,
On 27/03/2009, at 8:36 AM, Stamenkovic Florijan wrote:
On Mar 26, 2009, at 16:51, Lachlan Deck wrote:
Nothing else at this time. Perhaps a little more explanation about
your derived properties mechanism will trigger some extra thinking.
Sure, here is how it works, as briefly as possible...
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.
So the normal EOClassDescription, for example, is usually derived from
the model and is therefore loaded at runtime from the plist
definitions. I'm guess that you have something else happening (e.g.,
definitions in code rather than plist?)
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.
This could be trigged, for example, from the first awakeFrom[Insertion|
Fetch] for each entity perhaps?
i.e., there's nothing to observe if the destination of a derived
property isn't even in memory as yet right?
- valueForKey is overridden to check if the key points to a derived
property. If so, the cache is queried for a value, which is
returned. If there is no cached value, then the derived prop is
evaluated using EOF's KVC, and cached. valueForKey also initializes
the KeyPathChangeManagers that were scheduled for creation in the
constructor. This needs to happen here, because only here it is
guaranteed that the object graph defined by the keypath is fully
initialized. Also, since this can be an expensive operation, it is
not bad to initialize it lazily.
- the even firing mechanism of JBND (the DataObject aspect of it)
ensures two things:
a) When a change in any of the variables of a derived prop is
detected, a change event is fired for the derived prop too
b) When a change event for a derived prop is fired, the prop's
cached value is cleared
There are additional uses for the info about a derived property that
is given to a DataType.
- The PropType argument (PropType is an enumeration declared in the
DataType interface) is used to define if the property is an
attribute, a to-one or a to-many, or a derived attribute, to-one, to-
many. It is queried at various points in JBND to ensure appropriate
behavior.
- The property class argument is only applicable to derived
attributes, and is also queried throughout JBND where it is desired
or beneficial to know the value type for an attribute.
JBND does not deal with actual property derivation. It is not
interested in property definitions. In my opinion that would only
weaken it. Instead, the evaluation of derived properties happens in
EO methods, which are accessed through standard KVC. JBND just wants
to know about them to ensure they are properly handled, and to deal
with caching.
Sure. But it's all about when...
JBND has to know about all derived properties, as otherwise it might
encounter a key it can't interpret. In that sense I might have to
provide a per derived prop switch to control weather caching should
be done for the value or not. However, this is a performance
optimization that *might* be necessary, so I did not build that in
yet. Something to think about... Most likely this would be done by
checking the number of arguments passed to the addDerivedProp(...)
method. If it was given no info on which props a derived property is
made from, caching for that property should be disabled.
This pretty much covers it.
F
p.s. - this is not present in the current distribution of JBND. It
is coming out in 0.92. It is done, except for the caching control
mentioned above. And it could use a bit more testing. So far it
works OK, but I have not tested it extensively.
with regards,
--
Lachlan Deck
_______________________________________________
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