Download Now!
Documentation

Contents
1. Quick Setup Instructions
2. Before You Begin
2.1. Important Questions
2.2. Requirements
3. Installation and Setup
   3.1. Quick Setup
   3.2. Download
   3.3. Uncompress the Archive
   3.4. Modify Perl Scripts
   3.5. Transfer files to the web server
   3.6. Modify File Permissions
   3.7. Run the Admin Application
4. Troubleshooting Installation
5. Getting Started
   5.1. Basic Concepts
   5.2. Calendar Display Basics
   5.3. Calendar Admin Basics
6. Administrative Application
   6.1. Login Screens
   6.2. Events
   6.3. User Admin
   6.4. Calendar Options
   6.5. Global Options
7. Customization
   7.1. Display Templates
     7.1.1. Template Introduction
     7.1.2. Template Procecssing Flow
     7.1.3. Template Example
     7.1.4. Tag Syntax
     7.1.5. Special Calendar Tags
     7.1.6. Defined Variables
     7.1.7. Include Files
     7.1.8. Retrieving Events
     7.1.9. Template Debugging
     7.1.10. Advanced Notes
   7.2. Template Reference
   7.3. Customizing Admin Templates
   7.4. Language Translation
8. Plugins
   8.1. Concept
   8.2. What Plugins Can Do
   8.3. The Basics
   8.4. Adding Permissions
   8.5. Adding Admin Menu Options
   8.6. Adding and Overriding Templates
   8.7. Adding Custom Functionality
9. Advanced Usage
   9.1. SSIs
   9.2. Command-line
10. Security Considerations
   10.1. Changing File Locations
   10.2. Encrypted Passwords
   10.3. File Locking

Printer-friendly Documentation

Customization


Modifying Display Templates

Template Introduction

The output of the calendar display is extremely flexible and easily changable through the use of templates. These templates define how the data should be displayed, and consist of plain HTML, some special calendar-specific tags, and possibly some actual Perl code. By modifying these templates, you can make the calendar display fit into your site design and/or completely change the design of the output. There are almost no limits, and the true power of this program lies in the fact that you can make it do almost anything.

Modifying existing templates will most likely be very simple for anyone familiar with HTML. You can add a header, change colors, add graphics, or whatever you wish simply by editing an existing template style and changing the HTML. To do more advanced changes and customization, you will need to familiarize yourself with the special calendar tags designed for use in the calendar templates. To get full control over the templates and make the most radical and advanced changes, you will need to be familiar with the Perl programming language.

The display template files themselves are located under the 'calendarscript/templates/calendars' directory. A template set may consist of any number of files, or possibly just a single file. Each different template design is stored as its own directory, with the template files themselves in the directory. This directory name is what will show up in the 'Current Calendar Settings' screen when choosing which template style to use for any given calendar.

When the calendar program is called by your web browser, it processes the request and loads the appropriate template file. The template files is parsed, values are filled in, and then the output is sent back to the browser to be displayed. Therefore, the templates aren't actually called by themselves, but instead are used internally in the program.

If the calendar is not specifically told which template to load, it will try to load the file called 'default.html' in the defined template directory. The output of this template can then link back to other templates to be displayed. You could then have different ways of displaying the calendar data (month, week, day, grid, list, etc) each have their own template file, and the template files would link to each other.

Template Processing Flow

The following is an explanation of the steps that the program goes through when processing a template to display.
  1. Load the template file. If there is an error or the template doesn't exist, an error will be shown to the screen.
  2. Load all include files and insert them into the template, if applicable.
  3. Remove all comments from the output, in the format <!-- comment -->
  4. Replace all calendar-specific tags with the Perl translation
  5. Convert all plain text/HTML into Perl "print" statements.
  6. Do an eval() of the resulting code (run it) and capture the output.
  7. In the case of an error processing the resulting code, display the original and converted template to the browser for debugging.
  8. In the case of a successful execution, display the output to the browser.
Template Example

