typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
- Subject: typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
- From: Marc Guenther <email@hidden>
- Date: Mon, 21 Jun 2010 17:39:37 +0200
Hi,
On 20.06.2010, at 18:47, Andrew R. Kinnie wrote:
[...] So now I have Booking.PERFORMANCE_KEY + "." +
Performance.PERFORMANCE_TYPE_KEY + "." + PerformanceType.NAME_KEY
Last year I cobbled together a little extension to the ERXKey stuff,
which allows you to create ERXKey paths like this:
Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME()
which is almost as clear to read as the hardcoded version:
Though really, hardcoding it as performance.performancType.name
seems MUCH clearer. :-/
but it will catch typos :) and allows you to auto-complete through key
paths, which is really nice.
So you can create an ascending sort ordering like this:
Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME().ascs()
or a qualifier:
Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME().eq(someName)
It also has the added benefit of being type safe, so for example a
myBooking.valueForKeyPath(Booking.PERFORMANCE.PERFORMANCE_TYPE
().NAME())
will return a String, or the hypothetical to-many keypath
myBooking.valueForKeyPath(Booking.ITEMS.NAME())
would return an NSArray<String>. Calling it on the wrong object type
or with valueForKey() is a compiler error:
mySomethingElse.valueForKeyPath(Booking.PERFORMANCE.PERFORMANCE_TYPE
().NAME()) // won't compile
myBooking.valueForKey(Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME
()) // won't compile
The valueInObject() method also works:
Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME().valueInObject
(myBooking)
and returns a String, as expected. Giving it an NSArray instead
Booking.PERFORMANCE.PERFORMANCE_TYPE().NAME().valueInObject
(allBookings)
of course returns an NSArray<String>. So you don't need
arrayValueInObject() anymore. Ditto for
Booking.ITEMS.NAME().valueInObject(myBooking)
which returns an NSArray<String> because of the to-many relation in
the key path.
I never came around to posting this, cause:
- it's based on a legacy eogenerator template
- it does incompatible changes to Wonder's ERXKey (adds another type)
but if there is interest, I can clean this up, update to the current
Wonder implementation and current eogenerator and post it.
We are using it for over a year now, and it works great.
Marc
_______________________________________________
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