URLyBird : 48 hours rule enforced

[Alan W Morgan]

Hey all,

I read a few places that ppl were enforcing the 48 hour rule on the UI.
That is to say that if the date on the room if not within 48 hours of current date then you can't book it.

I was just looking at my data file and noticed that only 4 of them aren't in the past.
If I enforce this then how will anyone even test it as the chances of the test being within 48 of the date is very remote.

Thoughts ?

[Ta Ri Ki Sun]

Originally posted by Alan W Morgan:
Hey all,

I read a few places that ppl were enforcing the 48 hour rule on the UI.
That is to say that if the date on the room if not within 48 hours of current date then you can't book it.

I was just looking at my data file and noticed that only 4 of them aren't in the past.
If I enforce this then how will anyone even test it as the chances of the test being within 48 of the date is very remote.

Thoughts ?

They also asked you to implement the create method, and I suspect they've built some handy auto testing tools making this test an easy one.

[Alan Morgan]

Fair point.

I take it from your answer that

1. You think I should enforce this rule

2. I should have tests that create new rooms for the purposes of my own testing.

So I am going to implement this in the Controller, so that my book() method has a date check.

Thanks

[Ta Ri Ki Sun]

Originally posted by Alan Morgan:
Fair point.

I take it from your answer that

1. You think I should enforce this rule

2. I should have tests that create new rooms for the purposes of my own testing.

Yep and yep, as for the controller validating I dunno, wherever you feel it's at home.

[Paul Bourdeaux]

1. You think I should enforce this rule

Definately enforce this rule. Not doing so has resulted in automatic failures in the past! I also agree with Ta Ri Ki Sun as to creating new data for your own testing.

[Uwe Schäfer]

Originally posted by Paul Bourdeaux:
1. You think I should enforce this rule

Definately enforce this rule. Not doing so has resulted in automatic failures in the past! I also agree with Ta Ri Ki Sun as to creating new data for your own testing.

i suppose automatic tests are run against DB as it is the only implementation known to sun, prior to looking at one�s project.


IF we are supposed to enforce the 48h rule, AND it is tested automatically, DB.update WHOULD be the only place for this.

unfortunately i see some issues with that:

1. i�d have to find out while updating if it involves booking (Yak! ugly to virtually impossible)
2. the method does not leave the option of throwing a checked exception signalling the 48h rule stuff as this situation can not really be expressed by SecurityException or RecordNotFoundException (or a subclass of them) in an acceptable manner

As i have a unique place for the book() stuff, i�d suppose the enforcement of the 48h rule is best suited there. (in the business layer, ABOVE the DB)

But of course, i fear automatic failure as much as any one of you, so i�d love to hear your opinions.

[Alan Morgan]

Good point Uwe,

If they are gonna run automatic tests against the DB layer for this rule then I need to know that, cause a controller implementation could lead to...gulp...automatic failure.

[Uwe Schäfer]

Originally posted by Alan Morgan:
Good point Uwe,

damn. i wished i missed anything and someone would wake me up and show us some easy way out of this

i fear that simply documenting this in the design decisions
might be not enough.

any other opinions ?

[Paul Bourdeaux]

I actually had the B&S assignment, so I don't know the exact wording of the 48 hour rule. Could someone post it?

Without seeing it, my belief would be to enforce it in the book method and document your decision.

[Alan W Morgan]

The wording in the background section of the application overview which is the only place it is mentioned is as follows :

"URLyBird is a broker of discount hotel rooms. They sell accomodations for business and pleasure travellers at short notice, helping hotels to fill rooms that would otherwise be left empty. They take bookings only within 48 hours of the start of room occupancy. Curently, URLyBird sells the rooms over the phone using a team of customer service representatives (CSRs). The CSRs interact with an aging custom-written application that has been drawing increasing criticism from the CSRs. In the future, URLyBird wants to move into Internet-based marketing, and hopes to be able to accept bookings direct from customers over the web. "

[Muthaiah Ramanathan]

Hmm - So what happens to people, like me, who validate the booking date at the client side (view)? Any test scripts to test the DB, the update in this case, would fail (by not enforcing the 48h rule).

I have a dialog that takes the input from the user for the booking and checks there itself if the given booking date is valid or not. Only if it valid it does a update call on the DB.

So - what is the verdict here?

[Ta Ri Ki Sun]

Originally posted by Muthaiah Ram:
Hmm - So what happens to people, like me, who validate the booking date at the client side (view)? Any test scripts to test the DB, the update in this case, would fail (by not enforcing the 48h rule).

I have a dialog that takes the input from the user for the booking and checks there itself if the given booking date is valid or not. Only if it valid it does a update call on the DB.

So - what is the verdict here?

I don't believe the db update method is the place to do it, if you used sql or an EJB for db updates would you still feel it belongs there? If not why is this any different?
You must have some sort of method that books a room right? Then either call a method that validates the date prior to locking the record, or do it where the client's input is accepted, or both in case a different client is used but this is perhaps overkill.
IMO Business rules have no place in update, whatever you do document your choice and if you can defend it you'll be alright.

[donal horgan]

I'm kinda confused as to what you are all saying but basically all i did was have a drop down menu on the GUI for "Tonight" or "Tomorrow night" for booking.
Then go straight toi the Data.java class from there.

