Cy Think Content Management System

Programmer's Guide to Application-Layer Programs  

Nearly every program in the Cy Think CMS relates closely to a single database table. This creates an almost one-to-one relationship between programs and database tables.

Therefore, you probably need to create a dababase table, data-layer program and appropriate CMS parameters before you create an application-layer program. See this link.

Programmer's Procedure to Add a Database Table

This procedure is for adding a new application-layer program to the system. Therefore, this procedure is aimed at programmers. This is the procedure.

1. Decide on the name of the application tier module. This should normally be the table name followed by "s" and ".pl", all lower case. E.g. if the table is "abc" the module name will be abcs.pl. Note: A relationship table that has associated data will need an application tier module. But, a simple relationship table without associated data does not need an application tier module. For example, see business.pl and members.pl that share the bizus table. Look for gui_form_add_relation and gui_form_unlink.
2. Pick a model program from the available programs in the coreCMS directory.
   • For a very simple table, pick city.pl.
   • For a table with foreign keys, pick cszs.pl.
   • For a table that uses codes, pick styles.pl.
3. Open the model program, e.g. city.pl, and save it with the chosen application tier module name in the folder for the target development site.
4. Change the use directive at or near line 11, e.g. change use Jshcity to use Jshabc.
5. Change the value of $this_page at or near line 14.
6. If the program function is affected by parms values, be sure the context array is defined. For example, add "my @context_array = body_context_array();" near line 20.
7. Search through the file for '$sid("sel'. Change the name of the sid variable that holds the current instance of the item. E.g. change $sid{"selcity"} to $sid{"selabc"}. The first occurance is near line 70. This change will affect about 7 lines.
8. Change all the prefixes to match the table name. For example, if your model was city.pl, change city_ to abc_. This can be done with a global replace in the module. There will be 80-120 of these.
9. Locate the list_rows routine near the end of the file and decide the display order of the fields. Decide on a systematic plan for re-ordering and making the global changes needed to the field names.
10. If you are using enumerated values stored in the code table, search the file for "code_select_array" and make the appropriate modifications. Add or delete as needed to match the requirements of the new table. Change the default value. These changes are in the new_row_form and edit_form functions.
11. Change the display headings for the table and labels for the fields. Search the file for each label and make the appropriate changes. Avoid using global change to do this step.
12. Starting with the view_row sub, review the names of the calls that retrieve data from the table. Rename these calls, renaming them in the edit_form sub and list_row sub at the same time. Order the calls to match the table, if needed. Add calls for any new fields.
13. Using the view_row sub as your guide, change the field labels, as needed.
14. Using the new_row_form sub as your guide, check the code that displays the fields to the user. Make changes, as needed, so the fields are displayed appropriately.
15. Do the same for the edit_form sub. Order the calls to match the table. Globally rename the labels and call appropriate subs that correspond to the type of data in each field. Duplicate or add widgets for any new fields.
16. Continue with the data layer calls that add and update rows. Be sure that the param names match the HTML tag names. Be sure the field names in the arrays are correct. These calls are in the add_row and update_row subs.
17. Review add_row for any needed changes.
18. Review edit_form for any needed changes.
19. Review update_row for any needed changes.
20. Review list_rows for any needed changes.
21. Prepare to test the module by creating the linkage between the module and the Action Menu. See this link for details.
    
    Programmer's Guide to CMS Action Menus
    
    
22. Use FTP to upload the new program and any other files that have changed.
23. Change the permissions on the new PERL file (.pl) to allow execution. (755)
24. Begin testing by viewing the add form. The corresponding sub is new_row_form.
25. Continue by actually adding a row. After adding a row, the edit row form is immediately displayed. If there are problems, use phpMyAdmin to see if a row was inserted.
26. List all rows. You should be able to list the row you just added.
27. Select the row and make a change to each field. Save and verify the changes took effect.
28. Add a second row, list all, select the row, then delete it. If successful, you have tested the four the major functions.
    
    
29. Write and test any code needed to implement any special functions.
30. Consider the application as a whole and think if any additional changes are needed. Make changes and fix the implementation as needed.
31. Consider the need for user documentation and prepare any documentation that is appropriate.

This procedure is abbreviated and high level. It is documented to prompt the programmer as to the needed steps and is not intended to be a detailed step-by-step procedures.