On May 13, 2011, at 1:33 PM, Chuck Hill wrote:
> Hi A David,
>
>
> 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,
>
> Congratulations, that must feel very satisfying!
Oddly, you know, it does.
>> 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. ;-)
>
> Be careful of what you wish for.
Eh. I've been getting an earful from you people for the past 6 years. Note: I'm
not sure which that says more about, my self confidence, or your inability to
get rid of annoying people.
>> 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);
>
> EOQualifier studentQualifiers = new EOAndQualifier(new NSMutableArray(new
> EOQualifier[]{qual1, qual2});
Oooooh! Yes. Much more readable.
>> NSArray redheadedStudents = mySchool().students(studentQualifiers);
>>
>> Horribly unreadable,
>
> Read: "it makes my lips hurt!"
Your lips hurt, and you know what Hugi's tongue feels like. Does Nok know about
all this?
>> 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?
>
> I am all for more readable, so I have no objection to this being in Wonder.
> Though Ramsey also had a good point about English syntax sometimes being less
> than optimal.
Yes, point taken there. Maybe I should change it to the Spanish: cual() which
happens to be pronounced Qual, which warms the cockles of my heart. Maybe below
the cockles, maybe in the sub-cockle area.
> Now what would be REALLY cool is if you could get the templates to
> pre-generate qualifiers like:
Well, I was thinking about creating them for the attributes defined as
booleans... That would be pretty straight forward. The trick is knowing what
the possible values are for other attributes. If that were defined in the
userInfo dictionary then it should be easy to create those qualifiers. The
templates read out the qualifiers defined for fetch specs as it is. They just
don't make them stand-alone static variables.
Dave
>> EOQualifier haveRedHair = Student.HAIR_COLOR.eq(MyAppConstants.RED_HAIR);
>> EOQualifier areActive = Student.IS_ACTIVE.isTrue();
>
>
>
> Chuck
>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Come to WOWODC this July for unparalleled WO learning opportunities and real
> peer to peer problem solving! Network, socialize, and enjoy a great
> cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
>
_______________________________________________
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]
