Search Criteria

[Anonymous]

I realize that some of the developer application assignment requirements are somewhat vague, and that in these cases we are to figure out for ourselves what to do. However, the search criteria requirement seems to be particularly ambiguous. For example, is the user of FBN supposed to actually input text into the GUI with search strings like "Carrier='SpeedyAir',Origin='SFO'", or is it okay for the user to choose criteria with graphical drop-downs etc? In the "Creating the user interface" section of the assignment, it says that the "user should be able to select the origin and destination of flights, and the display should update to show only flights that satisfy those criteria", so I'm thinking that the example that specifies "carrier" above is not a situation we need to allow for. I will appreciate any interpretations of these items, and any suggestions how to implement the interpretations. Thanks in advance for your assistance.

[Mark Spritzler]

In my submission, I had three JComboBoxes, one for carrier, one for origin airport, and one for destination airport. The user selects fro the JCombobox, when they click the search button, I create the string "Carrier='SpeedyAir',Origin='SFO'" in code, and pass it to the criteriaFind method. How you handle the rest, is decisions you need to make.
Good luck
Mark

[Peter den Haan]

Seconded. To my mind, the criteriaFind() method is like the JDBC Statement.executeQuery() method. How many RDBMS-based systems do you know that ask users to formulate their queries in SQL, as opposed to fiddling with a few graphical widgets?
- Peter
[This message has been edited by Peter den Haan (edited November 27, 2001).]

[Matthew Comer]

One thing to note:
The instructions I received with my assignment (which is the old version, with the database conversion tool included) did state that criteriaFind() should be generic, i.e. should accept "queries" with any of the database columns as criteria. HOWEVER, the GUI needed to only allow for Origin and Destination as user-selectable criteria. They never said anything about allowing the user (with the GUI) to search by carrier... My criteriaFind() implementation would do it just fine, but the GUI offers no facility for it...
I offer this comment only to encourage folks to not "over-feature" their submissions above and beyond what the assignment calls for. I spent a long time working on this #$@! thing, only to have a kind and correct co-worker point out that I was over engineering it, and that if I'd just finish it per the instructions and submit it then I'd be on my merry way...
Matt

[Shivaji Bhosale]

I have only to say is, in criteriaFind i am having simple JTextField with, criteria's such as, Origin, Destination, & Carrier.
Hope giving 3 criterias makes no shortcomings for grading.

[Peter Crowley]

Originally posted by Mark Spritzler:
In my submission, I had three JComboBoxes, one for carrier, one for origin airport, and one for destination airport. The user selects fro the JCombobox, when they click the search button, I create the string "Carrier='SpeedyAir',Origin='SFO'" in code, and pass it to the criteriaFind method. How you handle the rest, is decisions you need to make.
Good luck
Mark

Mark, did you account for changes in the column names? I mean, you didn't just hard code the column names into the search string did you? I couldn't figure out a good way of figuring out what the column names were, so I have a JTextField for the user to enter the search criteria into, and instructions on how to do it.

As for the <code>criteriaFind(String)</code> method, I can search on any column name looking for any value. I didn't interpret the assignment to say LIMIT the client to searching only on the "origin" and "destination" fields. Since I can't really tell which columns and fields to look at for origin and destination if they ever change in the db file, I have no choice but to allow the user to specify the column name and the value. Any thoughts?

------------------
-Peter Crowley,
who is looking for work in North Florida

[Mark Spritzler]

>>Mark, did you account for changes in the column names?
What changes, that was not part of the assignment. It specifically gave us what the criteria string is supposed to be, including names.
Now if you want to go through the uneccessary time of adding the changability for the future, you can probably write code to get the fieldName from the fieldInfo class, getName() method, if I remember correctly.
>>so I have a JTextField for the user to enter the search >>criteria into, and instructions on how to do it.
and
>>I have no choice but to allow the user to specify the column >>name and the value. Any thoughts?

I would say that this makes for a less user friendly interface. Look at Peter's post above.
As far as the changes, I found that in my code, All I have to do is change the name in one place, my CriteriaBuilder class, in the string it creates it has the exact field name = value, just like it says in the requirements.
I just tried not to over-engineer things, and let the refactoring be done later only when needed. Hey, actually that's kind of like XP Programming. I am actually using that without being in a team. I like that
Ok have fun and hope that clears some things up.
Mark

[Anonymous]

Mark, Peter, Matthew, Shivaji, thanks for your replies to my question. I appreciate it. It seems that there are some differing opinions on this topic, and the fact that there may be slightly varying versions of the developer assignment complicates the matter. One of the main reasons I asked my original question was because the assignment notes that "your user interface should be designed with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs." Any interpretations of what this statement means? To me it signifies that the application should be designed in a manner that allows modifications to be made in an easier rather than more difficult manner should any changes be needed in the future. To me, I really do not see how hardcoding etc allows for possible future enhancements without rewriting significant parts of the application. Comments?

[Peter Crowley]

Originally posted by Erik Gfesser:
One of the main reasons I asked my original question was because the assignment notes that "your user interface should be designed with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs." Any interpretations of what this statement means?

I read this to mean to design the UI in such a way that the user will not have to do anything differently when it changes. For example, using a JMenuBar and adding new MenuItems for new features, doesn't change the way that the existing functions work, or how the user accesses them. I personally added a status bar to my GUI, but this is not necessary by any means.
I hope that this helps.

------------------
-Peter Crowley,
who is looking for work in North Florida

[Peter Crowley]

Originally posted by Mark Spritzler:
What changes, that was not part of the assignment. It specifically gave us what the criteria string is supposed to be, including names.

You are correct. I read over and over the assignment.html and see no mention of ever having the data change. I remember someone mentioning on another thread that the database was for reuse, but the assignment mentions nothing about ever changing the data structure.
I still think that making the criteriaFind method generic enough to take in any [field info]=[value] combination is the way to go.
Thanks for your comments, all.
-Peter Crowley

[This message has been edited by Peter Crowley (edited November 27, 2001).]
[This message has been edited by Peter Crowley (edited November 27, 2001).]

[Peter den Haan]

As I understand it, Data (and its networked counterpart) is for reuse in completely different projects, and nothing you implement in it or around it should make any assumptions about table layout, column names or whatever. Including criteriaFind().
The GUI is a completely different matter. That is tied to the table structure given to you. I, too, took the "minimal disruption" requirement to mean that you should be able to add new commands and menu items to the existing ones, that there should be room for new fields and whole new screens, and of course that the general architecture behind it should be amenable to modification.
- Peter