How to handle booked records?

[S Perreault]

Hello Again =)

I am wondering how other people who are creating the B & S application are handling 'booked' Contractors. If a Contractor is booked, should a search bring back that Contractor?

Currently, I have a textbox that accepts the Customer's owner ID and if the customer's id matches the booked id, the CSR will get a message "This customer now has booked this record." if they do not match, the CSR gets a message, "This record is booked by another customer."

How are others handling this? I suppose that it would also be wise to not have any booked records returned from a search.

Thanks,
Perogi.

[Philippe Maquet]

Hi Perogi,

I suppose that it would also be wise to not have any booked records returned from a search.

I personally agree with you, but I know that a majority of us here have a different opinion.

Given the CSR's job, who book last-minute hotel rooms (I've got URLyBird but I guess it's comparable with B&S in that area), it wouldn't make sense IMO that a search returns unbookable records. In my provided test db I have 31 records, so there is no issue. But in production, the application could have to deal with 10000 records with only a few of them available for booking. In that case, returning booked records just make the application unusable. If the CSR is looking for an available room in New York (the customer holds the line), performs a search and receives a 10-screens-resultset with the only one available room on the 8th screen, it's obvious that he won't appreciate the developer's decision to return all records booked or not.

The only problem is that the instructions state:

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.

And it's a must-be...

So I guess it's safer to support both modes, which suppse some additional property.

Regards,

Phil.
[ May 21, 2004: Message edited by: Philippe Maquet ]

[S Perreault]

Merci Philippe,

That's about all the French I know from visiting my father's side of the family (French Canadien). =)

Related to this same problem:

The User Interface
"It musts allow the user to search the data for all records, or for records where the name and/or location fields <b>exactly</b> (my emphasis) match values specified by the user."

And in the DBAccess interface:
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)


These two 'musts' do not match. One states that they must match exactly and the other only states that they need to only begin with. Currently I have it so that a search will return all records that begin with. However, "The User Interface" requires an exact match. I am beginning to think that it may be wise to go through the records and create a Set on Contractor name and a Set on Location and have them as dropdowns in the search pane.

Any ideas? It seems strange to me that they would have these two musts contradict each other.

Thanks for your time and efforts,
Perogi.

[Philippe Maquet]

That's about all the French I know from visiting my father's side of the family (French Canadien). =)

Your name sounds French, indeed!

BTW, my "A r�pondre sur" (which means "To reply on") followed by a link to this same thread in my previous post (I just removed it, it was a personal note I left by mistake) came from the fact that when I tried to post my reply to you this morning (Brussels time), JavaRanch was not running as usual and I had to save it in a text file to post it tonight.

it may be wise to go through the records and create a Set on Contractor name and a Set on Location and have them as dropdowns in the search pane.

I think it's the best solution. I'm even under the impression that most people who use text fields instead loose points in the GUI part (which is rather normal BTW ).

Any ideas? It seems strange to me that they would have these two musts contradict each other.

Is it really contradictory? Both layers (presentation and data) just have their own specs and it's rather easy to reconcile them. This thread may interest you.

Best regards,

Phil.
[ May 21, 2004: Message edited by: Philippe Maquet ]

[Javini Javono]

Hi,

The user interface section has four bullet points, of which here are two:

1. It must allow the user to search the data for all records, ...
2. It must allow the user to book a selected record, updating the database file accordingly.

These four bullet points are anded together, that is, all must be implemented.

Do you all plan to allow the user to book a selected record from last year?

If not, there is no reason to display a record from last year, I would think.

I think it is unfair to have "must conditions" quite so unclear. It certainly
doesn't take much effort to clarify exactly what might have been desired:

1. It must allow the user to search the data for all bookable records, ...
2. It must allow the user to book a selected record.

It is impossible to know what was on the person or persons mind who
wrote the above. They may simply have assumed that you would only
want to search for bookable records and thus felt no need to qualify
the word "records".

My solution, and no one can know what is right or best, is that I have,
at this time, a hard-coded value representing "48 hours". At present,
it is set at one year, so there are always bookable records which come up.
I might eventually make this a preference item (which would probably be
the most appropriate thing to do only to make the program easier to
test from the Sun examiner's standpoint).

Then again, I may just submit it using the 48-hour rule, since I really
don't want any arbitrary client to change the business rule. Probably
an interesting trick the client examiner might try is simply to adjust
their system clock so that they see the bookable records they need to
see.

thanks,
Javini Javono

[S Perreault]

Philippe,

Wow, some great threads there. I totally understand your last message that the two specs do not necessarily contradict each other but are in fact, pertinent to their appropriate part of the application (GUI vs. Database).

I believe that I will implement a dropdown list of the search criteria. That way, I can satisfy both sides =)

Now to determine how often to refresh the dropdown lists... Each time the search panel is displayed or once when the application is created...

Have a great weekend,
Perogi.

[Serkan Yazici]

I think all records that match the search criteria must be displayed. Otherwise once a record is booked, how can it be unbooked (set its owner to "") again, or rebooked with somebody else. It will be gone from the list forever. I guess in a real life system there would be a timeout for booked records, or two way communications with the contractor. When the job is complete the contractor will be avaliable again and its owner set to "". What happens if the customer changes his/her mind?

[Andrew Monkhouse]

Hi Serkan,

Welcome to JavaRanch and this forum.

You do need to be careful not to go beyond the requirements of the instructions (or, if you do go beyond them, make sure that you are aware of it you should document that you are deliberately going beyond the requirements so that the examiner is aware of it). You probably have a sentence in your instructions telling you that "You will not receive extra credit points for work beyond the requirements of the specification.". It is actually worse than that: while you cannot get extra marks for going beyond the specifications, you could potentially loose marks if you make a mistake in your "extra" code.

While all the questions you have asked are good questions that you should ask in real life, they are not part of your requirements. In my opinion, the best thing to do is to put a comment in your design decisions document stating that you are not catering for those issues - this shows the examiner that you have thought about the issues, but have not gone beyond the scope of the assignment.

Regards, Andrew

[Philippe Maquet]

Hi Perogi,

Now to determine how often to refresh the dropdown lists... Each time the search panel is displayed or once when the application is created...

Isn't your search panel displayed all the time? If it's the case, I think that some "Refresh" button could do the job on demand.

Regards,

Phil.

[S Perreault]

Good morning Phil,

Actually I use a JTabbedPane with 3 panels. The first one is for the Search, the second one is for the Search Results and the third is for the confirmation of the booking. Therefore, an event can fire when the first tabbed pane is selected, creating the dropdowns. However, I do not know if that constant traffic going back and forth of a list of options is a very good use of bandwidth.

I like your idea of having a 'refresh' button. That way, bandwidth is only consumed on startup of the application and if the user wishes to see if a new Contractor/Location is added to the database.

Thanks for the idea!
Perogi.