Hi, I'm on the documentation stage and after re-reading the instruction file again & again I've got confused over my design choice of providing JComboBox for every field. I've created a TabbedPane on which there are 2 panels one for normal search (only for Origin & Destination fields) and other for all fields with one search JButton on both panels. Will my extra effort of providing Advance Search panel cause some -ve impact ? I�ve used the tabbed pane in view of future functionality enhancements.
And one more question:
As per the instruction we have
The user should be able to select the origin and destination of flights...
I think it implicitly instructs us to use the JComboBox filled with all possible values. Am I right over this point?
I'm not filling the comboboxes with all possible values of orgin & destination but making a history of all the items entered on the JComboBoxes and storing them into a configuration file which automatically gets loaded at the startup and fills the comboboxes with the history values. So now I feel that I�ve made some unnecessary extra efforts.
Pleas help me out from this confusion. Any comment will be appreciated. Thanks & regards Manish Kumar
Hi Manish, yeah - the extra work is difficult to avoid. Maybe it's a comfort for you that you learned something by doing it. I pre-filled the combo boxes with all values, including a wildcard value. Many people have done so. My criteria search accepted any combination of values, but my GUI provided only those specified in the instructions. Hope this helps.
Mag, You think that our criteriaFind needs to be able to search on all fields of the database, even though the UI should just allow Destination and Origin? I have only provided a search for to&from, doh! Perhaps that is why the instructions provide an example of the search criteria containing an Origin.... Is there an easier way to parse the incoming String other than using StringTokenizer, as I used below:
Originally posted by Dave Teare: Mag, You think that our criteriaFind needs to be able to search on all fields of the database, even though the UI should just allow Destination and Origin? I have only provided a search for to&from, doh!
I provided a generic method, which could process any database fields. I wanted to anticipate any changes to the database schema.
Is there an easier way to parse the incoming String other than using StringTokenizer, ...
I'm afraid - no. I had even two Tokenizers, one cutting the string for the criteria, and the second one for the key/value pair. And in addition, I encapsulated the whole tokenizing stuff into a separate class. Hope this helps.
Is there an easier way to parse the incoming String other than using StringTokenizer, as I used below:
The way I did it is not necessarily easier, but I think it's more in the spirit of code re-use. I took advantage java.util.Properties.load(InputStream is). You wil l need to make some allowances for the fact that the default implementation does not allow spaces in the keys, as well properly wrapping the String into some sort of InputStream.
posted 17 years ago
I've throw the java.text.ParseException from my criteriaFind method to indicate if the search criteria string does not follow the following comma separated format <field name>=<value> like: Origin='SFO',destination='LAX' ParseException also gives the position of the error. so the following line will create an error at column 12 Origin='SFO,destination='LAX'
Villains always have antidotes. They're funny that way. Here's an antidote disguised as a tiny ad: