AgileApps Support Wiki Pre Release

Difference between revisions of "Object Varieties"

From AgileApps Support Wiki
imported>Alice
 
imported>Aeric
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
There are two kinds of objects:
There are two kinds of objects:
* [[Built-in Objects]] are pre-defined objects that come with the platform. For example: User, Team, Role.
* {{Type}}s are pre-defined objects that come with the platform. For example: User, Team, Role.
* [[CRM Objects]] are a special class of pre-defined objects that come with the CRM application. For example: Accounts, Contacts.
* {{Type|}}s are created when applications are developed or installed.  
* {{Type|}}s are created when applications are developed or installed.  


:''Note:''<br/>Most users will never be aware that there is a difference between those two kinds of objects. Even for developers, the distinction is often minor. In general, {{Type|}}s are more customizable. They allow subclassing, workflow processing, and provide a variety of other capabilities. [[Built-in Objects]] and [[CRM Objects]], on the other hand, often provide specific functionality that is available only in those objects.
:''Note:''<br/>Most users will never be aware that there is a difference between those two kinds of objects. Even for developers, the distinction is often minor. In general, {{Type|}}s are more customizable. They allow subclassing,and provide a variety of other capabilities. {{Type}}s, on the other hand, often provide specific functionality that is available only in those objects.


There are also two flavors:
There are also two flavors:
* The term ''object'' designates an entity that is built on a database table, with all of the features that the platform provides for manipulating them: Forms, Validations, Data Policies, Spreadsheet (grid) views, and more. Each table (object) has columns (fields), each row has cells, and each cell has exactly one value. That value may be an ID (foreign key) that lets you select records from a different table (connect to other objects via ''lookup'' fields). The field value may even be a comma-separated list. But when managing an object record, you are in effect dealing with a set of single values for a row in a spreadsheet.
* The term ''object'' designates an entity that is built on a database table, with all of the features that the platform provides for manipulating them: Forms, Validations, Spreadsheet (grid) views, and more. Each table (object) has columns (fields), each row has cells, and each cell has exactly one value. That value may be an ID (foreign key) that lets you select records from a different table (connect to other objects via ''lookup'' fields). The field value may even be a comma-separated list. But when managing an object record, you are in effect dealing with a set of single values for a row in a spreadsheet.
* A [[Composite Object]], on the other hand, is a combination of [[Related Objects]]--objects that are connected by lookup relationships. For example, a customer has many orders and a choice of mailing addresses, while every order has a mailing address chosen from the list.
* A [[Composite Object]], on the other hand, is a combination of [[Related Objects]]--objects that are connected by lookup relationships. For example, a customer has many orders and a choice of mailing addresses, while every order has a mailing address chosen from the list.


Depending on how you write your application, you can work with either simple objects or composite objects—-whichever makes the task easier.
Depending on how you write your application, you can work with either simple objects or composite objects—-whichever makes the task easier.

Latest revision as of 03:20, 12 January 2013

There are two kinds of objects:

  • System Objects are pre-defined objects that come with the platform. For example: User, Team, Role.
  • Custom Objects are created when applications are developed or installed.
Note:
Most users will never be aware that there is a difference between those two kinds of objects. Even for developers, the distinction is often minor. In general, Custom Objects are more customizable. They allow subclassing,and provide a variety of other capabilities. System Objects, on the other hand, often provide specific functionality that is available only in those objects.

There are also two flavors:

  • The term object designates an entity that is built on a database table, with all of the features that the platform provides for manipulating them: Forms, Validations, Spreadsheet (grid) views, and more. Each table (object) has columns (fields), each row has cells, and each cell has exactly one value. That value may be an ID (foreign key) that lets you select records from a different table (connect to other objects via lookup fields). The field value may even be a comma-separated list. But when managing an object record, you are in effect dealing with a set of single values for a row in a spreadsheet.
  • A Composite Object, on the other hand, is a combination of Related Objects--objects that are connected by lookup relationships. For example, a customer has many orders and a choice of mailing addresses, while every order has a mailing address chosen from the list.

Depending on how you write your application, you can work with either simple objects or composite objects—-whichever makes the task easier.