7 Commandments of Infinity Development

The window pane diagram displays the 7 commandments for Infinity software development. Roll over each image to view a quick description of each commandment. Click on each pane to navigate to the associated article.

Do Not Reuse GUIDs There are times when the XML that constitutes an Infinity table or an Infinity feature (such as data forms, data lists, search lists, and record operations) will need to be copied to create a new feature. When this occurs it is imperative that the software developer does NOT reuse the global unique identifier (GUID) for the root elements ID attribute of the spec. This rule also applies to the DataFormlnstancelD attribute of data form specs. Search Before Build. Before you begin to author a feature, search the feature metadata to see if the feature already exists within the Infinity catalog system You may be pleasantly surprised to find the feature already exists! Reference the DataForminstanceID. This commandment refers to data form specs. Whenever you refer to a data form within a task, page, or form field, refer to the feature by its DataFormInstanceID attribute and not its ID attribute.
Don’t Touch PD Tables or Specs. Custom specs that you create using Blackbaud’s Infinity SDK can be loaded multiple times. Developers can load a spec, change the XML of the spec, and reload in order to update the version that currently exists in the database. However, a software developer may not modify and reload specs created by Blackbaud Product Development since these specs define the features that ship with the product. Prefix Custom SQL Objects. For customizations, it is important that tables, stored procedures, user defined functions, and views start with “USR_’. Prefixing database objects with USR_ is a key to avoid potential naming collisions with future features delivered as part of the product. Unique Name on Spec. Most catalog tables contain a unique index on the Name column to enforce a unique name for the feature. Future product feature names could possibly conflict with your custom feature name. Therefore it is important that you provide a name that will not conflict with future features authored by Blackbaud. Blackbaud Professional Services typically adds the word “(custom)” to the end of each feature name This will allow for easy identification of whether the spec was written by Product Development or Professional Services, as well as guarantee a unique feature name.
  Use Package Spec Instead of Dependency Elements within Spec. Blackbaud recommends using the package spec to load specs together as a group instead of using dependency elements within the individual spec. Package specs control the order in which related specs are loaded.