Question about searching

[Elchin Asgarli]

I have looked around in the forum for answer to my coming question, but could not find a straightforward reply, so I will ask it.

The UI requirement for URLyBird clearly states :

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.

So what does this exactly mean? Does this mean that

1. It must allow the user to search the data for all records AND It must allow the user to search for records where the name and/or location fields exactly match values specified by the user.

2. It must allow the user to search the data for all records AND It must allow the user to search the data for records where the name and/or location fields exactly match values specified by the user.

Maybe someone who is native in English can clarify this?

In first case I am thinking of having a text field and search button for searching through all fields, and for second case a search dialog where you can specify name and location, and drop-down box to select whether you want to search location, name or both.

In second case I am pretty confused what to do, since the fields left to search for other than location and name are smoking, rate, date and custumer ID, out of which, the only one that makes sense to search for is customer ID and maybe date. Filtering for smoking and rates seem to advanced to me for this project

[David Byron]

Elchin Asgarli wrote:I have looked around in the forum for answer to my coming question, but could not find a straightforward reply, so I will ask it.

This is one of the classic ambiguities in the SCJD certification assignments. Searching this forum, you'll find many threads that address the issue. However, you're right-- there are no straightforward replies, because it's an area of disagreement and uncertainty.

The bottom line, as always, is that any reasonable interpretation of the requirement will be ok as long as you justify it in your choices.txt (and as long as it demonstrates the core skills at issue).

I interpreted the requirement this way:

First: the data access class must support all searching mandated by the interface and requirements.
Second: the GUI only has to support the particular cases mentioned in the GUI requirements.
Third: the business tier, if you have one, provides only the methods that support the partial implementation in the GUI.
(This means that the front end will implement only a subset of what the back end can support.)

Fourth: The user must be able to execute a search that returns all records.
Fifth: The user must be able to execute a search that returns any record that exactly matches the user-provided term in the 'name' field.
Sixth: The user must be able to execute a search that returns any record that exactly matches the user-provided term in the 'location' field.
Seventh: The user must be able to execute a search that returns any record that exactly matches either the user-provided term in the 'name' field or the user-provided term in the 'location' field. (Boolean inclusive OR)
Eighth: The user must be able to execute a search that returns any record that exactly matches both the user-provided term in the 'name' field and the user-provided term in the 'location' field. (Boolean AND)

My data tier supported any combination across any values in the domain object, but my GUI (and business methods) supported only these combinations. On the much-disputed "exactly matches" issue, I took this approach: my GUI presented results filtered for exact matches, but my data class looked for fuzzy/partial matches. This best captured what I took to be the spirit of my assignment's requirements; your assignment and interpretation may vary!

In first case I am thinking of having a text field and search button for searching through all fields, and for second case a search dialog where you can specify name and location, and drop-down box to select whether you want to search location, name or both.

There are many ways to approach the GUI design. Here's my advice: do the simplest thing (a) that works, and (b) that seems self-explanatory to the untutored user.

[Robert Benson]

If I remember, you have urlybird 1.1.1 (which is the same as mine).

My understanding is the instructions are asking for two distinct things to do with the search, one at the data level and one at the business level.

The find method in the interface states:

A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int[] find(String[] criteria);

However a business requirement is that:

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.

As you can see begins with and exactly mean two different things.

The find method is what I called the loose search. It returns potentially too many records that has data that begins with. However this does not meet the requirement. I did not for obvious reasons change the interface method. Instead, I refefined the returned data from the find method for exact matches only.

[David Byron]

FWIW, Searching the forum for the term "Freddy" is a good way to recover many of the previous discussions of these issues.

[Elchin Asgarli]

Thanks for replies! It seems almost clear to me now.

David, so from what I understood you took approach closer to my 1st assumption. So just few questions to make it 100% clear:

1. In your GUI the user could only search/filter through name and location fields, right? It was impossible to search lets say customer ID field.
2. A record can satisfy your eight point only if it has the same name as its location, true?
3. Does your business method call find() method of Data class and then filter its results to 'exact matches'? Or does it read all the records and filter manually?

And here is what I did up to now: My Data class implements find method by returning partial matches, as specified in the DB interface, and I have also added a convenience method to Data class that would return me the numbers of all records currently in the system. This is done so that my business layer can retrieve all the records from the system to show it to user. Now I think that it may have been redundant, since returning all the records could be achieved by calling find with all null parameters inside the criteria.

