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 protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to [email protected] > > -- > 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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
