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