[Ta Ri Ki Sun]

Originally posted by donal horgan:
I'm kinda confused as to what you are all saying but basically all i did was have a drop down menu on the GUI for "Tonight" or "Tomorrow night" for booking.
Then go straight toi the Data.java class from there.

Check your db schema, there's a date column. That date is the only available date, there's no tonight and tomorrow. If the user selects a particular record they have selected that one date, and you have to ensure that date is within 48 hours of that click to make the booking.

[Alan Morgan]

I think we're agreed that in principle the 48 hour rule is a Business Rule and therefore has no place in the Data layer.

However the question is is there some kind of automated testing that will go straight to the data layer that will expect this rule.

For example create() cannot be tested except by going straight to Data layer.

I'm probably gonna do it in Controller and document decision but I was concerned by talk of automatic faliure if not implemented properly.

[Jesse Xie Y.S.]

Excute me, I want to give my comments about this topics after I look around this forum about within 48 hours requirement.

1. I think that we should implement this requir, otherwise, my assigment is very simple just do the requirement that marked MUST. But the must requirement is the Automatic Failure requirement. And the other is for your good score requirement I think.

2. The within 48 hours requirement should be implemented in the logical layer, but not the Database layer, because database just only know how to lock & unlock record for update and how to save data into file, and but not the client gui layer, because the within hours rule should be checked according the time in the server, so no matter what time is it in client.

3. I would like to assume that the time of the start of room occupancy in URLyBird company is at noon AM 12:00 (It must be documented in the choice.txt). In other word, customer onwer the room which booked by themself begin from AM 12:00 to next day AM 12:00. So, to check if a room is bookable according to the within 48 hours, just caculate as follow method:
Date dateAvailable = GET_THE_DATE_IN_RECORD & SET 12:00 AM AS ITS TIME;
Date currDate = GET_CURRENT_DATE;
Date within48 = CURRENT_DATE + 48 HOURS;
if(dateAvailable.after(currDate)&&dateAvailable.before(within48)){
TRY_TO_BOOK_THIS_ROOM
}else{
THROW_UNBOOKABLE_ROOM_EXCEPTION
}

any comments tks.

[Jesse Xie Y.S.]

OK, I just test the following code for your information


Date roomDate = DATE_AVAILABLE_FIELD_VALUE;
Date currDate = new Date();
Date within48HDate = new Date();

within48HDate.setTime(currDate.getTime() + 48 * 60 * 60 * 1000);

if (roomDate.before(currDate) || roomDate.after(within48HDate)) {
throw new UnbookableRoomException("Out of 48 hours exception");
}

[Kuno Snaglers]

You MUST implement this feature in a way!! I just failed because of the automatic failure....

I think the DB-Layer is not the place for and don't have a buisness layer. So, I will implement it in the Controller.

I'm thinking about hiding the other records that aren't within 24H. I don't see the point why the CRSs shall be able to see records in the past or more than 2 days in the future.

Kuno

[Oricio Ocle]

Hello ,
I totally agree with you Uwe,
'Automatic requirements' only have sense in the data layer, behind the Sun provided interface...
Otherwise date (business) considerations at that low level is at least unusual...
Regarding the use of cookies one of Adrew's justifications was that the provided interface could serve access not only to the CSR personal, also other kind of clients like an admin tool.

Literally in my specs:

Initially, the system will support only the CSRs, although the hope is that this interim step will give them a starting point for migrating the system to the web

and i agree with him, presence of cookies lead us to consider that the interface is thought to serve more clients that CSR's given that these don't need cookies at all.

With this in mind, 48h rule in data layer is more than unusual, is contradictory.

For the time being I decided implementing the rule in the business layer in my book method, and documenting the decision

And my question is:
are you absolutely sure that automatic testing can be done only at the provided interface?

Regards

[Thomas Hawk]

Originally posted by Kuno Snaglers:
You MUST implement this feature in a way!! I just failed because of the automatic failure....

Kuno

Is the word must used in conjunction with the 48 hour rule in your instructions? If not, then the 48-hour rule is not an automatic failure condition. Assuming you justified why you did not enforce it in your design choices document, you should be able to appeal the automatic failure. I originally received an automatic failure for not enforcing the 48 hour rule and successfully appealed and passed. It took several weeks so you'll need to be patient.
[ September 28, 2005: Message edited by: Thomas Hawk ]

[Kuno Snaglers]

I don't know how they test it, but I failed because of the automatic failure. I guess they have a horde of indian students that test our application with a script or any else ;-}

Kuno

[Krzysiek Hycnar]

Hi,

The 48 hours rule is NOT a must! It's just a "nice to have" feature. Read the 48 hour rule thread. So you can safely do nothing about that, but I believe it's a good idea to document it in the choices.txt

To Kuno:

If you did nothing about the "48 hours rule" and documented your choice you should definitely appeal. (If I were you, I would appeal even without mentioning it in the choices.txt - it goes without saying that it's not a must).

Cheers
Krzysiek
[ October 05, 2005: Message edited by: Krzysiek Hycnar ]

[Kuno Snaglers]

I agree with you - I didn't think about this option. Anyway, it's almost done and I want to be on the save side this time:-}

THanks
Kuno