Below is an example of a very simple display template. It will display a typical monthly calendar grid, with the title of each event in the grid, and links to the next and previous months. Note the special syntax and tags embedded in the HTML to generate the display.
<%
&getEvents( { 'range'=>'month' } );
%>
<HTML>
<HEAD><TITLE>Calendar</TITLE></HEAD>
<BODY>
<CENTER>
<TABLE BORDER=1>
<TR>
   <TD ALIGN="center" COLSPAN="<%=$Grid->{'colcount'}%>">
      <A HREF="<%=$CGI_URL_QUERYSTRING%>month=<%=$LAST_MONTH%>
&year=<%=$LAST_MONTH_YEAR%>">&lt;&lt; <%=$LAST_MONTH_NAME%></A>
      &nbsp;&nbsp;&nbsp;
      <FONT SIZE="+3"><%= $MONTH_NAME %> <%= $YEAR %></FONT>
      &nbsp;&nbsp;&nbsp;
      <A HREF="<%=$CGI_URL_QUERYSTRING%>month=<%=$NEXT_MONTH%>
&year=<%=$NEXT_MONTH_YEAR%>"><%=$NEXT_MONTH_NAME%> &gt;&gt;</A>
   </TD>
</TR>
<TR>
<%FOREACH GRID COLUMN%>
   <TH><%= $Grid->{'daynames'}->[$COL] %></TH>
<%/FOREACH%>
</TR>
<%FOREACH GRID ROW%>
<TR>
   <%FOREACH GRID COLUMN%>
   <TD VALIGN=TOP WIDTH="14%">
      <%IF DISPLAY%>
         <B><%=$DAY->{'dd'}%></B><BR>
         <%FOREACH EVENT%>
            <FONT FACE="arial" SIZE="-2">&#149;
<%= $EVENT->{'details'}->{'title'} %></FONT><BR>
         <%/FOREACH%>
      <%/IF%>
   &nbsp;</TD>
   <%/FOREACH%>
</TR>
<%/FOREACH%>
</TABLE>
</CENTER>
</BODY>
</HTML>
Tag Syntax

The templating system in this application is designed to look and function in a way that is similar to ASP and JSP. This way, it will look familiar to anyone familiar with those common web technologies and will also appear correctly syntax-highlighted in editors such as Homesite, which understand ASP/JSP.

This templating system introduces two new forms of syntax for tags.

1. <%= VALUE %>

This tag format displays a value to the screen. Anything between the <%= and %> tags is evaluated and its value is displayed in output. These are some examples of output expression tags and their display values:
<%= (3+4) %> = 7
<%= $DAY %> = The value of the $DAY variable
<%= &func() %> = The output of the Perl subroutine called 'func'
The contents of the <%= %> tag are fed directly into Perl's "print" statement. So, a statement like this: <%= (3+4) %> becomes this after the template is parsed: print (3+4); Keep this in mind when creating your templates so as not to create syntax errors.

2. <% CODE %>

This tag contains Perl code, or pre-defined special tags which get translated into Perl code. Any Perl code embedded inside these tags will be executed like normal.

This is a small example of a block of template text and an explanation:
<% foreach $i (0 .. 10) { %>
<%= $i %><BR>
<% } %>
The text between the <% %> tags is standard Perl code that counts from 0 to 10 and puts the value into the $i variable. Then the <%= $i %> outputs the current value of $i for each time through the loop and appends a "<BR>" at the end for a new line. When the template parser processes this junk of code, it would turn it into exactly this Perl code:
foreach $i (0 .. 10) {
print $i; print "<BR>";
}
When executed by eval() this code would function just as it would if put into a Perl script by itself and print the expected output.

Special Calendar Tags

A number of tags are supported in the calendar templates which are specific to the calendar application. These special tags are translated into perl before the rest of the template is executed.

An example is this tag: <% NEXT MONTH LINK %>

