Re: More Readable EOQualifiers
Re: More Readable EOQualifiers
- Subject: Re: More Readable EOQualifiers
- From: David Avendasora <email@hidden>
- Date: Fri, 13 May 2011 14:17:36 -0400
On May 13, 2011, at 12:32 PM, Ramsey Gurley wrote:
>
> On May 13, 2011, at 9:21 AM, David Avendasora wrote:
>
>> Hi all,
>>
>> I've been doing a lot of work with EOQualifiers in the past few months, and while the new ERXKey-based, chainable qualifiers are a huge leap ahead of the standard EOQualifiers in terms of readability and clarity, they have always seemed just short of ideal. I believe I've come up with an improvement, but I want to get everyone's opinion first. Yes, even yours, Anjo. I'm ready. ;-)
>>
>> First, let me give you a basic use case.
>>
>> I have two Entities:
>> 1) School
>> 2) Student
>>
>> Their relationship to each other is: School <->> Student (Shhh! it's just an example. Let's not complicate things.)
>>
>> Now, let's say for a given school, I want all the active, red-headed students. Here's the way I originally learned (shudder):
>>
>> EOQualifier qual1 = EOQualifier.qualifierWithQualifierFormat("hairColor=%@", new NSArray("Red"));
>> EOQualifier qual2 = new EOKeyValueQualifier("isActive", EOQualifier.QualifierOperatorEqual, true);
>> NSArray studentQualifier = new NSMutableArray();
>> studentQualifier.add(qual1);
>> studentQualifier.add(qual2);
>> EOQualifier studentQualifiers = new EOAndQualifier(studentQualifier);
>> NSArray redheadedStudents = mySchool().students(studentQualifiers);
>>
>> Horribly unreadable, with lots of grunt-work to get things setup before you can even use the qualifier for anything! That and incredibly unsafe due to the use of "Magic Strings" that will break, but only at runtime when you change anything in the model (sure, there's ways around that, but they usually make the code even less readable).
>>
>> Then along came ERXKey chainable qualifiers and you could do it all with one (reasonable) line of code:
>>
>> NSArray<Student> redheadedStudents = mySchool.students(Student.IS_ACTIVE.isTrue().and(Student.HAIR_COLOR.eq("Red")));
>>
>> Which is pretty darn readable. Hugely better than the original way. HUGELY. But yet... you still need to spend a bit of time interpreting it when you first come across it.
>>
>> My new strategy combines still doing some setup, but the setup is explicitly for making things easier to read.
>>
>> EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);
>> EOQualifier areActive = Student.IS_ACTIVE.isTrue();
>> NSArray redheadedStudents = mySchool().students(Student.that(haveRedHair).and(areActive));
>>
>> "But where did the 'that(EOQualifier)' come from?" you ask?
>>
>> That's (no pun intended) the key (oh, wow. I'm on a roll!) to the improvement.
>>
>> I have added the following simple method to my EOGenericRecord subclass:
>>
>> public static ERXAndQualifier that(EOQualifier qualifier) {
>> return new ERXAndQualifier(new NSArray<EOQualifier>(qualifier));
>> }
>>
>> Basically, all this method does is coerce a standard EOQualifier into a chainable one (IERXChainableQualifier) and uses a conjunction to better tie the qualifier(s) to the Entity that they are qualifying. My #1 goal was to make places where I use qualifiers as sentence-like as possible, and I think Student.that(haveRedHair).and(areActive) is very readable.
>>
>> So, what do you all think? Is there some flaw inherent in the system? Am I missing something? Would it be worth putting into ERXGenericRecord?
>>
>> Dave
>
>
> I think, me personally, I'd just go with
>
> NSArray redheadedStudents = mySchool().students(haveRedHair.and(areActive));
That's nice and all, but you can't create haveRedHare as an instance of EOQualifier, you'd have to use a specific subclass that implements IERXChainableQualifier. You can't chain .and() onto the end of an plain-jane EOQualifier. I was also going for consistency, so the next person looking at my code won't have to wonder why I declared the first qualifier differently from all the others.
Dave
>
> because it's shorter. But then, I cut my teeth on AppleScript... English-like syntax isn't all it's cracked up to be sometimes (^_^)
>
> Ramsey
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
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