This section discusses some standard procedures to be followed by the developers of the OfficeClip Developer API. Following these guidelines will enable a structured upgrade of OfficeClip code when new versions are released. Another goal is to create guidelines that will not limit the OfficeClip developers to enhance or complement any of the OfficeClip’s functionality.

Guidelines

1. All code customizations should be done at the custom directory under the OfficeClip root. This diretory should be specified in the web.config file of the OfficeClip installation (please see the description of the CustomXml key in the Customization manual). Developers may create their own directory for customization but it should be a subdirectory of the root web folder of OfficeClip.
   
   
2. OfficeClip API may change in the future or the current API may be deprecated. We anticipate some change in the developer code due to this. OfficeClip will provide documentation on the API’s that got added, deprecated or modified. Every attempt will be made to keep the API consistent.
   
   
3. If developers wants to make a small change on an OfficeClip file, they are advised to copy the complete file in the custom area and make changes to it.
   
   
4. Developer should not get around the OfficeClip licensing code. OfficeClip’s licensing code is a means for OfficeClip to realize revenues from its sales. The rights to change or bypass the license are not provided explicitly. Developer will not attempt to tamper the code associated with the license or bypass them.
   
   
5. OfficeClip brands its products in certain places (e.g. browser titlebar). These should not be removed or changed by the developer of the API. Any branding changes will require authorization from OfficeClip.
   
   
6. All read access to the database should be done with the API supplied by the OfficeClip. We anticipate that OfficeClip API is comprehensive enough to provide information regarding all the database objects. In exceptional cases developer may want to write their own embedded SQL or stored procedure. In those cases, the following guidelines should be followed:
   
   
   1. Let OfficeClip know about the requirement. If OfficeClip decides to add the API in a later version and it satisfied all the needs of the developer, the developer agrees to use that API instead of the custom written API designed by them.
      
      
   2. Developer should *not* write any information to any OfficeClip tables directly using custom queries. Doing so may destroy the database consistency beyond repair. If the developer have a need to write into OfficeClip table, they should follow the following guidelines:
      
      
      1. Whereever possible, OfficeClip API should be used to write into these tables in a consistent manner.
         
         
      2. Developers may create their own tables linked by a foreign key to an OfficeClip table to write their information.
         
         
      3. If the developer wishes to delete any record in their table that is linked with an OfficeClip table, it should be dealt with in the following way:
         
         
         • If the primary record from the OfficeClip table also needs to be deleted, it should be done by calling the appropriate api function from the OfficeClip namespace.
           
           
         • If reference integrity needs to be maintained between the primary and the foreign key, it is necessary to customize the OfficeClip screen and remove the entries related to the foreign key before removing the primary key.
           
           
      4. All developer stored procedure should be named with an “Int_” prefix(or any other prefix with an underscore). This is done to ensure that the developer’s stored procedure does not overwrite OfficeClip stored procedure and vice versa.