By itself, this would generate an error, because the text "NEXT MONTH LINK" is not valid Perl code, and would cause a syntax error. However, this special tag is replace with valid (and somewhat complex) Perl code to generate a link to the next month of the calendar display. These special tags or provided to simply the templates, and make it easier to customize without having to learn the internal operations of the calendar.

Many of the special calendar tags are used to loop through days or events, or to decide whether certain things should be displayed. These have very easy syntax, so looping through days or events and deciding what to show is easy. This is an example of a simple loop/conditional blocks:
<% IF EVENTS EXIST %>
   <UL>
   <% FOREACH EVENTLIST %>
      <LI><%= EVENT FIELD(title) %>
   <% /FOREACH %>
   </UL>
<% ELSE %>
   No events Exist
<% /IF %>
In this example, the "IF" tag here is used to determine if there are any events to display. If there are, it loops through each event and displays the event's title in a bulleted list. If there are no events, it displays the "No Events Exist" text.

For a complete list of special tags and their meanings, see the Template Reference section later.

Defined Variables

There are a number of Perl variables defined in the calendar templates which do not have their own special tags. These variables are, by convention, all uppercase. You can reference these variable values just as you would any other Perl variable in your template, either in a display tag or in a code tag.

An example of this is $TODAY_MONTH, which holds the month number of today's date. There is no special tag to display this, but inserting <%= $TODAY_MONTH %> in your template will display its value. You can also reference in perl code such as <% if ($TODAY_MONTH > 6) %>. The full list of defined variables is available in the Template Reference section.

Include Files

Other files can be included into a template, much like Server-Side-Includes on a typical web server. Since the templates are not actually processed by the web server, but by the calendar program instead, the include commands do not function exactly as SSI's do. However, the syntax is similar in order to be familiar to those who use SSI's.

The syntax to include another file is:
<!--#include file="filename.html"-->
All file paths are relative to the template directory, so including a file like "header.html" will look for the file in the same directory as the file that is including it. You can use ../ relative paths to go up a directory.

Included files can be named anything, and have any extension - they do not need to be called .html files. Included files may contain Perl code that will be inserted into the template just as if it was there to begin with. Included files may not, however, include other files. If an include statement is contained in an included file, it will simply be ignored.

Retrieving Events

When creating a display template, and obvious task it must perform is to load the events that it will display. Events and their schedules are not loaded by default - it is up to the template to decide which range of events it wishes to load. This is because each template may be displaying a different date range, or a diferent type of event. It should know which events it needs to retrieve. Once the call is made to load the events, the calendar program retrieves them, stores them into special variables, inserts them into a grid in the proper places, and prepares special tags to be available in the rest of your template.

The call to retrieve events is done via the getEvents() subroutine defined in the calendar program. This call should be placed at the top of your template (assuming the output of the particular template contains events). An example call to load events is:
<% &getEvents( { 'range'=>'month' } ); %>
This loads all events and their schedules contained in a certain month (the range). By default, the getEvents() call will use dates relative to those currently selected. That is, if January 2001 is currently being displayed, and you click a link to go to the next month, the above line will get events for February 2001. You can of course over-ride this behavior and retrieve events for a specific year, month, date, or range if you wish.

The call to retrieve events is a standard Perl subroutine which takes an associative array of values as its argument. The general format is:
&getEvents({ name1=>value1 , name2=>value2 , name3=>value3 });
For a list of all possible arguments to this function and what effect they have on the events being retrieved, see the Template Reference section.

Retrieving A Single Event

Like the getEvent() function to retrieve a list of events, there is also a function to retrieve a single event. This is useful for a screen which displays the details of an event, for example. The format of this call is:
<% &getEvent( event_id ); %>
Template Debugging

If a template contains an error - usually invalid Perl code between <% %> tags - then an error screen will be displayed with debugging information. The actual error reported by Perl will be shown, followed by the original template, then the Perl code generated by the template after parsing. The line where Perl reported the error will be highlighted in yellow, and a link to the line is provided at the top in the actual Perl error message reported.

Occasionally, due to how Perl locates the source of an error, the actual line causing the problem may be a little above or below the highlighted line.

