• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Need help in building a pretty complex EOQualifier
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need help in building a pretty complex EOQualifier


  • Subject: Re: Need help in building a pretty complex EOQualifier
  • From: David Avendasora <email@hidden>
  • Date: Thu, 12 Dec 2013 12:02:50 -0500

Hey Marcus,

I’ve tried out D2W several times, but I always run into things like this where D2W just seems to get in the way, or makes things more complicated. But with that said, forcing you to do things differently isn’t always a bad thing!

I think you can still do what you want, you just have to make D2W your bit… er… um… take control of how D2W does searching for the Document entity.

I don’t implement the ID2WExpertDave interface, so one of those Daves may have a better method for doing this, but here’s my best shot:

I believe you want to use a QueryDataSourceDelegate (see: http://wiki.wocommunity.org/display/documentation/D2W+Flow+Control) to intercept the the search before it gets to the results page. This will allow you to access the EOQualifier built by the search form and also take over control of how the fetch is done, and even do things *after* the fetch to the EODataSource. As far as the query page knows, it handed off the EOQualifier it was supposed to and as far as the results page knows, it got the EODataSource it was expecting. The fact that you had your way with it 9-ways from Sunday in-between is completely encapsulated.

This is actually one of the REALLY, REALLY cool things about D2W, it forces you to put your business logic where it belongs; in the Controller and Model layers. The view layer is, in general, off-limits to you because it is dynamically generated by the rule engine.

BTW, QueryDataSourceDelegates are very handy. They’ll also let you apply additional qualifiers to a search so you can automatically filter out any results that the user shouldn’t see based on permissions or any other criteria you can think up. Also, you can combine it with a nextPageDelegate to automatically return the Inspect or Edit page instead of the List page if the user’s search only returns one row, or if the rows are all of a particular “type”, or, or, or!

Good luck!

Dave Avendasora

On Dec 12, 2013, at 11:31 AM, Markus Ruggiero <email@hidden> wrote:

Dave

great, thanks alot for your input. 

BUT, yes, there always is a BUT....

This query is created within a D2WQuery page. Executing the query actually just makes the displayGroup for the resulting D2WListPage perform the fetch - and that's where the BUT is. This displayGroup has a qualifier and that's the qualifier I try to build. I see no way to split the fetch into two parts and execute the second part based on the result of the first part. Any idea on that?

I know, I am asking weird things, but (again a BUT), the customer says what he wants, I _simply_ have to do it  :-(

---markus---

PS Maybe I simply go and fetch manually any fitting document during the loop over DocumentText query criteria and build a list of Documents, so that when all query values have been collected the resulting list is already created. I can then create an IN qualifier and pass that to the D2WListPage. Hey, that would make the customer suffer (performance wise, he deserves it! Why is he asking for such functionality in the first place! Yeah!)


On 12.12.2013, at 17:15, David Avendasora <email@hidden> wrote:

Hi Markus,

The problem is that you can’t do what you are trying to in one step because there are likely several DocumentText objects that match each of your criteria which is going to cause the problems you are seeing. 

You will have to evaluate the criteria one at a time, but first you have to figure out which criteria can combine into single Qualifiers/Clauses, and which have to be evaluated independently.

I find it much easier to create each qualifier individually, using descriptive of names as possible, then combine them together so it all reads as a sentence. It helps make complicated qualifiers like this more obvious to write, and later come back and read.

 all Documents where the assignment to Text "A" has comment "x” 
seems like criteria that can be combined like so:

 assignment to Text "A"  
ERXKeyValueQualifier thatAreForTextA = DocumentText.TEXT.eq(“A”)
has comment "x” 
ERXKeyValueQualifier thatAreForCommentContainsX = DocumentText.COMMENT.contains(“x”);
assignment to Text "A" has comment "x” 
ERXAndQualifier thatAreForTextAandCommentContainsX = thatAreForTextA.and(thatAreForCommentContainsX);

Now we will create a qualifier for Document objects that are related to **at least one** DocumentText that match this set of criteria:
ERXExistsQualifier thatMatchTheFirstSetOfCriteria = new ERXExistsQualifier(DOCUMENT_TEXTS, thatAreForTextAandCommentContainsX);


 AND the assignment to Text "B" has status "y”.
This also seems like criteria that can be combined.

 assignment to Text "B" 
ERXKeyValueQualifier thatAreForTextB = DocumentText.TEXT.eq(“B”)
 has status "y”.
ERXKeyValueQualifier thatAreForStatusY = DocumentText.STATUS.eq(“y”);
 assignment to Text "B" has status "y”.
ERXAndQualifier thatAreForTextBandStatusY = thatAreForTextB.and(thatAreForStatusY);

Now we will create another qualifier for Document objects. This one will find instances that are related to **at least one** DocumentText that match the this second set of criteria:
ERXExistsQualifier thatMatchTheSecondSetOfCriteria = new ERXExistsQualifier(DOCUMENT_TEXTS, thatAreForTextBandStatusY);


Now comes the two-step part:

First, fetch the Document objects that are related to **at least one** DocumentText that match the *first* set of criteria:
NSArray<Document> documentsForTheFirstSetOfCriteria = Document.fetch(thatMatchTheFirstSetOfCriteria);

Now, filter the that array for ones that are also related to **at least one** DocumentText that match the *second* set of criteria
NSArray<Document> documentsForTheFirstAndSecondSetsOfCriteria = ERXQ.filtered(documentsForTheFirstSetOfCriteria, thatMatchTheSecondSetOfCriteria);

Done. “documentsForTheFirstAndSecondSetsOfCriteria" will have … wait for it … Document objects that match both sets of criteria!

Another way to write (in English) what this does is:

"The user wants to see all Documents that are related to at least one DocumentText that has a Text of “A” and a comment of “x” and the Documents must also be related to at least one DocumentText that has a Text of “B” and a status of “y”."

Dave Avendasora

On Dec 12, 2013, at 8:56 AM, Markus Ruggiero <email@hidden> wrote:

Now comes the qualifier to retrieve Documents: The user sees a D2WQueryPage for the document properties with an embedded property level query component that presents the full list of possible DocumentText objects with their status and comment fields. A typical scenario could be: the user wants to enter a comment query for the second assigned text (that's Text "A") and/or picks a query value for the status of the 7th assigned text (this could be Text "B"). Upon executing the query the user expects to retrieve a list of Documents that fulfill all given criteria. In this example the user wants to see all Documents where the assignment to Text "A" has comment "x" AND the assignment to Text "B" has status "y".


—————————————————————————————
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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Need help in building a pretty complex EOQualifier
      • From: Markus Ruggiero <email@hidden>
References: 
 >Need help in building a pretty complex EOQualifier (From: Markus Ruggiero <email@hidden>)
 >Re: Need help in building a pretty complex EOQualifier (From: David Avendasora <email@hidden>)
 >Re: Need help in building a pretty complex EOQualifier (From: Markus Ruggiero <email@hidden>)

  • Prev by Date: Re: Need help in building a pretty complex EOQualifier
  • Next by Date: Re: Need help in building a pretty complex EOQualifier
  • Previous by thread: Re: Need help in building a pretty complex EOQualifier
  • Next by thread: Re: Need help in building a pretty complex EOQualifier
  • Index(es):
    • Date
    • Thread