I was thinking about the search mechanism. Somewhere along I thought the search should be implemented (I'm talking about the user interface now) using "starts with". So you have your text field and some mechanism to indicate that you want a "start with" match or a complete match. Just for the record:
start with= the search word 'jav' matches: 'java' 'javaworld' etc exact match= the search word 'jav' matches only: 'jav'
So you could do this using a checkbox to indicate what you want etc.
But, after reading the damn assignment (again, for a change) I realized that they are not speaking about a 'startwith' mechanism, instead they say a 'flexible search mechanism' . Don't know where I got the idea of the startwith...
So ! my question is this (since this has some important reflections on the database layer and such) what kind of mechanism do you guys use ?
First I was thinking of using regex. But, for letting the search word 'ja' return 'java' and 'javaworld' the user must enter: 'ja[a-zA-z]*' which is kinda complex, or not ? I do not know gui's where you use regex to search for something. I only know regex'es from programming...
A hybrid version is also a posibility, like a checkbox indicating you want to have exact match, startswith or you are using regex...
Don't confuse flexibility and overdoing it! That is, don't feel the need to implement additional functionality just because it makes searching more flexible. Just implement the required stuff so that it could be extended easily.
BTW, as a rule, I would say if the user sees a regex, I wouldn't submit!
1. The interface states that null elements are disregarded and all non null elements are matched using 'startswith' .
-> This means that the actual Data class may not change this behavior, no ? Since it would violate the description of the interface. But then again, making it a bit more flexible does not pers� mean changing the code of the interface, only the javadoc. Is this allowed ? ... Like you could use wildcards in the search strings. But that would result in changing the javadoc.
2."It must allow the user to search the data for all records, or records where the name and/or location fields match values specified by the user."
-> The gui should only have 2 searchable fields. Name and location. The other fields should not be used. So basicly, you would endup with only 2 text fields for your search ? Is this true ? I really cant imagine this.
3. "They take requests from home owners for a type of service, and offer the homeowner one or more contractors that can provide the required services."
-> So basicly they search assignable contractors using the services they offer. First, according to point 2) there is no search field for the services, so this is out of scope. Second, as mentioned in the other topic the specialities consist out of a coma separated list. How on earth can you handle that without making your data business aware ? My data class is very abstract, it can be re-used for other database files (as long as they use the same schema header) . So if I would treat that field on a different way because its comma separated, I would make my Data class business aware and that I want to avoid.
I'm going insance here [ December 09, 2004: Message edited by: Koen Serneels ]