Advanced Notes

For template designers who are familiar with Perl, here are some additional noted which may be useful:
  • The code generated from the template is executed in a package called 'Template'. You can access other information in the application, if necessary, by directly accessing the $main:: package as usual.
  • All form parameters passed into the script in the URL or via a form can be found in the %in hash in the Template package.
  • Config file values may be retrieved by using the $Config and $AdminConfig objects in the Template package. To diplay the value of config field "foo" use the syntax: <%= $Config->get("foo") %>
Template Reference

Template Tags

These are special tags that are specific to the calendar display, and have special meaning.

<% code %> Evaluate Perl code
<%= expression %> Print out the value of expression
<% CALENDAR NAME %> The name of the currently-displayed calendar
<% CALENDAR KEY %> The key of the currently-displayed calendar (to be used for linking, etc)
<% CALENDAR DESCRIPTION %> The description of the currently-displayed calendar
<% FOREACH GRID ROW %> ... <% /FOREACH %> Loops through each available row in the grid of dates, setting the variable $ROW to the row number, beginning with 0
<% FOREACH GRID COLUMN %> ... <% /FOREACH %> Used inside of the "FOREACH GRID ROW" tag, this loops through each column available in each row, beginning with 0. It sets the value of the $DAY variable to be a reference to the day in the current Grid Row/Col, and sets the $EVENTS variable to be a reference to that day's events
<% FOREACH HOUR OF DAY %> ... <% /FOREACH %> Loops through the hours of the day, so you can pull out events by hour. The first 'hour' returned is '99' which is code for 'All Day Events'. The first and last hours of the day that are returned are specified in the config file as 'days_hours_display_start' and 'days_hours_display_end' but there is no interface in the Calendar Admin to change them - they must be changed by hand. This loop works on the current $DAY reference, so this must be used in a context where $DAY is defined. Inside the loop, the $EVENTS variable is set to be a reference to the list of events for that hour of that day.
<% FOREACH EVENTLIST %> ... <% /FOREACH %> Loops through each day existing in the current view without respect to the grid. It sets the $DAY variable to be a reference to the day, and the $EVENTS variable to be a reference to the events for that day.
<% FOREACH EVENT %> ... <% /FOREACH %> Loops through each event in the current list of events held in the $EVENTS variable, setting the $EVENT variable to be a reference to each event.
<% FOREACH SEARCH RESULT %> ... <% /FOREACH %> Loops through each event that exists in the search results, if a search was done. It sets the $EVENT variable to be a reference to each event in the results.
<% IF SEARCH RESULT %> ... <% /IF %> Evaluates the block if a search was just executed.
<% IF SEARCH RESULTS EXIST %> ... <% /IF %> Evaluates the block if at least one search result is returned as a result of a search.
<% IF EVENTS EXIST %> ... <% /IF %> Evaluates the block if the current $EVENTS variable contains at least one event.
<% IF NO EVENTS EXIST %> ... <% /IF %> Evaluates the block if the current $EVENTS variable does not contain any events.
<% IF NEXT OCCURRENCE EXISTS %> ... <% /IF %> Evaluates the block if the current event held in the $EVENT variable is set to occur any time in the future.
<% IF DISPLAY %> ... <% /IF %> Evaluates the block if the $DAY variable contains a reference to a day which should be displayed. In a Grid display, for example, some of the grids do not contain actual dates, so you should not attempt to display the date number in that grid cell.
<% IF SELECTED %> ... <% /IF %> Evaluates the block if the current day in the $DAY variable is selected as the date to highlight or show in detail.
<% IF USER LOGGED ID %> ... <% /IF %> Evaluates the block if the current user is logged into the calendar.
<% IF ... %> block1 <% ELSE %> block2 <% /IF %> The ELSE tag is used in conjunction with the above conditional tags to define a block to evaluate if the condition is not true.
<%= EVENT FIELD(name) %> Outputs the value of the 'name' field in the event currently defined in the $EVENT variable. For example, 'title', or any other field defined in the Customize Event Fields screen.
<%= SCHEDULE FIELD(type) %> Outputs a part of the schedule for the current occurrence of the current event held in $EVENT. The following values are available for the value of 'type':
  • start = gmtime() value of when the event occurrence starts.
  • end = gmtime() value of when the event ends
  • year = 4-digit year
  • month = The month number, from 1-12
  • date = The day of the month
  • day = The day number, from 0-6
  • datestring = The date in format yyyymmdd
  • start_ss = The seconds value of the start time, 0-59
  • start_mi = The minutes value of the start time, 0-59
  • start_hh = The hours value of the start time, 0-23
  • start_time = Formatted string of the start time, according to 12/24-hour format preference in config file
  • end_ss = The seconds value of the end time, 0-59
  • end_mi = The minutes value of the end time, 0-59
  • end_hh = The hours value of the end time, 0-23
  • all_day = 1 if this is an all day event, otherwise blank or 0
