NX: customer ID in urlybird

[Yanick Labelle]

Hi, I've got some questions about the customer id in the URLyBid project:
An employe will be booking rooms on behalf of custommers who call the company.
Where should I put the field that asks for the customer ID?
In the preferences? (not a good idea since the employee will be receiving calls from many customers)
In the JTable, at each line?
At the bottom of the form near the Book button?
If I put it in the JTable at each line, what hapens if the user enters the customer ID on multiple lines? Should I support multiple rooms booking?
Any advice? Thanks!

[Nathaniel Stoddard]

A customer should be able to book multiple rooms. Otherwise that road-trip is going to be pretty rough. As for where it goes, just consider all your options, the advantages and disadvantages of each, choose one, and justify yourself when you write your choices documentation.
Your option of setting it in the properties file is a bit off. The CSR will run the program and it will be running for a long time. You need to create some sort of Swing widget to get that information from the CSR. I did mine in a dialog box so I could validate it and book the room. Think JTextField--but where is up to you.

[Yanick Labelle]

Hi, thanks for the answer.
What your are saying is that I should allow the user to select many rooms from the JTable by using ctrl-click or shift-click, then, when the user clicks the book buttom, I should ask for the custommer ID, and assign all the rooms to this custommer?
Another of my questions was, did you show the rooms that are already booked in the JTable for information purpose or only the rooms that are free?
Also, the spec says that the customer can book rooms in a 48h delay, do you display the rooms for which the available date is in the past (since the available date has passed, it seems useless), or the rooms for which the available date is more than 48h in the futur?

[Simon Ingram]

Hi Yanick,
Unless I am mistaken, the customer id is an 8 digit number that the CSR knows and types into the owner field in the JTable. In fact it is the presence or absence of this number that identifies the record as booked or not. I don't think you need any separate wigits and the only validation is that it is a number between 10000000 and 99999999.
regards,
Simon

[Satish Avadhanam]

Hi Simon

Originally posted by Simon Ingram:
Hi Yanick,
it is a number between 10000000 and 99999999.
regards,
Simon

So it seems that you are allowing EXACTLY 8 digits right? Actually you can do that, or you can allow digits ranging from 1 - 99999999.(less than 8 is OK, I think)

[Andrew Monkhouse]

Hi Satish,

So it seems that you are allowing EXACTLY 8 digits right? Actually you can do that, or you can allow digits ranging from 1 - 99999999.(less than 8 is OK, I think)

I agree that allowing less than 8 digits should be acceptable, however I doubt that anyone has failed for forcing exactly eight digits. Another design decision to make (and document ).
You might also be interested in this post.
Regards, Andrew

[Andrew Monkhouse]

Hi Satish,

So it seems that you are allowing EXACTLY 8 digits right? Actually you can do that, or you can allow digits ranging from 1 - 99999999.(less than 8 is OK, I think)

I agree that allowing less than 8 digits should be acceptable, however I doubt that anyone has failed for forcing exactly eight digits. Another design decision to make (and document ).
You might also be interested in this post.
Regards, Andrew

[Satish Avadhanam]

Hey Andrew, yeah I read the post you mentioned sometime back and then only replied that less than 8 digits is OK.
Thanks for pointing out the thread. Actually thought of doing it myself as its a direct response from Sun, but you know, am very lazy

[Yanick Labelle]

