Re: typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
Re: typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
- Subject: Re: typesafe and chainable keypaths (was: Re: EOSortOrdering and keypaths [SOLVED])
- From: Marc Guenther <email@hidden>
- Date: Mon, 21 Jun 2010 22:40:12 +0200
On 21.06.2010, at 18:46, Chuck Hill wrote:
> On Jun 21, 2010, at 8:39 AM, Marc Guenther wrote:
>> 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()
>
> I like that! I was thinking of using the model info to try and implement something like:
>
> Booking.keyPathTo(PerformanceType.NAME).
Yea, but doing this at runtime wouldn't give you all this type safety stuff explained below.
> Though it would probably have to be more verbose:
> Booking.keyPathTo(PerformanceType, PerformanceType.NAME).
And no autocompletion either, which is way cool :)
Marc
> Or is that
> Booking.keyPathTo(PerformanceType().NAME()).
>
>
> Chuck
>
>> 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
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
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