<% LAST YEAR LINK %> , <% NEXT YEAR LINK %> The URL to navigate to the previous or next year.
<% LAST MONTH LINK %> , <% NEXT MONTH LINK %> The URL to navigate to the previous or next month.
<% LAST WEEK LINK %> , <% NEXT WEEK LINK %> The URL to navigate to the previous or next week.
<% PREVIOUS DAY LINK %> , <% NEXT DAY LINK %> The URL to navigate to the previous or next day.


Template Variables

These are Perl variables available in your templates. You can use these inside of <% %> code blocks, or print their value using <%= $VARIABLE %>.

$Config A reference to a Config object for the calendar. You can retrieve values from the config file for this calendar by using the syntax $Config->get("aCODEribute_name").
$AdminConfig A reference to the Admin config file and functions the same way.
$Session A reference to a CGISession object, to retrieve or set values in the user's session. This will only apply if the user is logged in. It is most useful in the Admin templates.
$CGI_URL The URL of the calendar application, so you can link back to it or submit forms back to it.
$CGI_URL_QUERYSTRING The URL of the calendar application, but with all current display parameters aCODEached to the end of it. This should be used rather than $CGI_URL in most cases where you are making a link.
$QUERY_STRING The current display parameters in a URL-encoded query string.
$CGI_HIDDEN_FIELDS The current display parameters in HTML hidden fields. If you create a form that submits back to the CGI URL, include these hidden fields.
$ADMIN_CGI_URL The URL of the Calendar Admin application.
$User A reference to the User object of the user currently logged in. Fields in the user database can be accessed using $User->{fieldname}. You can also use $User->isCalendarAdmin(calendar_id) to determine if the user has any Admin permissions on the calendar with id "calendar_id".
$userMessage The text of any message that should be displayed for the user.
$YEAR_SELECT Contains the text of an HTML SELECT element containing a list of options for each year. If you have a form and want the user to select a year, simply output the value of this variable.
$MONTH_SELECT Contains the text of an HTML SELECT element containing a list of options for each month's full name. If you have a form and want the user to select a month, simply output the value of this variable.
$MONTH_ABBREVIATION_SELECT Contains the text of an HTML SELECT element containing a list of options for each month's abbreviation. If you have a form and want the user to select a month, simply output the value of this variable.
$DAY_NAMES A reference to an array of the names of days of the week. The name of the first day of the week would be $DAY_NAMES->[0].
$DAY_ABBREVIATIONS A reference to an array of the abbreviations of days of the week. The abbreviation of the first day of the week would be $DAY_ABBREVIATIONS->[0].
$MONTH_NAMES A reference to an array of the names of the months. The name of the first month would be $MONTH_NAMES->[0].
$MONTH_ABBREVIATIONS A reference to an array of the abbreviations of months. The abbreviation of the first month would be $MONTH_ABBREVIATIONS->[0].
$DAY_NAME_0 .. $DAY_NAME_6 Separate variables for the names of each day, 7 variables in all.
$DAY_ABBREVIATION_0 .. $DAY_ABBREVIATION_6 Separate variables for the abbreviations of each day, 7 variables in all.
$MONTH_NAME_0 .. $MONTH_NAME_11 Separate variables for the names of each month, 12 variables in all.
$MONTH_ABBREVIATION_0 .. $MONTH_ABBREVIATION_11 Separate variables for the abbreviations of each month, 12 variables in all.
$YEAR The 4-digit year of the currently displayed date.
$MONTH The month number of the currently displayed date.
$MONTH_NAME The month name of the currently displayed date.
$DATE The date of the currently displayed date.
$DATESTRING The yyyymmdd date string of the currently displayed date.
$LAST_YEAR The 4-digit year of the previous year from the one currently displayed.
$NEXT_YEAR The 4-digit year of the next year from the one currently displayed.
$LAST_MONTH_YEAR The 4-digit year of the previous month from the one currently displayed. If the current month is January, for example, this will be the previous year. Otherwise it will be the same year as the current.
$NEXT_MONTH_YEAR The 4-digit year of the next month from the one currently displayed. If the current month is December, for example, this will be the next year. Otherwise it will be the same year as the current.
$LAST_MONTH, $NEXT_MONTH The number of the previous month and next month from the one currently displayed.
$NEXT_MONTH_NAME, $LAST_MONTH_NAME The names of the previous month and next month from the one currently displayed.
$LAST_WEEK_YEAR, $LAST_WEEK_MONTH, $LAST_WEEK_DATE The year, month, and date of the week prior to the currently-displayed date.
$NEXT_WEEK_YEAR, $NEXT_WEEK_MONTH, $NEXT_WEEK_DATE The year, month, and date of the week after the currently-displayed date.
$PREVIOUS_DAY_YEAR, $PREVIOUS_DAY_MONTH, $PREVIOUS_DAY_DATE, $PREVIOUS_DAY_DATESTRING The year, month, date, and yyyymmdd date string of the date prior to the one currently displayed.
$NEXT_DAY_YEAR, $NEXT_DAY_MONTH, $NEXT_DAY_DATE, $NEXT_DAY_DATESTRING The year, month, date, and yyyymmdd date string of the date after the one currently displayed.
$TODAY_YEAR, $TODAY_MONTH, $TODAY_DATE, $TODAY_DATESTRING The year, month, date, and yyyymmdd date string of today's date, regardless of which date is currently being displayed.
$CALENDAR An object containing the properties of the currently-displayed calendar.
$RANGE_START A formatted date string (formatted according to config settings) representing the first date in the range currently being displayed.
$RANGE_START_YEAR, $RANGE_START_MONTH,
$RANGE_START_DATE
The year, month, and date of the first date in the range currently being displayed.
$RANGE_END A formatted date string (formatted according to config settings) representing the first date in the range currently being displayed.
$RANGE_END_YEAR, $RANGE_END_MONTH, $RANGE_END_DATE The year, month, and date of the last date in the range currently being displayed.
$EVENTS A reference to a list of $EVENT objects for every event displayed in the current view.
$GRID_ROW_COUNT, $GRID_COL_COUNT The number of rows and columns in the grid required to display all the dates in the current view.
$Grid
$Grid->{rowcount}
$Grid->{colcount}
$Grid->{grid}->[y]->[x]->{dd}
$Grid->{grid}->[y]->[x]->{mm}
$Grid->{grid}->[y]->[x]->{yyyy}
$Grid->{grid}->[y]->[x]->{d}
$Grid->{grid}->[y]->[x]->{yd}
$Grid->{grid}->[y]->[x]->{dayname}
$Grid->{grid}->[y]->[x]->
{dayabbreviation}