Hi everyone, and thanks for the responces!
This is completly out of topic, but I just came back from the PHP Quebec conference in montreal, really cool stuff!
Back on topic...
So, if I understand, the employe enters the clients IDs in the jtable in the Client id column... When he clicks the book buttom, i have to try to book every room that now has a customer ID in the jtable...
About my other questions, do you guys print out the rooms that are already booked for information purpose?
I'm I right to think that it is illogical to display the rooms that have an available date in the past. (probably) What disturbs me is that the file given by Sun only have available dates in the past (2003, I think). So if someone executes the application, absolutly no data will be shown if we use this data file! Maybe the guy at Sun will set his system date in the past, I don't know
Should I show the rooms that are available, but (let's say) only in two weeks. Since the system allows to book rooms 48h in advance. Should I allow the user to book rooms many weeks in advance?

[Satish Avadhanam]

Hi Yanick

Originally posted by Yanick Labelle:
Hi everyone, and thanks for the responces!
This is completly out of topic, but I just came back from the PHP Quebec conference in montreal, really cool stuff!
Back on topic...
So, if I understand, the employe enters the clients IDs in the jtable in the Client id column... When he clicks the book buttom, i have to try to book every room that now has a customer ID in the jtable...

I have to say, that's a pretty impressing solution. But for the scope of the assignment here is what we are supposed to do. You can do more as much as we can think, but remember there will be no additional points for that
1. All I did is show a non-editable JTable(when I say non-editable, client cannot enter anything in the JTable as such).
2. CSR selects a room(I allowed only ONE SELECTION) one at a time.
3. There will be a book panel at the bottom or top of JTable with a owner JTextField and book button.
4. After selecting the room from the JTable, CSR has to enter owner ID and press the book button.
5. That is it. No multiple selections in my implementation and cannot enter anything in JTable.
I know this is the bare minimum, but it took me a while to do above functionality. So gave up on fancy things

About my other questions, do you guys print out the rooms that are already booked for information purpose?

I have shown them in the JTable. But when client selects the booked room, book button is diabled.

I'm I right to think that it is illogical to display the rooms that have an available date in the past. (probably) What disturbs me is that the file given by Sun only have available dates in the past (2003, I think). So if someone executes the application, absolutly no data will be shown if we use this data file! Maybe the guy at Sun will set his system date in the past, I don't know

Client can see all the records in database. But if the date is in the past, he cannot book as server throws an exception. This is what I did.

Should I show the rooms that are available, but (let's say) only in two weeks. Since the system allows to book rooms 48h in advance. Should I allow the user to book rooms many weeks in advance?
Well, you may allow it or not. If you don't want to do the 48hrs implementation, I think you can ignore and document it and then allow to book anytime.
FYI: Some ranchers did'nt implement this 48hrs requirement and passed with good scores. I think all they did is document a couple of lines or one in the choices document.

Good Luck.

[Yanick Labelle]

Hi, thanks for the really precise response!
I'm gonna do exactly that, a field near the book button to enter the custommer id (8 char, numeric... or less). then book!
New validations will be added to my book method, here is what I will add:
Check if the available date is in the past.
Check if the available date is more than 48 hours in the futur.
(In a new post from this forum, someone sais that he had an automatic failure for not implementing this rule)
The booking action will take place only if those conditions are false.
The JTable will be readonly and list all the records in the data file, or those matching the criteria... depending on the case. I will permit the user to select only one row at once.
Again, thanks a lot for the response, the help is really apreciated!

[Yanick Labelle]

Hi, just another precision, did you do a lot of work with the JTable to make it look better, or simply used JTable and an extention of AbstractTableModel for the data and columns names?
I've been reading a bit about the JTable and it seems that there is a lot of things that can be done, but is it really worth it (in this context).
Also, in the Sun certified java developer exam with j2se 1.4 book, the author only used JTable and an extention of AbstractTableModel... and made the columns resizable. Which gives a result that is really nice and easy to use without too much customization.

[Satish Avadhanam]

Hi Yanick

Originally posted by Yanick Labelle:
Hi, just another precision, did you do a lot of work with the JTable to make it look better, or simply used JTable and an extention of AbstractTableModel for the data and columns names?

I used a JTable, a class that extends AbstractTableModel and a class that extends DefaultTableColumnModel.

I've been reading a bit about the JTable and it seems that there is a lot of things that can be done, but is it really worth it (in this context).

We can do lots of things with JTable. But as far as I know, all we need to do is show the results in JTable, make the columns resizable and allow single selection to book. Beyond this we can do many more things using JTable, but I think we don't need them in the project context.

Also, in the Sun certified java developer exam with j2se 1.4 book, the author only used JTable and an extention of AbstractTableModel... and made the columns resizable. Which gives a result that is really nice and easy to use without too much customization.
[/qb]
Yeah right. I don't think we need anything beyond Max's book. He has given a complete idea in every aspect of project. If we understand the book and sample project thoroughly, we can easily complete the assignment.
Good Luck.
[qb]

[Satish Avadhanam]

Hi Yanick

Originally posted by Yanick Labelle:
Hi, thanks for the really precise response!
I'm gonna do exactly that, a field near the book button to enter the custommer id (8 char, numeric... or less). then book!

In my instructions it is clearly specified that its 8 digit number. So you many also want to check this.

New validations will be added to my book method, here is what I will add:
Check if the available date is in the past.
Check if the available date is more than 48 hours in the futur.
(In a new post from this forum, someone sais that he had an automatic failure for not implementing this rule)

You may also want to check if its already booked and in your design if you are not allowing to book an already booked room, then you don't want to book the record.
You also need to check if its 8 digit number and it must not be greater than 8 digit.
Also, its advisable to check whether the record has been modified or not on the server side because multiple clients are accessing in the server mode, and so there might be a chance that what is shown in the GUI is not exactly what is in the database while booking. Other clients may have modified, already booked or updated the record.

The booking action will take place only if those conditions are false.
The JTable will be readonly and list all the records in the data file, or those matching the criteria... depending on the case. I will permit the user to select only one row at once.
Again, thanks a lot for the response, the help is really apreciated!

[Yanick Labelle]

Yes, I was already checking if the the room is already booked (the user's data may be out of sync...) I do that in the book() method (which is executed on the server side).
I was also comparing the record passed by the user to what is currently in the database at that record number. This is quite impossible in this project, but in real life, someone could have deleted the record that we are working on and inserted a new room at the same record number (I re-use deleted records). When you try to book the room, you are in fact booking the wrong one. So this is why I compare the 6 first fields of the record passed by the user to the book() business method (every field except the customer ID) to what is currently in the database, if there is a change, the room is not booked.
I will look at the DefaultTableColumnModel class.
I will also check the customer ID validation carefully!
Thank you very much, your help is really appreciated.

[Satish Avadhanam]

Hi Yanick, I got a little doubt in the implementation you mentioned below

Originally posted by Yanick Labelle:
Yes, I was already checking if the the room is already booked (the user's data may be out of sync...) I do that in the book() method (which is executed on the server side).
I was also comparing the record passed by the user to what is currently in the database at that record number. This is quite impossible in this project, but in real life, someone could have deleted the record that we are working on and inserted a new room at the same record number (I re-use deleted records). When you try to book the room, you are in fact booking the wrong one. So this is why I compare the 6 first fields of the record passed by the user to the book() business method (every field except the customer ID) to what is currently in the database, if there is a change, the room is not booked.

So in the book method, you check if the data the user is seeing in the GUI is exactly same as in the data in the db and then only book right. If that's what you are doing then its ok. From the first four lines above, I got a different meaning so just want to let you know.
Also you should (a)lock the record, (b)check if the data is same or not, (c)book the record and (d)then unlock the record. If the protocol is like this, then we can make sure that between the time we check and the time we book the record, noone else can change/book.

I will look at the DefaultTableColumnModel class.
I will also check the customer ID validation carefully!
Thank you very much, your help is really appreciated.

[Theo van Loon]

Could someone please tell me how to validate the 8 digit value?

[Satish Avadhanam]

Hi Theo

Originally posted by Theo van Loon:
Could someone please tell me how to validate the 8 digit value?

First you need to make sure its greater than 0 digits and less than or equal to 8 digits. This you can do using lenght method of String.
Then you need to make sure its an integer number. You can do it using Integer.parseInt method.
Good Luck.

[Yanick Labelle]

Yes, the steps I did were:
lock
read
validations...
update
unlock

[Theo van Loon]

Yes i understand but how do you validate it is an 8 digit number?

[Jim Frank]

"The system your are writing does not interact with these numbers."
I assume that means to not use them, except in the data access class to determine/make if the record is available or not, and not to have them in the GUI.

[Jim Frank]

"The system your are writing does not interact with these numbers."
I assume that means to not use them, except in the data access class to determine/make if the record is available or not, and not to have them in the GUI.

[Satish Avadhanam]

Hi Theo

Originally posted by Theo van Loon:
Yes i understand but how do you validate it is an 8 digit number?

If I was'nt clear before, I will try to explain with a code sample.

String owner = ownerField.getText();
if ((owner.length() < 1) || (owner.length() > 8)) {
    Tell CSR("owner filed should be less than or equal to 8 digits");
    return;
}
try {
    Integer.parseInt(owner);
} catch (NFE ) {
    Tell CSR("owner is an 8 digit number");
    return;
}

First if statement tries to check if its less than or equal to 8 digits and try statement checks if its numberic or not.
Good Luck.

[Satish Avadhanam]

Hi Jim

Originally posted by Jim Frank:
"The system your are writing does not interact with these numbers."
I assume that means to not use them, except in the data access class to determine/make if the record is available or not, and not to have them in the GUI.

No. In order for the CSR to book a record for the customer, we must provide a way to enter the owner ID in the GUI. If we donot provide a way for the CSR to enter owner ID, it is not possible to book a room/hotel right. So we MUST provide a means of doing so.
Good Luck.

[Yanick Labelle]

Yes, the customer ID is validated at this step. But I also validate it in the gui to make sure that the user isn't allowed to enter other characters, a kind of input mask...

[Yanick Labelle]

I use the InputVerifier class...
custID.length() must be <= to 8
also, the parseInt will check if this is really a number.

[Theo van Loon]

String owner = ownerField.getText();
if ((owner.length() < 1) || (owner.length() > 8)) {
    Tell CSR("owner filed should be less than or equal to 8 digits");
    return;
}
try {
    Integer.parseInt(owner);
} catch (NFE ) {
    Tell CSR("owner is an 8 digit number");
    return;
}

First if statement tries to check if its less than or equal to 8 digits and try statement checks if its numberic or not.
Good Luck.[/qb]<hr></blockquote>
Sorry Satish i completely missed out on your prior post...
I must be working to hard on this, sometimes completely missing out on the simple things...
Could you do the validation client side so you only start booking when digit is validated, else show message?
[ April 01, 2004: Message edited by: Theo van Loon ]

[Andrew Monkhouse]

Hi Theo,

Could you do the validation client side so you only start booking when digit is validated, else show message?

I think Satish's code is client side: it looks like he is validating the text field he is reading from the form.
Another way of doing this is to create your own field which will only allow positive numbers to be entered. If the user cannot enter alphanumeric characters or more than 8 digits, then it is harder for them to make a mistake . To do this, you would extend JTextField and PlainDocument. See this post for an example.
Yet another way of doing this would be to use a JFormattedTextField, however there are issues with it.
Regards, Andrew

[Satish Avadhanam]

That's right, Theo. The validation is on the client side only. I think Server has to do a lot of other validation and moreover I think its better to do this owner field validation on client side only instead of travelling all the way to the server and doing the validtaion there.