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 session 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 Editing the core Jomres code, 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.
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 and extras to change, either by changing guest numbers, 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 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 as it's quite likely that the users will need to confer with family members to determine their requirements.
When a booking is finally processed ( IE added to the database ) then this booking information is stored in the Booking data archive. If a property is configured to use the Booking Enquiries feature then this archive data is reused later to complete the booking once it's been approved.
Room locking
The Booking engine includes a feature to lock rooms once a room has been selected in the booking form. This is to prevent two users attempting to book the same room at the same time. If they did, then the second person to actually complete the booking would be presented with an error message about double bookings.
Typically this timeout is set to 3600 seconds ( about an hour ) but you can change this in the Site Configuration - Booking form tab.