Difference between revisions of "Child Objects"

From AgileApps Support Wiki
imported>Aeric
m (Text replace - 'Form Layout' to 'Form')
imported>Aeric
Β 
(41 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Designer > Data > Objects > {object} > Child Objects'''
'''[[File:GearIcon.png]] > Customization > Objects > {object} > Object Relationships > Child Objects'''


==About Child Objects==
[[File:Objectmodel.gif|right|thumb|Object Inheritance Model]]Object Inheritance provides the ability to build new (Child) objects that contain the attributes of an existing (Parent) [[Object]].
[[File:Objectmodel.gif|right|thumb|Object Inheritance Model]]Object Inheritance provides the ability to build new (Child) objects that contain the attributes of an existing (Parent) [[Object]].


Line 6: Line 7:


Using the parent/child object model provides the ability to infuse the fields and behaviors of one object to another, which saves time when building objects, and creates a robust data model. Β 
Using the parent/child object model provides the ability to infuse the fields and behaviors of one object to another, which saves time when building objects, and creates a robust data model. Β 
{{:Option:Object Inheritance}}


{{tenantfeatures|}}
===How Inheritance Works===
Β 
==How it Works==
The Parent-Child relationship is evident when considering the perspective of an object in the hierarchy, looking above or below. The following relationships describe the model shown at the top of this page:
The Parent-Child relationship is evident when considering the perspective of an object in the hierarchy, looking above or below. The following relationships describe the model shown at the top of this page:


Line 24: Line 24:
The Object Inheritance model can be carried further, expanding to include multiple categories and subcategories of ''People'', or any kind of object (places, things, etc.)
The Object Inheritance model can be carried further, expanding to include multiple categories and subcategories of ''People'', or any kind of object (places, things, etc.)


===Example to Create a Parent and Child Object===
===Example: Club Members===
Β 
To create an [[Object]] for members of a club or organization:
To create an [[Object]] for members of a club or organization:
#Create a ''People'' object, and include the following [[fields]]:
#Create a ''People'' object, and include the following [[fields]]:
#*Mr/Mrs/Ms
#*Mr/Mrs/Ms
Line 47: Line 45:
#Save changes when complete
#Save changes when complete


It's easy to understand how these child objects could evolve from a parent object. What's also interesting is that, in addition to inheriting fields, attributes from the parent are applied at the child level.
===When Should the Object Inheritance Model Be Used?===
Use Object Inheritance when:
*A parent object can be defined that contains fields common to a group of objects
*When any of the following elements are required in some objects but not in others:
:*[[Fields]]
:*[[Forms]]
:*[[Custom Form Actions]] *
:*[[Business Rules]]
:*[[Processes]]
:*[[Email Templates]]
:*[[Document Templates]] *
:*[[Indexes]]
:*[[Record Locators]]
:*[[Validations]]
:*[[Web Forms]] *


It's easy to understand how these child objects could evolve from a parent object. What's also interesting is that, in addition to inheriting fields, attributes from the parent are applied at the child level.
::'''*''' These items can be used in objects that are part of an object inheritance hierarchy, but their functionality is limited to the object where they originate. They must be created specifically for use in parent or child objects.


==Inheritance Guidelines==
==Inheritance Guidelines==
Line 56: Line 71:
:*A child object can have only one parent object
:*A child object can have only one parent object
:*An unlimited number of child objects can be associated with a parent object
:*An unlimited number of child objects can be associated with a parent object
*The Base Object (base class):
*The Base Object (base class):
:*is the top-most object in the hierarchy
:*is the top-most object in the hierarchy
:*is a parent object
:*is a parent object
:*has attributes and behaviors different from other parent objects
:*has attributes and behaviors different from other parent objects
*Any attributes in a parent object are common to all child objects (i.e., the child object inherits all the attributes of the parent object)
*Any attributes in a parent object are common to all child objects (i.e., the child object inherits all the attributes of the parent object)
:*All attributes present in the parent object ([[Forms]] / [[Workflows]] / [[Validations]] / [[Data Policies]]) are available in the child object
:*All attributes present in the parent object ([[Forms]] and [[Validations]] are available in the child object
Β 
*After a child object is associated with a parent object, the child object ''cannot be reassigned to a different parent object''
*After a child object is associated with a parent object, the child object ''cannot be reassigned to a different parent object''
*Visibility:
*Visibility:
:*When referring to a parent object, only attributes present in the parent are visible
:*When referring to a parent object, only attributes present in the parent are visible
:*Attributes present in the child object can only be seen when referring to the child object
:*Attributes present in the child object can only be seen when referring to the child object
*Add/Update/Delete operations on a child object will also result in corresponding operations in the parent object (cascading operations)
*Add/Update/Delete operations on a child object will also result in corresponding operations in the parent object (cascading operations)
*Unique Indexes can only be defined on the Base Object
Β 
*When running calendar policies at an object, all rows matching the criteria will be acted upon (whether they belong to the object on which the policy is defined or to the child objects)
*Unique Indexes can be defined only on the Base Object
Β 
*All parent level fields are available to be placed in a child object, but they will not appear in Fields tab in Customization (use the [[Elements Sidebar]] to select parent object fields in a child object's [[Form]])
*All parent level fields are available to be placed in a child object, but they will not appear in Fields tab in Customization (use the [[Elements Sidebar]] to select parent object fields in a child object's [[Form]])


Line 77: Line 98:
::*Search and retrieve actions on a child object can use criteria from fields in the parent or the child object
::*Search and retrieve actions on a child object can use criteria from fields in the parent or the child object
::*If a field in the parent object is not in the child object's Form, the search and retrieve action will fail
::*If a field in the parent object is not in the child object's Form, the search and retrieve action will fail
:;Delete:Learn more: [[Records]]
:;Delete:
::* When you delete a parent object, all child objects are deleted, as well. You cannot delete a parent object without also deleting its children.
::*Deleting a parent object permanently from the [[Recycle Bin]] also permanently deletes any child objects that reside in the Recycle Bin
::*Deleting a parent object permanently from the [[Recycle Bin]] also permanently deletes any child objects that reside in the Recycle Bin
::*If a parent object resides in the Recycle Bin, and an attempt is made to restore child object(s) also residing in the Recycle Bin, an error message is displayed (instead, restore the parent object first, then the child object)
::*If a parent object resides in the Recycle Bin, and an attempt is made to restore child object(s) also residing in the Recycle Bin, an error message is displayed (instead, restore the parent object first, then the child object)
Line 84: Line 106:
:;Reports:Learn more: [[Reports]]
:;Reports:Learn more: [[Reports]]
::*Reports defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
::*Reports defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
::*Learn more: [[About Views, Reports and Object Inheritance]]
::*Learn more: [[Views, Reports and Object Inheritance]]
:;Forms: Β 
:;Forms: Β 
::*Forms defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
::*Forms defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
:;Validations, Data Policies and Workflows: Β 
:;Validations: Β 
::*Entries defined for an object can refer to fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
::*Entries defined for an object can refer to fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
:;Import:Learn more: [[Data Import|Import Data]]
:;Import:Learn more: [[Data Import|Import Data]]
Line 95: Line 117:
::*An Export operation performed on a parent object will export all the ''records'' present for the object as well as any child objects in the inheritance chain (following the path down to the bottom [leaf] level)
::*An Export operation performed on a parent object will export all the ''records'' present for the object as well as any child objects in the inheritance chain (following the path down to the bottom [leaf] level)
::*However, it will only retrieve the ''fields'' that correspond to the exported object and fields from all parent object(s) in the hierarchy (following the path up to the root level)
::*However, it will only retrieve the ''fields'' that correspond to the exported object and fields from all parent object(s) in the hierarchy (following the path up to the root level)
:;Mass Operations and More Actions:Learn more: [[Mass Operations]], [[More Actions]]
:;Mass Operations:Learn more: [[Mass Operations]]
:::*Mass Operations defined for an object can include fields of that object as well as fields fromΒ  all parent object(s) in the hierarchy (following the path up to the root level)
::*Mass Operations defined for an object can include fields of that object as well as fields fromΒ  all parent object(s) in the hierarchy (following the path up to the root level)
Β 
===Not Supported===
The following platform elements can be used in objects that are part of an object inheritance hierarchy, however their functionality is limited to the object where they originate. These elements must be created specifically for use in parent or child object(s):


*Print Templates
==Views, Reports and Object Inheritance==
*Actions
{{:Views, Reports and Object Inheritance}}
*Web Forms


==For Developers==
==For Developers==
The platform uses the concept of a single Table per Class Hierarchy for storing records in an inheritance chain. This strategy means that all the class hierarchy is stored in a single table in the database. Β 
When one object inherits from another, there are two virtual objects, but only one physical object. Β 
;Considerations:
*For each [[Object]] there is an associated [[Object Type Identifier]] (<tt>object_id</tt>)
::*At the [[Record]] level there is an associated [[Record Identifier]] (<tt>record_id</tt>)


*For objects not part of an inheritance relationship, the <tt>object_id</tt> value on <tt>requestParams</tt> and the <tt>record_id</tt> are the same
If object B is a child of object A, then:
*In the case of inherited objects, it is important to look at the <tt>object_id</tt> field value at the record level:
:* For a record added to object A, the <tt>object_id</tt> value is A's object identifier.
::*If the record was added to the base/parent object, the <tt>object_id</tt> in the record will specify the ID of the base/parent object Β 
:* For a record added to object B, the <tt>object_id</tt> value is B's object identifier.
::*If the record was added to the child object , then the <tt>object_id</tt> in the record will contain the ID of the child object.


===When Should the Object Inheritance Model Be Used?===
:;Considerations:
Use Object Inheritance when:
:*For each [[Object]] there is an associated [[Object Type Identifier]] (<tt>object_id</tt>)
*A parent object can be defined that contains fields common to a group of objects
:*That value is stored in the <tt>object_id</tt> field for each record.
*Child objects should be created when any of the following elements is required, and are not included in, or related to, the parent object:
::*At the [[Record]] level there is an associated [[Record Id]] (<tt>record_id</tt>)
:*[[Fields]]
:*[[Forms]]
:*[[Actions]]
:*[[Record Locators]]
:*[[Indexes]]
:*[[Validations]]
:*[[Data Policies]]
:*[[Assignment]]s (Prospect or Cases Objects only)
:*[[Print Templates]]
:*[[Web Forms]]
:*[[Workflows]]


==About Views, Reports and Object Inheritance==
<noinclude>
{{:About Views, Reports and Object Inheritance}}


[[Category:Objects| 0.5]]
[[Category:Object Aspects]]
<noinclude>[[Category:{{features}}]]</noinclude>
</noinclude>

Latest revision as of 20:14, 30 March 2015

GearIcon.png > Customization > Objects > {object} > Object Relationships > Child Objects

About Child Objects

Object Inheritance Model

Object Inheritance provides the ability to build new (Child) objects that contain the attributes of an existing (Parent) Object.

When a child object inherits the fields and behaviors of a parent object, common properties (defined once in the Parent Object) are applied uniformly to the child object. Each child object gains the base attributes of the parent, while contributing additional, unique attributes into a powerful module.

Using the parent/child object model provides the ability to infuse the fields and behaviors of one object to another, which saves time when building objects, and creates a robust data model.

Lock-tiny.gif

How Inheritance Works

The Parent-Child relationship is evident when considering the perspective of an object in the hierarchy, looking above or below. The following relationships describe the model shown at the top of this page:

  • Parent objects are located above an object
People object is a parent of Employees, Members, etc.
  • Child objects are located below an object
Employees object is the child of the People object, and a parent of the Active employees object
Customers object is the child of the People object
  • Naming conventions:
  • There is one base object, which is located at the top of the hierarchy
  • The leaf objects are located at the bottom of the hierarchy
  • Objects in the middle can be parents or children, depending on the path (going up or down)

The Object Inheritance model can be carried further, expanding to include multiple categories and subcategories of People, or any kind of object (places, things, etc.)

Example: Club Members

To create an Object for members of a club or organization:

  1. Create a People object, and include the following fields:
    • Mr/Mrs/Ms
    • First Name
    • Middle Initial
    • Last Name
    • Primary Email Address
    • Primary Telephone Number
    • Primary Address, City, State, Zipcode
  2. Create a Members object
    • Select People as the Parent Object
    • Click the [Next] button and add the following fields:
    • Membership Number
    • Member since (date)
    • Annual Fee Amount ($)
    • Annual Fee Paid (Y/N)
    • From the Elements Sidebar, click the Pick Existing tab to display the fields from the People object; Click and drag these fields from the People object into the Members object Form
  3. Optionally, build out the Member child object with additional elements; Learn more: Customize Objects
  4. Save changes when complete

It's easy to understand how these child objects could evolve from a parent object. What's also interesting is that, in addition to inheriting fields, attributes from the parent are applied at the child level.

When Should the Object Inheritance Model Be Used?

Use Object Inheritance when:

  • A parent object can be defined that contains fields common to a group of objects
  • When any of the following elements are required in some objects but not in others:
* These items can be used in objects that are part of an object inheritance hierarchy, but their functionality is limited to the object where they originate. They must be created specifically for use in parent or child objects.

Inheritance Guidelines

  • Single inheritance is supported:
  • A parent object can have multiple child objects
  • A child object can have only one parent object
  • An unlimited number of child objects can be associated with a parent object
  • The Base Object (base class):
  • is the top-most object in the hierarchy
  • is a parent object
  • has attributes and behaviors different from other parent objects
  • Any attributes in a parent object are common to all child objects (i.e., the child object inherits all the attributes of the parent object)
  • All attributes present in the parent object (Forms and Validations are available in the child object
  • After a child object is associated with a parent object, the child object cannot be reassigned to a different parent object
  • Visibility:
  • When referring to a parent object, only attributes present in the parent are visible
  • Attributes present in the child object can only be seen when referring to the child object
  • Add/Update/Delete operations on a child object will also result in corresponding operations in the parent object (cascading operations)
  • Unique Indexes can be defined only on the Base Object
  • All parent level fields are available to be placed in a child object, but they will not appear in Fields tab in Customization (use the Elements Sidebar to select parent object fields in a child object's Form)

Supported Properties and Actions

Search
Learn more: Search
  • Search and retrieve actions on a parent object can only use criteria from fields in the parent object
  • Search and retrieve actions on a child object can use criteria from fields in the parent or the child object
  • If a field in the parent object is not in the child object's Form, the search and retrieve action will fail
Delete
  • When you delete a parent object, all child objects are deleted, as well. You cannot delete a parent object without also deleting its children.
  • Deleting a parent object permanently from the Recycle Bin also permanently deletes any child objects that reside in the Recycle Bin
  • If a parent object resides in the Recycle Bin, and an attempt is made to restore child object(s) also residing in the Recycle Bin, an error message is displayed (instead, restore the parent object first, then the child object)
Formula Fields
Learn more: Formula Fields
  • A formula defined on the parent object is calculated during a parent record operation as well as any child record operation
Reports
Learn more: Reports
  • Reports defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
  • Learn more: Views, Reports and Object Inheritance
Forms
  • Forms defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
Validations
  • Entries defined for an object can refer to fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)
Import
Learn more: Import Data
  • When importing data into an object, fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level) are available for mapping
  • Import uses the Indexes defined in the parent object for data imported to both parent and child objects
Export
Learn more: Export Data
  • An Export operation performed on a parent object will export all the records present for the object as well as any child objects in the inheritance chain (following the path down to the bottom [leaf] level)
  • However, it will only retrieve the fields that correspond to the exported object and fields from all parent object(s) in the hierarchy (following the path up to the root level)
Mass Operations
Learn more: Mass Operations
  • Mass Operations defined for an object can include fields of that object as well as fields from all parent object(s) in the hierarchy (following the path up to the root level)

Views, Reports and Object Inheritance

When creating Views or Reports in objects that are part of an Object Inheritance model, it is important to consider the following:

A Report or View that has no Filters will return all records from the designated object, including records from all parent object(s) in the hierarchy (following the path up to the root level).

To restrict the View or Report to only the desired objects, include the Object Name field in the Selected Fields list, and create a Filter on Object Name field to select only the objects of interest.

For Developers

When one object inherits from another, there are two virtual objects, but only one physical object.

If object B is a child of object A, then:

  • For a record added to object A, the object_id value is A's object identifier.
  • For a record added to object B, the object_id value is B's object identifier.
Considerations