|
|
|
Calendar Solution
Documentation
Section 7:
Developer Access (cont'd)
Section 7.2: Developer Access,
People.fp5
People.fp5 (a.k.a. People, People module, People file) -
The People file stores the names of calendar users, and
has no other significant data connection to the Calendar
module or to the Task module. Other information about users
(addresses, phone numbers, etc.) may be entered in the
People file, but neither the Calendar file nor the Task file
access any of it. The Calendar and Task modules only access
name information (First name & Last name) for each user
in the People module, and then only for the purpose of
building value lists.
Each record that is added to the People file creates a new
user in the Calendar module's event Assigned To dropdown
lists. Test this by adding a record in the People file (with
at least a first and last name); then navigate to the Month
view of the Calendar module, add a new event, and click on
the Assigned To dropdown. You will see that the newly added
user has been added to the User list in the Calendar.
Fields - All fields in People that allow user
interaction begin with 'pe.'
prefixes. All other fields in this file are developer
fields, which each begin with a 'z', and are therefore
sorted to the bottom of the field definitions list. A full
description of the purpose of every field in this file is
not provided in this manual. The developer should take the
time to look at the scripts, layouts and fields in all of
the files to which he has access, familiarizing himself with
the programming and determining the intent behind the
programming. Scripts are well commented, when needed, and
all programming is well-organized for the benefit of
developers who employ this solution.
Those fields which are integral to the solution, or whose
components or usage may be complex for the moderately
experienced developer, will be described in detail in this
manual. For more information on developer fields and naming
conventions, see the Preface
for Section 7.
Relationships - There are no relationships between
the Calendar file and the People file. The only purpose for
the People file, where the Calendar is concerned, is to
generate a value list of users for event creation in the
Calendar. This concept applies to the Task file as well. Its
only use for the People file is for value list generation.
Users' names do end up in events stored in the Task file;
those user names are chosen in the Calendar module when
creating events.
The Task file does not know that there are People records
with those user names attached to them. This means that when
an event is created, it belongs to the name of the person
for whom it was created, not to any particular record in
People. Therefore, when a People record is deleted, all of
the events tied to that user's name will remain. Similarly,
if a user's name is changed, all of the events that were
tied to their original name will remain unchanged.
For example, if a user named John Smythe is added to People,
and events are created for him, those events will maintain
the name John Smythe, even if the spelling of his last name
is changed to Smith in the People file. New events for John
Smith will display as such, and the older records stamped
John Smythe will remain as such. Additionally, if John
Smith/Smythe is completely deleted from the People file, his
events, under both of his surname spellings (Smith and
Smythe) will remain in the Task file, and will therefore
continue to display in the calendar.
Value Lists - The user value list available when
adding/editing events in the Calendar is named
people.f~zi.nameFirst.last.cc.
As its name indicates, this value list is built from the
field zu.nameFirstLast.cc
in People.fp5. Both developer access levels (Levels 3 &
4) allow defining value lists in the Calendar file, enabling
the developer to populate these lists from values in any
file desired. If you decide to replace the People file with
your own contact database, you may redefine this value list
to display data from a file of your choosing.
Navigation - The only other noteworthy connections
between the People file and the Calendar file are navigation
scripts. Clicking the People navigation button in the
Calendar button bar executes a script in the Calendar, which
in turn calls a script in the People file.
Because Standard Access (Level 3) does not allow access to
ScriptMaker in Calendar.fp5, navigating to your own
users/people database will require modifying the script
nav.pe.entry
in People. To do so, add to the
nav.pe.entry
script in People a subscript which calls a script in your
contact database. Employing this method dictates that the
People file will need to remain in your solution, as the
navigation script in People will be accessed every time the
People button is clicked in the Calendar. Full Developer
access (Level 4) negates the need for this workaround, since
that level grants access to ScriptMaker in Calendar.fp5.
To achieve return navigation to the Calendar from your own
contact file, import the script
navx.cal.curView[xsub
calendar] from the
People file into the file of your choosing.
|
|