This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It 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.
My opinion is searchAll will call read() with all recNo. Tow JTextField instances will be created and added to client UI. So search means both the two conditions name and location should be satisfied. When instance which stands for name is blank, I will search for records only exactly match location fields values. It is similar when instance which stands for location is blank. When both of them are blank, search now equals the meaning of searchAll. At first I want to utilize find in Data to realize search. Howerver, comments regarding find say
//A null value in criteria[n] matches any field // value. A non-null value in criteria[n] matches any field // value that begins with criteria[n]. (For example, "Fred" // matches "Fred" or "Freddy".)
. So can you see the collision here? Then I decide to overwrite find, with passed parameters name (String ) and location (String) ,and this time find will do exactly matching. How do you think so?
Consider this from the perspective of a large company developing this program:
The server side staff have to create a generic search facility that will do "starts-with" searching.
They may not be aware of the GUI programmer's requirements, or they may be aware of two (or more) different groups who all want to do searches (so they are creating a generic interface). We don't know. All we know is that the server programmers have been told to create a server-side "starts-with" search.
The GUI programming team have been told to make an application that is very specific to the needs of the users who will be using the system.
So the GUI programmers will be developing a client-side exact-match system.
This has nothing to do with how the search facility on the server-side works.When you look at it like that, it might be possible to see that there is no real problem: what you are seeing as a problem is only because you are trying to develop one application rather than considering from the view that there are two separate applications (client and server).
To further divorce the concept between performing a search and displaying data, the search method does not return records - it returns record numbers. You have to retrieve the records based on the numbers in a separate step. So you would presumably be validating that the records still matched anyway (otherwise the records could change between when you complete the search and when you retrieve the record).
Also you have even been told that there are other applications working with the data, so having a more generic API than you really need that has methods you don't need should come as no surprise.
Hi Andrew, Your replies have always helped me a lot.
what you are seeing as a problem is only because you are trying to develop one application rather than considering from the view that there are two separate applications (client and server).
That is my key problem.So my task now is to realize exact matching in client using the result of find in server.
You have to retrieve the records based on the numbers in a separate step.So you would presumably be validating that the records still matched anyway (otherwise the records could change between when you complete the search and when you retrieve the record).
This is the principle my search must take into account.And the result will be certain object and certain scope be synchronized. However I still wonder to know the form how user send their searching infor, what JComponent best suite this requirement.Thanks a lot.
I didn't do an exact match search on the client. However, I stated that since searching the prefix will return all the exact matches, it satisfy the requirements in the spec of performing an exact match search. My reason is that the user will have a lot to type and have to type careful if you have to type in the exact name and/or location. What do you think about this?
Joined: Jan 25, 2006
My reason is that the user will have a lot to type and have to type careful if you have to type in the exact name and/or location
But I think it will not add much complexity, cause only name and location execute exact matching. Why you risk breaking the requirement? Am I right or wrong?