Table of Contents Table of Contents  >> Technical Reference Technical Reference  >> ASCII Front End
 
 

Previous Next ASCII Front End

Information in this help file pertains to: eventedit.dat

Using ASCII front end mode causes the software to ignore its own internal event database and read events directly from an ASCII file.

The options needed to initiate this feature are found in the event customization file under the [FRONTEND_MODE] section. These options are explained in detail below:


[FRONTEND_MODE]
OptionValuesComments
mode
(string)

proprietary
ascii

default: proprietary

To enable this feature set this item to 'ascii'. Any value other than 'ascii' (the default) disables this feature.

ownerid
(string)

frontend

default: frontend

Ignored unless mode is set to 'ascii'. A read only value reserved for future use. Do not change this value.

source
(string)

any filename

default: events.txt

Ignored unless mode is set to 'ascii'. The name of the file in the calendar's data folder from which to read events. This is not a path, just a filename. The file must exist in the calendar's data folder.

sorted
(bool)

true
false

default: false

Ignored unless mode is set to 'ascii'. If true the program stops reading the data file when the first event with a date and time after the end of the current date range is encountered. This greatly improves performance of the ASCII front end mode. The file must be sorted correctly by date and time. See note below about performance of this mode.

message
(string)

any string

default: Ascii front end mode is in effect. You may not add, edit or delete events.

A message to displayed in the main table footer warning users that this mode is in effect. Users may not add, edit or delete events under this mode.

Format of ASCII front end mode data file

The format of the ASCII front end data file is identical to the import file format except the first line of the file must contain the current version of the file and the number of events in the file. The first line should look something like this:

    version[delim]nrows
where:
    version     the current version of the file (4[delim]0[delim]2)
    nrows       the number of events in the file (excluding field header row)
    [delim]     the field delimiter (one of semi-colon, comma or tab) you choose for the file

For example, a file, delimited with semi-colon containing 10 events would have these first two lines:

    4;0;2;10
    "subject";"date"...

The second line of the file must contain field names as described in the import file format help page. Each remaining line in the file ('nrows' of them) must contain the actual event data. Include each event on one and only one line. Do not include blank lines. Do not include comment lines.

Field delimiter

You may use any one of three possible field delimiters to separate the fields of your data: a tab, a comma or a semi-colon. The delimiter for the entire file is determined by the delimiter found in the first line of the file as follows:

    If a tab is found anywhere in the first line then
        delimiter is a tab
    else if a semicolon is found anywhere in the line then
        delimiter is a semicolon
    else if a comma is found anywhere in the line then
        delimiter is a comma
    else
        delimiter is a tab

You need not specify a delimiter other than by delimiting the first line of the file.

Why would one use this feature

Many of our clients have other processes or programs on their website that generate scheduling information (for example a doctor's office may have an online billing, patient information and scheduling system). In some cases this other process displays the scheduling information poorly.

With this feature you may keep your existing scheduling system but use our software to display the results. You will need to modify the existing system to export its data into our format and place the file in the correct location on your server (in each calendar's data folder).

For example, one of our users modified an existing application so that each time an event was added, edited or deleted to that application a file called events.txt was written to ./data/calweb. Our program simply read the file and displayed its contents. In this way the display of the data is as fresh as the contents of the events.txt file (which were always current). Our software was acting as an ASCII front end to the existing application.

You must create a separate events.txt file for each calendar. The modifications mentioned above to the eventedit.dat file must be made in each calendar folder.

Performance

The ASCII file is read and parsed each time the calendar is displayed. For this reason this mode of operation is slower than the native proprietary mode. If there are more than three to four hundred events in the ascii file the performance of the program may be too slow to be effective. There are a number of things you may do to alleviate this problem:

Performance improvements
1.

Make sure only the events that need to be in the events.txt file are included. Remove any extraneous events.

2.

Make sure only the fields you need are included in the file. Do not include fields that are not needed.

3.

Sort the file by date and time. Format the file so that the first two columns are date and time. Set the 'sorted' value to true. These settings instruct the program to check the date and time against the currently displayed date range. If an event is encountered that is after the end of the date range the program stops reading the file. In general this will speed this ASCII front end mode up by a factor of 2.



Calendars for the Web - Server Help File
Copyright (c) 1999, 2025 by Great Hill Corporation
All Rights Reserved