Dave, Thanks for your answer, seems to be an interesting approach. I will read up on QueryDataSourceDelegate. I was already thinking about doing stuff in nextPageDelegate.
Btw I like your "job title" (I often see myself as an (ab)user as well) ---markus--- On 12.12.2013, at 18:02, David Avendasora <[email protected]> wrote: > 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]
