< prev
main
next >

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.

< prev
main
next >

AppleScript - Links
Copyright 1998-2003 davedowling.com, All Rights Reserved.