• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: contractor. JTextField or JComboBox for search creteria?

 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HI, all.
My assignment is the NX contractor. I don't know whether I should use JTextField or JComboBox for the search creteria. I noticed people doing the flight ticket assignment are using JComboBox because of the natual of SRC and DES locations, which are not editable. However I think this does not apply in contractor assignment. Does anyone have any suggestion for this problem? Thanks.
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peter,
I have an URLyBird assignment which is different by definition, but maybe this part is comparable with a Contractors assignment.
GUI "search" specs :

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.


DB "search" specs :


// 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);


It can be translated by :
GUI == "exact match" search
DB == "wildcard" search
As an "exact match" may be seen as a subset of any wilcard match, it's obvious that both specs are compatible.
Now to come back to your question, it's obvious too that with such requirements, JComboBoxes are better than JTextFields to meet the GUI requirements : if the user has to enter some exact criteria value, it will be easier for him to have to choose them among a limited number of possible search criteria instead of having to type them.
By "easier", I mean "faster" and more efficient. The JComboBoxes contents is a useful information in itself. Let's say that a customer is looking for a room to be booked in New York, the fact that the "New York" value is not in the Location JComboBox is enough information for the CSR to avoid a DB query.
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.
Best,
Phil.
 
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the good tips. I have one more question related to the difference between the GUI "exact match" and the DB "wildcard" search.
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?
TJ
 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
...


Hi Philippe--
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

Thanks in advance!
Paul
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But if using JComboBox, there are two other problems:
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?
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?
Thanks.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Terry,

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?


As your GUI cannot build any other query than "exact matches" ones, by definition you should not receive "partial matches" results from the DB (I mean if your db-side search method is well written ). I wrote "search" on purpose, because findByCriteria() alone cannot do the job.
To take the assignment example :
If your GUI asks for "Freddy", you shouldn't get any "Fred*" in the results. This is obvious.
Less obvious, let's say now that there is a "Fred" among the possible unique field values and you asks for "Fred" (exact match from the GUI). If you simply pass "Fred" to findByCriteria(), you should get "Freddy" records too. My solution to this issue is that I have two findByCriteria() methods : the one given + another one which accepts range criteria (two arrays in parameters instead of one).
I use the second findByCriteria all the time, and in the example I pass to it "Fred" right-padded with 0x0000 in criteriaFrom[] and in criteriaTo[]. In this method, criteria are right-padded up to the field length with 0x0000 chars (criteriaFrom) and 0xFFFF chars (criteriaTo). As the params received use the full length of the field, they are kept unchanged, meaning that in the example, search will be performed from "Fred"+00000000000 to "Fred"+000000000000, excluding "Freddy".
Now what does the original findByCriteria() method ? Simply calling the second one with criteria repeated in criteriaFrom and criteriaTo. If you pass "Fred" to it, the search performed will then be on from "Fred"+0000000000 to "Fred"+FFFFFFFFFF, hence including "Freddy". I never call this original method, it just works as expected, period.
Hope this helped,
Phil.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Paul,
Mmh... Looks like the time I answered to Terry, I got two new posts to reply to.
Hope it will not be the case this time.

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?


No. Just a "Refresh" button in my search panel to get updated unique criteria values on demand.

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


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 !
Best,
Phil.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peter,
Phew ! No new post in the meantime !


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?


I love this question because I have replied to it above already (Refresh button).

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?


Do you expect hundreds of unique locations and hundreds of unique hotel names ? Now even if it happens, typing the first char should select the first matching criteria, so it's not an issue IMO : the user looks for "New York", types "N", opens the combobox and has just a few locations to choose from.
Best,
Phil.
 
Paul Tongyoo
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 !


