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: Chuck Hill <email@hidden>
- Date: Mon, 21 Jun 2010 09:46:29 -0700
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).
Though it would probably have to be more verbose:
Booking.keyPathTo(PerformanceType, PerformanceType.NAME).
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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