Hi all,
I came to some considerations on the find method of UrlyBird 1.1.1, and was wondering what choices and considerations others have made.
First of all, the interface comment on the find method talks about matching records where the specific field
starts with the specific criteria. However, the instructions on the GUI talk about returning
exact matches. So my idea was to use regular expressions to meet the specification of the find method, and then, in the GUI, do filtering of these results, in order to keep only the exact matches - however, case insensitive as to make it a bit more user friendly.
However, in working this out, I came to some problems with the price field. First of all, in all records, the price field starts with a dollar sign, and this is a predefined character in regular exceptions, standing for "end of line". This leads to the fact that price fields are never matched, because if we start the criteria with a $ it means something different, and if we do not start the criteria with $, then it just does not match.
So we cannot just allow that $ in the regular expression
string for the criteria - we should at least escape it - or something else. But then I realized that searching this field doesn't make sense anyway, at least not when we do it according to the specs of this method: treating the contents as strings and matching at with what it should start. Nobody would want to search this field and having to type a $ sign first. The way users would want to use it is to find all recs having the criteria price as a maximum. But that goes beyond the scope of the assignment, as it is not asked for, and I think one of the basic principles of this assignment is: don't do fancy things which weren't asked for.
So, what is the best way? My thinking goes a bit towards just ignoring this price field anyway, and just excluding it from the criteria search (that is: to let any content in the price field by definition match the criteria). The GUI asks for only two fields to be searchable anyway (though the find comments specifications suggests all fields to be searchable).
But then, how far to take this? Ignore the size field as well? And the date field too? I wonder what others decided on this.
And then: $ is not the only predefined regex character. What if the user passes any of those characters to the find method? Like ^, or \ or whatever? Just ignore that problem? Or allow it and let them use the feature if they are smart enough? Or filter those characters out? Or raise an IllegalArgumentException if these characters are in?
Or just avoid this problem by not using regex and just use something like String.startsWith??