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