Contents
- Index
Customisation
This discussion and any downloads can be found online at the jomres.net forums.
Most people want to make changes to their Jomres installation. Whether it's to just modify the layout (you can edit the templates for this) or to modify the functionality of a given part of the script (like adding different data to the header, for example) there's a number of ways you can achieve this.
You can take the simple approach, which is to edit the core Jomres files but if you do that you'll need to make a careful note of all your changes and remake them when you upgrade and it's not a very good solution.
There are two other ways you can make changes that mean that you're less likely to suffer when you need to upgrade, each of the ways are valid but they have their strengths and weaknesses.
1. External Minicomponents
2. Simple Data Inserts
External minicomponents can be considered straight replacements for the existing code. They are installed like a normal Mambo/Joomla component but used only by Jomres. I'll give you an example.
The normal property header script is j01070showpropertyheader.class.php and resides in the core-minicomponents folder under components/com_jomres. If jomres, when it starts running, finds another version of j01070showpropertyheader.class.php in either remote_plugins/XXXfolder or another com_jomcomp folder then it'll use that instead, allowing you to completely change the functionality of that script in another file that's outside the normal Jomres directory structure and therefore not subject to change in the event of an upgrade. The disadvantage of this is if that particular file in the core changes a lot you might run into functionality problems when your script interacts with Jomres, although this is unlikely. What's more likely is that you won't be able to take advantages of any new changes in a new version of the same core minicomponent. Nevertheless, it's a good option.
The other way to do it is to use the Simple Data Insert feature. As nearly all of the changes that people want to make are to cutomer facing scripts the functinality is generally limited to customer mincomponents. These are:
j00015viewproperty.class.php
j01010listpropertys.class.php
j00010reception.class.php
j00011manager.class.php
j01020showtariffs.class.php
j01025showtariffs.class.php
j01055showroomdetails.class.php
j01070showpropertyheader.class.php
I've never used the receptionist/manager options and imagine that really the only ones of real interest are the view property, property header and list properties calls (list properties is a special case because it actually has two simple data inserts available, one that can be applied to each property in the list, and one that can be applied to the template overall). They generally consist of a small minicomponent/script that has exactly (except for list properties) the same trigger number as the the minicomponents they're designed to collect data for, so for example if you look at the carousel plugin (http://forum.jomres.net/index.php?topic=245.0, download and extract it locally) you'll see j00015a_property_details_slideshow.class.php which is a simple data insert for the view property script. It's named "a_XXXXX" because minicomponents are called in alphabetical order therefore we want to collect the data before j00015viewproperty.class.php itself is called. It's then a case of adding some special code to your template to make sure that the data collected by this plugin is inserted into the template by adding some code to the template:
<patTemplate:tmpl name="customOutput_a_slideshow">{SLIDESHOW}</patTemplate:tmpl>
Note the name of the customOutput string matches the name of the plugin that would be called, in this case j00015a_slideshow.class.php and that SLIDESHOW is the name of the array index passed back by j00015a_slideshow.class.php**.
Whilst the SDI functionality is called "Simple Data Insert" the actual implementation is slightly trickier than just creating a minicomponent because you need to make sure that the data you've inserted into the template is referred to correctly, but it's by far the better way to make changes to Jomres that will not be overwritten by the next upgrade of Jomres, and you'll still have access to any updates to the calling script (eg. j00015viewproperty.class.php).
** If you're trying to track these calls through the code to understand for yourself how they work, the important parts are (in the case of view property)
$mcOutput=$MiniComponents->getAllEventPointsData('00015');
if (count($mcOutput)>0)
{
foreach ($mcOutput as $key=>$val)
{
$tmpl->addRows( 'customOutput_'.$key, array($val) );
}
}
Otherwise you can just take my word for it.