$Grid->{grid}->[y]->[x]->{monthname}
$Grid->{grid}->[y]->[x]->
{monthabbreviation}

$Grid->{grid}->[y]->[x]->{datestring}
$Grid->{grid}->[y]->[x]->{display}
$Grid->{grid}->[y]->[x]->{selected}
$Grid->{grid}->[y]->[x]->{events}
$Grid->{grid}->[y]->[x]->
{hours}->[hh]->{events}

$Grid is a reference to an object containing all the details of the grid required to display all the dates in the view. Each cell in the grid can be referenced by column and row, to retrieve the date details of that grid cell and the events that should be displayed in the cell.
$DAY Inside special tags that loop through days, the $DAY variable is set to the current day in the loop. Properties of $DAY are the same as those in each grid cell above. Special tags listed above also reference the current day held in the $DAY variable.


Retrieving Events

Each template is responsible for retrieving the events it wishes to display, if any. This is the job of the &getEvents() and &getEvent() subroutines.

The &getEvents() subroutine takes arguments which define which range of events to retrieve, then gets the events and schedules from the database and populates most of the variables and special tags listed above. The arguments are given in the form on a hash table of values. For example,
&getEvents( {range=>'month'} );
This will retrieve all events and their schedules for the current-displayed month.

The list of possible arguments to the function are as follows:
  • startdate : A date in the yyyymmdd format which will be the starting point of the date display range.
  • enddate : A date in the yyyymmdd format which will be the ending point of the date display range.
  • range : One of their 'month' (default), 'week', 'twoweek', 'threeweek', 'fourweek', 'year' or 'day'.
  • duration : A number, followed by either 'h' or 'd' or 'w'. This specifies the number of hours, days, or weeks to span from the beginning date. For example, '3d' would retrieve events for the next 3 days.
  • year : The year of the begin date
  • month : The month of the begin date
  • date : The date of the begin date
  • start : The string 'today' or a Perl gmtime() value to use as the start date of the display range.
  • end : A Perl gmtime() value to use as the end date of the display range.
