• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX URLyBird 1.3.2: Discrepency in find interface with specs.

 
Larry Cha Cha
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The spec for the GUI says
"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."
Yet in the comments to the find method say:
"A non-null value in criteria[n] matches any field
value that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)"
To conform to the assignment, I would have to implement the find method above as required... and just not use it, using another one that does exactly the same thing but where the criteria exactly matches.
Clearly this is nonsense to do.
But which way to go I am not sure, either matching exactly or matching on the start of the string will contradict one of their requirements.
Cheers,
Larry
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Larry,
I have the same apparent contradiction in version 1.2.1 of URLyBird.
I say apparent because you may simply see the GUI specs as a particular case of the server specs. I mean that if you implement the server find method as required, that same method may be used to serve values which match exactly.
In the GUI, I'll use combo boxes filled in with the unique distinct values I can find in the database for the corresponding fields. It supposes some specific method at server side to get those unique values, some mechanism to maintain them if they change, but from there, I can still use the more general server find method.
Regards,
Phil.
 
Larry Cha Cha
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like a pretty good way to go Philippe, I think I may employ the same technique.
Do you think that it is good enough to just obtain the values for the combo boxes for location and name at the beginning? or should it dynamically change?
Since we don't have to have delete, and create in the GUI I don't think I will bother changing them as it will require passing back another array on every query to the db. By using the values in the JTable isn't the answer either as it doesn't truly reflect what's in the db.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Larry,
I personally think it's better to have the search values updated dynamically, but your arguments are defensible !
Regards,
Phil.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NX Contractors has the same issue.
I say apparent because you may simply see the GUI specs as a particular case of the server specs.
I agree. This is a good approach in general - keep the server and network code as generic as possible, following the required server functionality and ingnoring the GUI requirements if possible. Then when you get to the GUI, put in a facade which wraps the DB (or remote connection to the DB, whatever) a and adapts the generic DB functionality to the specific GUI needs.
E.g. the GUI needs to find exact matches for "Fred". Your facade class can call the DB find() method, which will return both "Fred" and "Freddy". The facade can loop through each of these results and see if it's really the exact match it was looking for, and ignore inexact matches. Then pass the exact match(es) on to the GUI.
Do you think that it is good enough to just obtain the values for the combo boxes for location and name at the beginning? or should it dynamically change?
I'm inclined to think dynamic updates are too complex for this assignment. Load them on startup, and provide a "Refresh" key of some sort if the user thinks the values are too stale. But also make sure that the user can write their own value to search for, not just the ones in the drop-down. If the DB file is really big, there may be too many things in the drop-down for it to be useful to the user - easier to just type what you want directly.
If you allow the GUI to do inexact matches (not required) in addition to the exact matches which are required, then one option is to always populate the drop-down with the results of the latest find() operation. This would probably scale well for a big db - users could get in the habit of using inexact find() first to narrow their options, and then go to the drop-down to find more exact matches. Though at this point they are also looking at a table of records that were returned by that find - may be easier to just find what they want there, and ignore the drop-down. Hmmm... I'm still working on the GUI, so I'll think about this some more.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic