first we have a method called "dot()" and now we have "that()"
personally, I've decided to code all my queries as a standard Jeopardy question.
On May 13, 2011, at 12:21 PM, 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
>
>
>
> _______________________________________________
> 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/jtayler%40oeinc.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]