The logic to determine the actual begin date and end date of the range to show is:
  • Start Date
    • If a value for 'start' is passed, use it.
    • If a startdate is passed, use it.
    • Construct a startdate value from the year, month, and date values passed. If any of these fields are not passed, use the currently displayed date's value.
  • End Date
    • If a value for 'end' is passed, use it.
    • If an enddate is passed, use it.
    • If a duration is passed, add it to the start date and use that as the end date.
    • If any value is passed for 'range' calculate that range from the start date, and use it.
    • Default to a monthly display from the start date
So, to retrieve the current month's events, all you would even need to use is:
&getEvents({});
Since the range defaults to 'month' and the start date defaults to the currently displayed date.

The &getEvent() subroutine retrieves the details and schedule of a single event, and is passed the event ID.

Customizing Admin Templates

The entire Calendar Admin interface is template-driven also. However, the templates used in the Calendar Admin do not have special tags, and any special variables are not documented. The Admin templates are often somewhat complex and filled with Perl code, and should only be changed if you are very familiar with HTML and Perl.

Changing the Calendar Admin templates will allow you to dramatically change the look and feel of the Admin application, as well as customize its behavior and features. This is a task for advanced users only!

Language Translation

Language translation of the calendar display interface is taken care of by changing day names and month names in the Calendar Settings page of each calendar, as well as changing the text used in the display templates.

Translating the Calendar Admin application is a little more complex, although well supported and fairly straight-forward.

Under the calendarscript/templates/admin/ directory exists a different directory for every language currently supported by the Calendar Admin application. Currently, the only language supported is Enlish. However, you can easily translate to another language by copying this directory and renaming it to the language of your choice. Then go into all the template files of this new directory and translate the text in them. The final step is to translate the file called 'messages.txt' in the same directory. These are the messages that the Calendar Admin script itself generates in the case of warnings, errors, and other usre messages.

Once the translations are complete, log into the Calendar Admin application and navigate to the 'Admin Interface' screen. Here you will find the name of your new directory under the Language setting. Select your new language translation, save the changes, and your Calendar Admin interface will now be in your new language.
Home | Features | Demo | Pricing | Download | Documentation | Support
CalendarScript 3.21 ©Copyright 2003-2014