The search UI must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
1) I do not understand what it means by "search the data for all records"?
Say, if I type in "abcd", what should search do?
Does that mean my search has to go through all records, and if any field of any record has "abcd" in it, it is a match?
2) name/location search should match exactly, but that seems to be a contradiction on the requirement of the find() method:
A non-null value in criteria[n] matches any field value that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)
As you can see here, the find() method requires a case-sensitive but not exact match.
I do not understand what it means by "search the data for all records"?
I understood this to mean "display all records in the database."
name/location search should match exactly, but that seems to be a contradiction on the requirement of the find() method
Yes, it is different. For a search of "Fred", both "Fred" and "Freddy" would be returned from the find() method, but only "Fred" should be displayed in the GUI. This means that you have to filter the results of find().
Of course, if you use JComboBox's instead of JTextField's for searching, you can provide the GUI with values that are exact matches to the values in the database, and therefore simplify this problem.
BTW, as far as the "exact match" requirement is concerned, I consider:
"Fred" != "Freddy"
"Fred" == "Fred "
"Fred" == "fred"
I am documenting why in my design desicions.
The requirement is that is MUST support an exact match. Yes, it does. An exact match is a subset of partial match. So if you put in the exact name and exact location, the search will work. It also works with partial name and location.
Would I be pushing it with this interpretation? Please someone show me the flaw in this logic.
However, there is an additional minor complication with "exact" match because at least as the database is originally constructed, it is space delimited, so you will not find you will find So even an "exact" match should allow for trailing white space.
And by the way, for those people who ask Sun, many of them eventually get back a reply saying that the database is actually supposed to be space delemited, not null-character delimited. Some people said they had gotten this reply, so I asked Sun too (I wasn't sure if it was legit to quote the javaranch forum ), and after a couple of weeks, they told me it was s pace delimited too.
[ May 31, 2005: Message edited by: Lara McCarver ]
Filtering search results in the GUI just seems like a poor design
In this assignment, the Data class has a set-in-stone interface for find() and it is "first n characters." The GUI needs to be able to do exact matching.
The most straightforward solution is, some class needs to do additional filtering. However, it doesn't necessarily have to be the GUI. It could be a layer on the server side that sits on top of Data. For example, in the SCJD Exam book, they show a DBClient Interface that is on the server side. Or, the layer could be on the client side, but remember, not all code on the client side is GUI code... some is GUI code, some is internal logic related to business rules, etc.