confused about 48 hours rule check.

[Olena Golub]

Hi all,

I am a little bit confused about 48 hours rule check.
Where should I implement it?
In GUI: After the user pressed the "book" button. If the booking time is less than
the 48 hours the program notifies the user and cancels the booking. The drawback of this is
that the record can not be actual.

In Data: before the update is called this will be checked. But this has also one drawback:
the user will not be notified that the booking is not complited.

Where and how did you implement this rule?
Thanks a lot for your help and comments.
Regards,
Olena.

[Wei-ju Wu]

Hi Olena,

even though I know there are people opposing this approach, I placed the check for the 48 hour rule into my business tier, which means I chose an n-tier approach. This makes it easy to use the same code for doing the check either in the search() function, in the book() function or both.

If you chose the 2-tier approach, you can (or will have to) place it in the model part of your user interface. The DB interface does not lend itself easily to business specific implementation.

From the user perspective it would be even better if the records that can not be booked are not be displayed at all, at least so I would think.

HTH

Wei-ju

[Ta Ri Ki Sun]

Originally posted by Wei-ju Wu:

From the user perspective it would be even better if the records that can not be booked are not be displayed at all, at least so I would think.

hmmmm, personally I think that record is of interest to the user, many websites, particularly for airlines, display flights you cannot yet book.

Your approach raises another issue, will you also hide records that have already been booked?


Olena Golub :

In Data: before the update is called this will be checked. But this has also one drawback:
the user will not be notified that the booking is not complited.

I don't do it in Data, it's not really at home there.
I implemented the business rules in the class and method that does the booking.

[Wei-ju Wu]

Yes, it is the other thing I added to my business logic, it is checked during search and booking so you can neither find nor book records that are already booked by some other person.

I understand that one could discuss about whether to diplay or not to display the records that are not available anyways, from my point of view I would not be interested in hundreds of records that could not be booked .....

[Ta Ri Ki Sun]

Originally posted by Wei-ju Wu:
Yes, it is the other thing I added to my business logic, it is checked during search and booking so you can neither find nor book records that are already booked by some other person.

Redundant code?

I understand that one could discuss about whether to diplay or not to display the records that are not available anyways, from my point of view I would not be interested in hundreds of records that could not be booked .....

I'm with you, but surely the system is not built only for booking. A user may only be interested to know which rooms/dates have in fact been booked, or by which client, perhaps even tracking a client's stay at various hotels over a certain period, and your GUI will never show them that.
Besides the system has search functionality, so the users can narrow their results.
Also consider that cancellation of a booking, if implemented in future, would require more coding effort than it would otherwise need.

[Wei-ju Wu]

Originally posted by Ta Ri Ki Sun:

Redundant code?

These are actually the same objects implementing two different interfaces and used in the search and the booking functions (the search can be configured with search filters, the book() with so called "constraints"), there is the choice whether to place it in searching, booking, both or none at all

Originally posted by Ta Ri Ki Sun:

I'm with you, but surely the system is not built only for booking. A user may only be interested to know which rooms/dates have in fact been booked, or by which client, perhaps even tracking a client's stay at various hotels over a certain period, and your GUI will never show them that.
Besides the system has search functionality, so the users can narrow their results.
Also consider that cancellation of a booking, if implemented in future, would require more coding effort than it would otherwise need.

Well, at least that is what I understand from the specification: That it is for booking Since the nature of the business described in the URLyBird project is simply to support CSRs selling rooms I would not put any tracking functionality into that application - this would be more CRM-related. Could be part of a larger system though...

But you truly are right - cancellation would not be easy if the search can not give you at least the records that are already booked, an aspect I have not thought about yet.

Thanks

Wei-ju

[Olena Golub]

Thanks a lot for your help.
Sorry, I made a mistake, I meant the DataAdaptor (business-Logic).

I think also that we need to display also the already booked records and the records that are not
satisfing the 48 hours criteria.

Regards,
Olena