Robert, I have no idea what version I have, but the signature of unlock method and the descriptions of methods seem to match 1.1.1. Since I bought my exam from Oracle/Prometric IBT, there is no longer instructions.html available, you view the instructions online and you must save them.

[David Byron]

Elchin Asgarli wrote:David, so from what I understood you took approach closer to my 1st assumption. So just few questions to make it 100% clear:

1. In your GUI the user could only search/filter through name and location fields, right? It was impossible to search lets say customer ID field.

Correct. I used a single search button and one text field per value. If both fields are empty when the user presses the button, the system returns all records.

2. A record can satisfy your eight point only if it has the same name as its location, true?

The name does not have to match the location. Rather, (a) the name has to match the user's search term for the 'name' category, and (b) the location has to match the user's search term for the 'location' category.

It's possible for the name to match the location, but that would be an irrelevant coincidence.

If memory serves, Roberto implemented -- or considered implementing -- a different approach to searching. It would be good to hear from someone who passed with another interpretation of these ambiguities.

3. Does your business method call find() method of Data class and then filter its results to 'exact matches'? Or does it read all the records and filter manually?

Fuzzy/Partial matches happen in my Data class. The business method then implements a stricter filtering and returned to the GUI only what the GUI really wants. My GUI knows nothing of filtering. However, I believe some others here implemented filtering in the GUI rather than in the middle tier.

Now I think that it may have been redundant, since returning all the records could be achieved by calling find with all null parameters inside the criteria.

When in doubt, simplify!

[Elchin Asgarli]

Almost clear..

One more clarification question:

The requirement states "It must allow the user to search the data for all records". Does this mean that UI MUST allow user to search for given expression in all the records, or does this simply mean that UI search functionality must only allow user to retrieve all records? In other words, can this requirement be rephrased into "It must allow the user to retrieve data for all the records"? Its more of an English question than technical.

[Elchin Asgarli]

Also one thing that came to my mind right now : The requirement says "where the name and/or location fields exactly match values specified by the user", valueS! Which means that user must specify name and location values in separate fields, not in possibly in one field like I thought before.

[Roel De Nijs]

My (simple) GUI contains 2 fields: one for location and for name. So the user has 4 possibilities:

retrieve all hotel rooms (leave both input fields empty)

search on a name (enter a value in the input field name and leave the input field location empty)

search on a location (enter a value in the input field location and leave the input field name empty)

search on both name and location (enter a value in both input fields)

I think it can't get easier than this. Correct me if I'm wrong

[Elchin Asgarli]

Roel De Nijs wrote:My (simple) GUI contains 2 fields: one for location and for name. So the user has 4 possibilities:

retrieve all hotel rooms (leave both input fields empty)

search on a name (enter a value in the input field name and leave the input field location empty)

search on a location (enter a value in the input field location and leave the input field name empty)

search on both name and location (enter a value in both input fields)

I think it can't get easier than this. Correct me if I'm wrong

That is exactly what I was thinking of doing, if my last question about clarification gets an affirmation But now that doing this you got 400/400, I consider it as the best possible affirmation ;)

Thanks a lot everyone!

[David Byron]

Elchin Asgarli wrote:The requirement states "It must allow the user to search the data for all records". Does this mean that UI MUST allow user to search for given expression in all the records, or does this simply mean that UI search functionality must only allow user to retrieve all records? In other words, can this requirement be rephrased into "It must allow the user to retrieve data for all the records"? Its more of an English question than technical.

I'm not sure I understand the distinction you're trying to draw. It seems to me that both of your interpretations are true: it must be possible to retrieve all records, and it must be possible to search through all records.

In any event, the sentence you quote seems to mean simply that it must be possible to retrieve everything in the database at once.

Roel's advice is good. The only difference between his options and mine is that he doesn't support Boolean 'OR'. A value in each of the two search fields means a record must include both in his app; in mine, the user chooses whether to OR or AND them.

[Olu Shiyan]

Hi guys,

My understanding/interpretation of the GUI requirements is similar to the approach explained by Roel. However after reading David's post Im somewhat confused. I think both interpretations are acceptable?

Thanks

[Roel De Nijs]

Olu Shiyan wrote:I think both interpretations are acceptable?

Of course, they are.

[Olu Shiyan]

Thanks Roel. I think I'll settle for the simpler method i.e. the one you described above.



Cheers!

[David Byron]

Roel's interpretation and mine are identical except for the requirement that I marked as "Seventh". I support it; he doesn't.

Either way, you'll be fine as long as you justify your decision!