Re: Proper place for functions in KVC paths?
Re: Proper place for functions in KVC paths?
- Subject: Re: Proper place for functions in KVC paths?
- From: John Larson <email@hidden>
- Date: Tue, 29 Aug 2006 17:05:04 -0500
You can think of the keypath as a tokenized string that is
evaluated recursively through the elements toward the end of the
string and the @operators are looking for scalar values to iterate
over and accumulate. So, for
company.people.account.totalLiability where people is the only
array, then email@hiddenLiability would
produce the sum as desired. Suppose, however, that each person
had multiple accounts. The following would also be valid:
email@hiddenemail@hiddenLiability.
Now _that_ is some clever thinking!
The point of this was to not leave the thread with the idea that
there can only be one @operator in a keypath.
And I will also add that it is quite easy to hook into KVC to
implement your own "magic" operators. IIRC, there are some quite
interesting things in Wonder as well as WOOgnl.
Chuck
I don't know if the Wonder project is interested, but I have a class
that takes KVC strings and a source class (i.e. Customer.class) and:
1) tells you if the keypath is in the eomodel or not (i.e. has
@operators or java methods)
2) lets you store max, min, like, equals, and not values for
eoqualifiers at specified key paths (i.e. addToLikeQualifiers
(someValue, "email@hidden");)
3) allows you to store the quals in "hard" and "soft" quals so that
you can reset the soft qualifiers while preserving the hard
qualifiers (i.e. the filter form is cleared).
4) generates a fetch spec based on the values stored in the object
that excludes those qualifiers not fetchable from the db
5) generates an eoqualifier to filter the fetched records for the
fields that aren't in the db
It pretty much all draws on an implementation of takeValueForKeyPath,
takeValueForKey, valueForKeyPath, and valueForKey so it is compatible
with display groups and form fields.
With this in your wo java file:
SSQualBuilder myQualBuilder = new SSQualBuilder(Customer.class);
you can put this in your wod file:
NameFilter: WOTextField {
value = myQualBuilder.likeFields.customerName;
}
and it does the rest. I actually also have an extension of
WODisplayGroup that has one of these built in and does all the
display group stuff too. It's a little rough around the edges, but
it works pretty good for my purposes. It's really nice not to have
to worry about filtering on fields that aren't in the db and
conversely, doing all the filtering in memory.
_______________________________________________
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