Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proper place for functions in KVC paths?





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:
http://lists.apple.com/mailman/options/webobjects-dev/email@hidden


This email sent to email@hidden
References: 
 >Proper place for functions in KVC paths? (From: "John Huss" <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: Chuck Hill <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: Lachlan Deck <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: Chuck Hill <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: Lachlan Deck <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: John Larson <email@hidden>)
 >Re: Proper place for functions in KVC paths? (From: Chuck Hill <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.