|Bookshelf Home | Contents | Index | Search | PDF|
Configuration Guidelines > Naming Conventions > Naming Conventions >
Controls and List Columns
A control (except for a button, prompt, or system control) must correspond to a field on the business component on which the applet is based. The control's Name property should have the same value as the field's Name property.
Follow these guidelines when creating display names:
- Use the same display name for an underlying field in every applet in which it appears.
- Avoid using abbreviations when enough room is available for you to spell out the word. For example, when there is sufficient space, use Opportunity instead of Oppty.
- If you must abbreviate, use the same abbreviation throughout the application. For example, always use Account Num and do not switch between Account Num, Account No., and Account #.
- Initial-capitalize control and list column names, for example, Account Num rather than account num. This prevents unexpected sorting behavior in the Object List Editor.
Here are other naming considerations:
- When naming currency code and exchange date fields, call them Currency Code and Exchange Date if they are the only such fields in the business component. If there are multiple instances of similar fields, prefix each with the name of the corresponding Amount column—for example, Revenue Currency Code and Budget Currency Code. The reason for this is that they are referenced by other fields when you specify the Properties Currency Code field and Exchange Date field. Defining the fields this way makes the reference easier to understand.
- The field URL must be named URL and the class of the Business Component must be set to CSSBCBase for the hyperlinking functionality to work correctly.
- Never include a question mark at the end of a field name or user interface label.
- Use meaningful, descriptive object names (for example, Account Detail Applet With Agreement, instead of Account Detail Applet 2).
- Be careful about spelling, spacing, and capitalization when naming objects. Typically, logical names of objects in the repository use complete words, mixed casing, and spaces between words. However, physical database objects use abbreviations, uppercase, and underscores. For example, the Service Request business component is based on the S_SRV_REQ database table. Also, note the unusual capitalization of the word PickList as it is used throughout the standard repository.
- It is time-consuming to change an object's name after it has been referenced throughout the repository. If you need to change the name of an object that may have many references throughout the repository, use the Find in Repository feature (from the Tools menu in Siebel Tools) to find all of the references.
- Make sure read-only applets always have the string Read-Only immediately before the word Applet in their name—for example, ABC Account List Read-Only Applet instead of ABC Account List Applet - Read-Only.
- Make sure read-only views always have the string Read-Only immediately before the word View in their name—for example, ABC Account Common Profile Read- Only View instead of ABC Account Common Profile View - Read-Only.
- Give duplicate applets without drilldowns the same name as the original applet but with the words Without Navigation immediately preceding the word Applet (or Read-Only Applet)—for example, ABC Selective Account List Without Navigation Applet.
- Applets that are used specifically for Administration purposes (which are almost always list applets) should be named <entity> Administration Applet—for example, Master Forecast Administration Applet.
- Business components used to represent child entities should not have their parent entity in their name—for example, ABC Subsegment instead of ABC Account Subsegment. Similarly, the applets that are based on these child business components should only reflect the name of the business component itself—for example, ABC Subsegment List Applet instead of ABC Account Subsegment List Applet.
NOTE: The exception is when you need multiple variations of the same business component or applet. Typically, multiple variations are necessary if a particular entity is displayed as both a top-level applet and a child applet on other views, and the two applets are not the same. In such cases, put the name of the parent entity at the beginning of the child applet name. For example, the ABC Account Contact List Applet is a Contact List that is displayed as the child of an Account. It needs the word Account to distinguish itself from the standard ABC Contact List Applet, which is a different applet.
- Always name multi-value group applets <BusComp> Mvg Applet. (Note the case sensitivity of Mvg.)
- Always name Pick applets <BusComp> Pick Applet. Always name association applets <BusComp> Assoc Applet.
- Always name a profile applet <Entity> Profile Applet, instead of <Entity> Profile Form Applet.
- Always name a new PickList object ABC PickList <entity>. Note that if the entity name itself has a prefix, it does not need to be repeated. For example, a PickList based on the MS Subsegment business component would be ABC PickList Subsegment instead of MS PickList MS Subsegment.
- When creating a physical extension column:
- Use an _ID suffix for foreign key columns (varchar 15) and a _CD suffix for List of Values domain fields (varchar 30).
NOTE: Do not use these suffixes for fields that do not meet this criteria.
- Use a physical type of varchar 40 for phone number fields.
- Remember that an extension column on a base table is automatically given an X_ prefix, so it is not necessary to add an additional prefix (for example, X_ABC_) to distinguish the columns from a standard column.
- Limit column names to 18 characters, which is the Siebel standard. Using this standard allows the application to use the column names as the basis for related column names without ever approaching the database limit for column names.
- On MS SQL Server 7 or Oracle, always extend a base table in favor of using an _X extension table. Note that this was not feasible on MS SQL Server 6.5 (and previous versions) or Sybase SQL Server because page size and the number of columns per table were limited.
TIP: If you are in doubt about object names, use the existing objects in the standard Siebel repository as your guide. For example, when creating a new Association applet, you would notice the <BusComp> Assoc Applet naming convention. Examine the standard objects and conform to their established naming conventions.
|Bookshelf Home | Contents | Index | Search | PDF|
Published: 18 April 2003