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: Thu, 26 Mar 2009 17:36:44 -0400
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...
DataType interface (JBND equivalent of EOClassDescription) among other
things defines some method:
/**
* Adds meta-information about a derived property, does <b>not</b>
accept a
* property definition. This meta-info could (and should) be used for
* derived property value caching, to reduce the overhead involved in
* calculating a derived property every time it is asked for. The info
* (specifically the derived property type and class) is used
throughout
* JBND where such info is required...
*/
public void addDerivedProp(String key, PropType type, Class<?>
propClass,
String... derivedFromProps);
/**
* Returns a <tt>Set</tt> of keys designating properties that are
derived
* from the given <tt>key</tt>, or <tt>Collections.EMPTY_SET</tt> if
there
* aren't any.
*
* @param key The key that might be used in the derivation of any
number of
* derived properties.
* @return See above.
*/
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.
- 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.
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.
_______________________________________________
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