Nooooooooooo-- now i'm back to being uncertain again to what to do. You know, i'm beginning to hate this phase of the project. When does the refactoring end???
(But i know without JavaRanch i'd be even more lost-- this site (and this forum) is a life-saver.)
Paul
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Philippe,
You seem to be on the ball with the search criteria issue, but i am having a hard time understanding it.
I've completed and doc'ed the project yet still am not satisfied about the result. Especially search criteria.
Requirements statement:
"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. "
Its difficult to accept that this means anything other than, the field in the database (location/hotel name in this project) must match the whole string that the user typed. This means that there will be no wildcard searches.
It also seems that the findByCriteria method in Data class is unnecessary since the criteria it receives comes from the user, so, why perform a prefix search when all of the field must be matched?
I have 2 text boxes for searching. Its just not logical that the user has to
type exactly all text to match all of the text in a database record field.
Please enlighten me.
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peter,
I provided editable combo boxes for the search criteria. They were editable because I allowed the user to activate wildcard matching for each search criterion. I populated the combo boxes once, the first time the JTable was displayed. I updated the search criteria for only one field (owner) when the user entered a new customer ID during a booking.
I definitely recommend using combo boxes. However, I recommend making them non-editable. I would recommend populating them one time only (at start up). The combo boxes are a significant convenience for the user; they are even a convenience for you when you are testing your GUI.
Hope this helps,
George
[ February 10, 2004: Message edited by: George Marinkovich ]
 
Jim Brown
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
George,
1. So u accept that client search must match all of the text in a record field (Because you filled comboboxes with full field data for later searching, right?).
2. How are you integrating the two searches (both on server or mixed between client and server).
3. On findByCriteria, we must all implement this method but did u also find this was redundant? I mean with the prefix search.
4. Can u exapnd on your wildcard. It sounds like it was a once only thing to fill the cmboxes, but have you taken into account that new records maybe added, and they wont show up.
Apologies if im asking too much, but i think i'm just starting to get it, and will get once these questions are answered.
Thanks
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,
1. Regarding exact searches : Since my Data class already had the functionality to do inexact searches, I simply exposed it by providing an "exact" JCheckbox which was checked by default. I also supplied a "case-sensitive" JCheckBox which was also checked by default. This precisely meets the requirments and provides the user with the hidden functionality.
In the real world, I would justify providing this "unnecessary" functionality by pointing out that it would greatly increase usability without having to do much extra work. This would probably enhance the chances of landing additional work from the customer. If this capability were not provided, users might find the app annoying to use which might result in not getting the additional work.
2. Regarding JComboBox vs. JTextField : I used editable JComboBoxes because I thought it was nicer from a usability standpoint. At first, the only entries are a "---ANY--" wildcard. As the user searches, newly discovered unique names and locations are automatically added to the lists. This approach would not work well should the database size grow considerably to hundreds or thousands of entries. Since the current size of the database is small and the instructions say that this exercize is an experiment prior to going to a full web-based system (see below), you have an easy out and don't have to cater for this possibility to meet the requirements of the assignment. I firmly enunciated that point in the choices.txt file.
The following is from my instructions :


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.

 
Jim Brown
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ken,
Ok it sounds like i got it now. I just couldnt understand why people were using Comboxes, maybe because i couldnt bring myself around to think that these were to cache (all) unique field data from the database.
Sometimes, its just not easy to let reality go.
Thanks.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
Hey, you're not the professional football player/actor are you? If you are I must say I thought you'd been retired for quite a while and I kind of pictured you having a Margarita on a beach in Acupulco rather than busting your hump studying for the SCJD. By the way, you were great in "Dirty Dozen." If you're not him, then I guess it's just the curse of having a common name.
1. Yes with an explanation. By default, meaning wildcard matching is disabled for the database field, the search string must match the database field contents exactly, except for any trailing white space. Yes, I did fill each combo box pulldown with all the unique values from the database file for that field.
2. The server does a starts-with search as specified by the Sun-supplied interface. The client's find filters the search result returned from the server. For fields where wildcard matching is enabled, there is no filtering; for fields where wildcard matching is disabled, non-exact matches (ignoring trailing white space) are filtered out from the search result.
3. Sounds like our assignments were a bit different. I had B&S Contractors (version 2.3.3) and did not have a findByCriteria method. I did have a "String[] find(String[] criteria)" method though, maybe that's the same thing. I didn't find it redundant. I actually use it to generate the starts-with search result that is sent to the client.
4. This is how I implemented wildcard matching. I allowed the user to search on every field in the database schema. I had a preferences editor that allowed the user to indicate by checkbox whether wildcard matching was allowed for each field in the database schema. By default wildcard matching was disabled for "name" and "location" as required by the assignment instructions. I allowed the user to enable/disable wildcard matching for each field in the database schema at any time. The configuration preference would remain in effect until changed by the user (that is, it was persistent for subsequent runs of the application).
About the combo-boxes. I filled them with all unique values one time only (when the JTable is first displayed). I updated the owner field combo box pull-down when the user entered a new customer ID. None of the other fields could be updated because I made only find (to support searching) and update (to support booking for an owner) available to the client so there's no way for the pull-down lists to get-out-of-date since I didn't allow (at the client) create or delete functionality. If I had allowd (at the client) the ability to add records or delete records then I would have had to be concerned with the issue of keeping the pull-down lists up-to-date. But remember, my combo-boxes were editable, so I could have taken the position that the pull-down lists were a convenience. If the value you wanted was missing then you could type it in yourself (but again, given my situation there was no way records could be added using my client GUI).
Hope this helps,
George
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
My B&S assignment states under The User Interface section:

Your user interface should be designed with the expectation of future functionality enhancement.

Does the JComboboxes for Name and Location suffice in fulfilling this requirement?
Any advice?
rgds,
derek
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Derek,

Originally posted by Derek Canaan:
Does the JComboboxes for Name and Location suffice in fulfilling this requirement?


In my opinion, yes.
Hope this helps,
George
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic