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.
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. 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".)
public long[] findByCriteria(String[] criteria);
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Philippe Maquet:
...
So if what I just wrote with the URLyBird context in mind may apply to the Contractor one, don't hesitate any more and choose the JComboBox solution.
...
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
Can I assume then that the GUI will need to do some type of further scrubbing after it gets the wildcard results from the database?
Did you implement some operation that dynamically updates your combobox(es) with new values if a user creates a record with an entirely new name and/or location? This functionality makes sense, but I wonder if it is beyond scope?
I've been using textfields with case-insensitive pattern matching for awhile but after reading your post you've convinced me to go with JComboBoxes to better fulfill the "exact" match requirement on client-side. The only thing i didn't like about this approach (which is irrelevant because it seems to be what the specs want) is that it's sending over more records over the wire than we need, given our spec of the DB.find return results. With my original approach I had my DB.find return only matches which matched a regular expression pattern (the matches the client actually intends to see), and was ready to justify this approach in my design document. But I predict it will be easier to go with JComboBoxes because 1) their function is a closer match to what the specs ask for, and 2) less spec deviations for me to justify in my design document
2. If the remote db update, some new search field may need insert. How can I reflect this change in my search JComboBox? Or I didn't care at all?
1. If there are hundreds of the unique keys in a search field, it would be rather hard for user to find one. How to solve this?
Originally posted by Philippe Maquet:
Oops, sorry ! If you follow my advices above, you'll have to recode search server-side and client-side. And you'll have to rewrite your design choices ! But do you really need it ? I may be wrong BTW !
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
Regards, George
SCJP, SCJD, SCWCD, SCBCD
In the future, Bodgitt and Scarper wants to move into
Internet-based marketing, and hopes to be able to provide their services
directly to customers over the web.
The company's IT director has decided to migrate the existing
application to a Java technology based system. Initially, the system
will support only the CSRs, although the hope is that this interim
step will give them a starting point for migrating the system to the
web. The IT director does not anticipate much reuse of the first Java
technology system, but intends to use that system as a learning
exercise before going on to a web based system.
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Does the JComboboxes for Name and Location suffice in fulfilling this requirement?Your user interface should be designed with the expectation of future functionality enhancement.
Originally posted by Derek Canaan:
Does the JComboboxes for Name and Location suffice in fulfilling this requirement?
Regards, George
SCJP, SCJD, SCWCD, SCBCD
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |