so after screwing around all day I came up with:
EOQualifier theQualifier =
Book.INSTRUMENT_BOOKS.containsAnyObjectSatisfying(InstrumentBook.INSTRUMENT.in(
Instrument.fetchInstruments(person.editingContext(),
Instrument.PERSON_INSTRUMENTS.dot(PersonInstrument.PERSON.eq(person)), null)));
but just because it works doesn’t make it right, correct?
On Feb 5, 2015, at 4:51 PM, David Avendasora <[email protected]> wrote:
>> On Feb 5, 2015, at 1:38 PM, Theodore Petrosky <[email protected]> wrote:
>>
>> David,
>>
>> I am deliberately not responding to the list. Would you be interested in
>> helping me get my head around this? If yes, what I can do, is when we are
>> complete with this part, I will document it and submit it to the wiki docs.
>>
>> What do you think, I can create a concrete example. The goal would be to add
>> the static EOQualifier methods and create the rules that access them.’
>
> I help with what I can. I’m pretty busy, but qualifiers are kinda my thing.
> :-)
>
> I would really like it if you also posted this to the list as that is where
> a lot of people search.
>
>> like this guy a static method on Person:
>>
>> Person <->> PersonInstrument <<-> Instrument <->> InstrumentBook <<-> Book
>>
>> Then:
>> public static synchronized EOQualifier thatAreForPersonByInstrument(Person
>> person) {
>> return Book.INSTRUMENT_BOOKS.containsAnyObjectSatisfying(
>> InstrumentBook.INSTRUMENT.dot(
>> Instrument.PERSON_INSTRUMENTS.containsAnyObjectSatisfying(
>> PersonInstrument.PERSON.is( person ) ) ) );
>> }
>>
>> how would you create a rule to access use this.
>
> When I’ve done D2W stuff where I don’t want the full list of values for a
> relationship, I used the “restrictedChoiceKey"
>
> 90 : ((pageConfiguration like 'Create*' or pageConfiguration like 'Edit*')
> and (propertyKey = 'book')) => restrictedChoiceKey = "object.availableBooks"
> [com.webobjects.directtoweb.Assignment]
>
> You specify the regular relationship key of the relationship you want to set
> in this case "(propertyKey = 'book’)" , but set the rule’s key to
> "restrictedChoiceKey” and point it to a different keypath that contains the
> qualified (and sorted, if needed) list of valid values, in this case
> “object.availableBooks”. (the “object” in the binding keypath just means to
> look on the same object that the “propertyKey” binding is for.
>
> In the code below, I’m assuming “Person” is also the class that has the
> “book” propertyKey, if it isn’t you’ll just have to change how you get the
> person object.
>
> The method would look something like this:
>
> public NSArray<Book> availableBooks() {
> NSArray<Book> allBooks = [however you get the list of all books from
> the DB];
> EOQualifier thatAreAvailableToPerson =
> Book.thatAreForPersonByInstrument(this);
> MSArray<Book> availableBooks = ERXQ.filtered(allBooks,
> thatAreAvailableToPerson);
> return availableBooks;
> }
>
> That’s really about it.
>
> I hope this helps, and please do post this back to the list in some form!
>
> Dave
>
>>
>> Ted
>>
>> On Feb 5, 2015, at 9:09 AM, David Avendasora <[email protected]>
>> wrote:
>>
>>> ERXExistsQualifier to the rescue!
>>>
>>>> On Jan 29, 2015, at 9:12 AM, Theodore Petrosky <[email protected]> wrote:
>>>>
>>>> The Person has an instrument. The Book has an instrument. so the popup
>>>> list should be only those books with the same instrument.
>>>
>>> To match instances of book that are for an instrument that is related to a
>>> given person:
>>>
>>> If this is your model:
>>> Person <<-> Instrument <->> Book
>>>
>>> Then:
>>> public static synchronized EOQualifier thatAreForPersonByInstrument(Person
>>> person) {
>>> return
>>> Book.INSTRUMENT.dot(Instrument.PERSONS.containsAnyObjectSatisfying( person
>>> ) );
>>> }
>>>
>>> OR If this is your model (seems more likely):
>>>
>>> Person <->> PersonInstrument <<-> Instrument <->> InstrumentBook <<-> Book
>>>
>>> Then:
>>> public static synchronized EOQualifier thatAreForPersonByInstrument(Person
>>> person) {
>>> return Book.INSTRUMENT_BOOKS.containsAnyObjectSatisfying(
>>> InstrumentBook.INSTRUMENT.dot(
>>> Instrument.PERSON_INSTRUMENTS.containsAnyObjectSatisfying(
>>> PersonInstrument.PERSON.is( person ) ) ) );
>>> }
>>>
>>>> But one layer deeper. a Person is assigned to one or many Shows. the Books
>>>> belong to a show. So if Person 1 only play one show and plays viola (I
>>>> know its a handicapped Person), the popup list only shows that one book as
>>>> available to assign.
>>>
>>> Person <->> ShowPerson <<-> Show <->> Book
>>>
>>> public static synchronized EOQualifier thatAreForPersonByShow(Person
>>> person) {
>>> return Book.SHOW.dot(
>>> Show.SHOW_PERSON.containsAnyObjectSatisfying(
>>> ShowPerson.PERSON.is( person ) ) );
>>> }
>>>
>>> And to combine them together:
>>>
>>> public static synchronized EOQualifier thatAreForPerson(Person person) {
>>> return Book.thatAreForPersonByInstrument( person )
>>> .and( thatAreForPersonByShow( person ) );
>>> }
>>>
>>> By making these static methods, not only can you use that in your fetch
>>> specification, but you can also use it to check to see if a book is
>>> available to a person (for example, in validateForSave, or wherever else):
>>>
>>> public boolean isVisibleTo(Person person) {
>>> return thatAreForPerson(person).evaluateWithObject(this);
>>> }
>>>
>>> Dave
>>>
>>>
>>> —————————————————————————————
>>> WebObjects - so easy that even Dave Avendasora can do it!™
>>> —————————————————————————————
>>> David Avendasora
>>> Senior Software Abuser
>>> Nekesto, Inc.
>>>
>>>
>>>
>>>
>>>
>>
>
>
> —————————————————————————————
> WebObjects - so easy that even Dave Avendasora can do it!™
> —————————————————————————————
> David Avendasora
> Senior Software Abuser
> Nekesto, Inc.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
