flexible search and B&S requirement

My UI for B&S assignment search is:

For name, location field 'fred' matches 'Freddy' or exact match may be enforced.

For owner field, 'fred' matches 'Freddy'. (No exact match option)

rate and size fields do numeric comparion (>, >=, =, < or <= may be selected)

specialties field is regex enabled.
Without regex, 'Heat' matches 'Air Conditioning, Heating'.

I am not sure if the above violates the requirement (it does not exactly
conform to the javadoc of 'findByCriteria' method in interface ).

Appreciate suggestion if above implementation leads to automatic failure..

And the idea behind this search mechanism was:
Make the serach flexible. Let CSR specify any of six fields.
It does not make sense to match '3' with '30' for size field. A numeric
comparison is more practical.
Also for comma separated 'specialties' field , CSR would rather look search
like ' is there any contractor doing Heating? ..'

Sugestion appreciated.
[ January 07, 2007: Message edited by: Louis Logan ]

If so, we need to use regex, don't know java.util.regex.* package are allow or not...

if it doesn't match the requirements, it will likely result in failure.

Originally posted by Song Jing Lim:
If so, we need to use regex, don't know java.util.regex.* package are allow or not...

There is nothing in spec preventing regex use.

Coming to main topic..
I wonder if it would be safer to implement the findByCriteria method
just as mentioned in spec. AND implement another find method, which
is actually used in the code.
It is meaningless to have a method never referenced, but at least it does not break the spec.

IS IT A SANE IDEA ?

Hi Louis

Try to encapsulate the search in to a interface and make it interchangeable. The advantage is that you can define how many search criteria you need (and easily change them).

regards M

Read your requirements carefully and its better not to provide anything which is not required.
I am working on similar assignment. find(....) method is same as you described so I implemented accordingly at DB layer. Now at GUI level, I found:

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.

My understanding is, there is need of two fields (name and location) on search screen. If they are blank then all records should be displayed. If either of them is not blank than an EXACT mach in mandatory. No "Fred", "Freddy" comparison. Please anybody correct me, if I am wrong!

Shafique

You are both right and wrong.
The client indeed has those requirements, the server has far wider requirements.
Both need to be implemented. How you take care of any mismatch between them is up to you.

Jeroen,
Perhaps I was unable to elaborate or you could not understand the whole picture.

In my case, server is taking care of everthing (the wider spectrum) according to specs. Now at client side you are supposed to FILTER/PROVIDE funcationalites accoring to GUI requirements. Its up to you how you handle this.

One more thing, I would like you to comment on. My Data class is indirectly implementing DBMain interface because I added some more methods in other interface which is extending DBMain. It helped a lot to reduce coding and processing at client side. In specs, its mentioned that Data class MUST implement DBMain interface which it is doing but indirectly.

Shafique

Originally posted by Muhammad Shafique:
Jeroen,
Perhaps I was unable to elaborate or you could not understand the whole picture.

In my case, server is taking care of everthing (the wider spectrum) according to specs. Now at client side you are supposed to FILTER/PROVIDE funcationalites accoring to GUI requirements. Its up to you how you handle this.

One more thing, I would like you to comment on. My Data class is indirectly implementing DBMain interface because I added some more methods in other interface which is extending DBMain. It helped a lot to reduce coding and processing at client side. In specs, its mentioned that Data class MUST implement DBMain interface which it is doing but indirectly.

Shafique

On your second point with regard to DBMain. I think that indirectly implementating the DBMain interface via an extended interface should be ok as per the specs because your Data instance is-a DBMain instance also.

Mark.