| I'd recommend doing your search directly on the database using an EOQualifier, then set the found set for the display group. One of the easiest ways of doing this is via a named fetch spec in EOModeler.
For example, create a named fetch spec called "QuickSearch" in EOModeler, which searches all sorts of attributes and relationships for a string binding called "$q".
Then you can find matching records using the code:
public static NSArray objectsForQuickSearch(EOEditingContext context, String qBinding) { EOFetchSpecification spec = EOFetchSpecification.fetchSpecificationNamed("quickSearch", "MyEntityName");
NSMutableDictionary bindings = new NSMutableDictionary();
if (qBinding != null) bindings.setObjectForKey(qBinding, "q"); spec = spec.fetchSpecificationWithQualifierBindings(bindings);
return context.objectsWithFetchSpecification(spec); }
I use EOGenerator to auto-generate methods like the above for every named fetch spec, saves a lot of typing.
Once you have an NSArray of found records, you set it right in the display group by calling displayGroup.setObjectArray(foundSet)
Some might see this as a hack, since it bypasses the datasource and qualifier mechanism for the displayGroup, and uses the displayGroup only for displaying, not fetching. On Jul 16, 2006, at 8:53 PM, John Larson wrote: Hi David,
It is important to realize that when using qualifyDataSource, the dg is going to try to qualify via sql qualifiers. If the attributes that you are searching on aren't in the db, then you get this error. I should qualify this by saying that this happens when you use the standard dg construction tools provided by wobuilder, et al. This contrasts with qualifyDisplayGroup which is going to do in-memory filtering, and therefore the object will have programmed attributes available to filter against.
Since I assume that you are using a mix of db reachable attributes and programmed attributes, you may have to dig a little deeper. For instance, you may have to bind your filter fields against fields in the java file, then programatically set the querymatch, etc. arrays for db fields, execute qualifyDataSource, then set the programmatically reachable fields and execute qualifyDisplayGroup to filter down to the items. This has the negative effect of leaving the dg's allObjects field populated with the elements from the db fetch. Or, you could create your own fetch spec using the db reachable fields, filter on the results to result in an array, and then set the dg's data source as an arrayDataSource with the resultant array as the arrayDataSource's array. There's about 800 different ways to do this, and we'd need to know more about how flexible you want this to be, etc. to continue.
Personally, I created a dg subclass and datasource subclass where in each class I specify a series of strings that I want to make available for db or in-memory filtering, and then have the sql and in-memory qualifiers created automatically using the standard queryMatch, min, max, etc. This was a fun project, but it makes me wonder why since the model knows the attributes that are part of the db model and the other attributes that aren't, why couldn't dg figure it out on its own.
Oh well, probably a Project Wonder problem. (?)
John On Jul 14, 2006, at 7:03 PM, David Holt wrote: I am using DisplayGroups which make queries on individual attributes very easy.
I would like to provide a simple search where one text field returns a search on a concatenation of several attributes of the entity. I just tried putting the following code in my EO to try this concept out (title and author are attributes in the entity):
public String simpleSearch() { String author = author(); String title = title();
String simpleSearch;
if ((author != null) && (!author.equals(""))) { simpleSearch = author + " " + title; } else { simpleSearch = title; }
return simpleSearch; }
When I try and do a queryMatch on the simpleSearch field I get an error: java.lang.IllegalStateException: sqlStringForKeyValueQualifier: attempt to generate SQL for com.webobjects.eocontrol.EOKeyValueQualifier (simpleSearch caseinsensitivelike '*test*') failed because attribute identified by key 'simpleSearch' was not reachable from from entity 'Document'
I assume this is because the attribute "simpleSearch" is not actually in the database. Is there a better strategy for searching concatenated fields using DisplayGroups?
Thanks, David _______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
