Introduction

 

This section is a brief discussion regarding the operation of the booking engine.

 

The booking engine's main goals are to be as simple as possible to use, removing as many decisions from the hands of the user as possible, guiding them through supplying all the information that they need to enable the system to take a booking from them.

 

The booking engine in Jomres is an AJAX driven booking engine designed to make the process of finding available rooms in a property as simple as possible. We use AJAX because it allows the user to experiment with their requirements without having to use the tired old Click -> Submit routine that normally would be used to find and book a room on a truly real time system, or the substantial costs involved with interfacing with a GDS.

 

 

The Engine's files

 

Whilst all operations in Jomres go through the file jomres.php the main files used to generate and perform the booking are done through

 

jomres.js contains all of the booking form Javascript (excluding the actual AJAX Javascript class).

dobooking.php generates the booking form when the user selects the booking link. It builds all of the data required to construct the booking form, initialises the booking data in the Jomres internal sessions and calls the booking form template file.

handlereq.php receives all the AJAX queries from the booking form and passes them into the booking object for processing.

dobooking.class.php contains the booking object class

j05000bookingobject.class.php is called by dobooking.php and handlereq.php, extends the booking object found in dobooking.class.php.

 

If you want to modify how any of the methods in the dobooking class works, you are advised to see this page, which will show you how to apply changes in a way that will make upgrading your Jomres installation easier in the future.

 

All of the booking engine functionality is provided by the jomres_booking class. This class isn't called directly, rather it is called and extended by the booking class which can be found in j05000bookingobject.class.php. The reason we don't call the file directly is fairly straightforward: by creating a new object booking and putting it into a minicomponent of it's own, it's simple enough to override the basic workings of the booking engine without actually editing any of the core Jomres files.

 

How it works

 

Summary

 

The aim of the booking form is to allow the guest to query room and extras prices and tailor a booking to their requirements all on one page. When they've constructed their booking they can then go to the Review Booking page.

 

In more detail

 

When a user clicks on an element in the booking form, depending on the element selected the Javascript will trigger an AJAX query which will call the task ''handlereq''. The ''handlereq'' task then triggers the inclusion of ''handlereq.php''.

''handlereq.php'' determines the element changed in the booking form and puts this into the variable $field, then ''handlereq.php'' will call various class methods depending on which element was changed. When this is done available & selected rooms are returned as output to the booking form and then the show_log Javascript function is triggered. This again calls the handlereq task and any messages required are passed back to the user, as are pricing information and finally, if the booking form is judged to be complete, the Review Booking button is enabled.

 

Types of information

 

There are two types of information that are passed to handlereq, Booking Particulars and 'other data'. Booking Particulars are details about the booking that will potentially cause the list of available rooms to change, either by changing guest numbers, smoking options or of course the dates of the booking itself. Other data would be guest names, selected extras etc.

 

The filtering process for available room and tariff combinations

 

When one of these particulars is changed the system will build the booking object and query all of the rooms on the system using the following methods:

 

getAllRoomUidsForProperty

findFreeRoomsInDateRange

checkPeopleNumbers

checkSmokingOption

removeFromSelectedRooms

removeRoomuidsAlreadyInThisBooking

getTariffsForRoomUids

 

The names of the methods are fairly descriptive, but in short all of the room ids are found, and by a gradual process of elimination all rooms who's various status fails to match a given set of criteria are dropped from the $freeRoomsArray variable. This last set of rooms is sent then to the getTariffsForRoomUids method, which will find any tariffs who's criteria also match the particulars of the booking. If a tariff passes then the room id is concatenated to the tariff id with a hat (^) symbol (eg. 3^20).

 

An array of these rooms/tariff ids is built up and eventually this is passed back out of the method. This concatenation allows us to offer a room multiple times for as many tariffs as are valid in that period and room types, so you can for example offer numerous different tariffs over the same time period, offering eg Simple Bed and Breakfast, or Bed, Breakfast and Evening meal tariffs for the same room over the same time period.

 

This array of room ids and tariff ids is then passed to the generateRoomsList method which actually creates the lists of available and selected rooms for display in the booking form.

 

Once the rooms list has been passed back show_log is called, and depending on what was previously changed it may or may not recalculate the price list. If Yes, then the ''generateBilling'' method is called, this will trigger the pricing calculations to be performed, then finally various data is returned  to the jomres.js script and evaluated using mainly the getElementById Javascript function to set various divs in the booking form to the updated fields.

 

How the booking information is stored

 

Jomres stores information in the /jomres/sessions directory in "session" files. These files are constructed and maintained by the ''jomres_temp_booking_handler'' class in ''tempbookinghandler.class.php''. This information is mainly about the user's address details and booking requirements but some other information is stored in there too. In the past this information was stored in the database but it proved a slow method of storing and retrieving information so we changed the system to store the information in the session files instead.

 

This information is only retained for as long as the session is active. As some systems have a very short session timeout period set we use a "heartbeat" function in the booking form to keep this information alive whilst the user is on the booking form page.