When creating object, auto-increment ids are used internally by Tiki. Object references allow to track these object IDs during the profile creation to create relationships between the different objects. For example, when a tracker is created, the trackerId provided to it is arbitrary. Unless you know what that ID is, it is impossible to add fields or items to it in an automated way. It could be possible to force the ID to a certain value, but this could cause conflicts if multiple profiles decided to use the same value.
During profile installation, the ref: attribute names an object. When a named object is encountered, the ID assigned to it is stored under the provided name. Other objects can access this value as a variable for any of their attributes.
The object block contains all objects to be created.
As you can see, the profile defined here will create three distinct categories. Profiles will be the parent category and contain two child categories. These child categories find their parent by using a reference ($profile_category). This internal reference uses the name defined by the ref attribute. For more information about the category object type, see Category Handler.
The following example does not work to categorize the item. It is a good example to show how a reference to another profile could be used but the wiki page handler (when last updated) still does not have categorization. To categorize objects, use the category handler.
References don't have to be in a logical place. Profiles are a big data structure. Each part may or may not be interpreted depending on what features are supported. To have profiles that call other profiles see Profile dependencies.
In larger portions of text, references can be be made using $profileobject:example.com:SampleProfile:object_name$. The same reduced patterns can be used.
This syntax is especially useful if a value in the object is fetched from a remote location using the wikicontent: handler. See Wiki Handler for an example.
During profile installation, the ref: attribute names an object. When a named object is encountered, the ID assigned to it is stored under the provided name. Other objects can access this value as a variable for any of their attributes.
The object block contains all objects to be created.
Category Tree Profile
YAML
objects: - type: category ref: profile_category data: name: Profiles - type: category ref: app_category data: name: Tracker Applications parent: $profile_category - type: category data: name: Site Samples parent: $profile_category
As you can see, the profile defined here will create three distinct categories. Profiles will be the parent category and contain two child categories. These child categories find their parent by using a reference ($profile_category). This internal reference uses the name defined by the ref attribute. For more information about the category object type, see Category Handler.
- Reference attributes (ref)
- are optional
- must be unique inside a profile
- can be useful to understand the ProfileHistory
- Internal references ($object_name)
- must refer to an existing object
- act as a variable
- must not cause circular dependencies between objects
- Inter-profile references ($ProfileName:object_name)
- must refer to an existing profile on the same site
- must not cause circular dependencies between profiles
- allow to refer to objects created by other profiles
- will cause the other profile to be installed
- Cross-site references ($example.com:ProfileName:object_name)
- must refer to a valid Tiki installation
- allows to create custom profile extensions on a personal host (see Custom Repository for how to create a custom repository)
The following example does not work to categorize the item. It is a good example to show how a reference to another profile could be used but the wiki page handler (when last updated) still does not have categorization. To categorize objects, use the category handler.
SampleDataProfile
objects: - type: wiki_page ref: sample_page data: name: Sample Profile category: $CategoryTreeProfile:app_category content: | ...
References don't have to be in a logical place. Profiles are a big data structure. Each part may or may not be interpreted depending on what features are supported. To have profiles that call other profiles see Profile dependencies.
Alternative Syntax
In larger portions of text, references can be be made using $profileobject:example.com:SampleProfile:object_name$. The same reduced patterns can be used.
This syntax is especially useful if a value in the object is fetched from a remote location using the wikicontent: handler. See Wiki Handler for an example.