History: Object References
Preview of version: 7
When creating object, auto-increment ids are used internally by Tikiwiki. 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 th same value.
During profile installation, 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.
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.
dependencies need to be all in one YAML block.
By installing the MyConfigurationRepositoryProfile profile, the following profiles would be installed:
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, 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 Tikiwiki installation
- allows to create custom profile extensions on a personal host (see Custom Repository for how to create a custom repository)
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.
MyConfigurationRepositoryProfile
dependencies: # Could also be called dummy - $profiles.tikiwiki.org:BugTrackerProfile:bug_tracker - $profiles.tikiwiki.org:ClientManagementProfile:client_tracker - $profiles.tikiwiki.org:SampleDataProfile:sample_page
dependencies need to be all in one YAML block.
By installing the MyConfigurationRepositoryProfile profile, the following profiles would be installed:
- ))BugTrackerProfile((
- ))ClientManagementProfile((
- ))CategoryTreeProfile((
- ))SampleDataProfile((
- ))MyConfigurationRepositoryProfile((
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.
History
Current Profiles
Latest Changes
- test_profile_change
- test_new_personal_blog_and_profile
- test_new_personal_blog_and_profile_vlog_include
- Bootstrap Row and Col Plugin Aliases
- Profile_Test_all_Modules_Test_all_Modules_page
- Bug_Tracker_16
- Bug_Tracker_16
- Profile_Tracker_as_Calendar_page_09
- Tracker_as_Calendar_09
- TikiKart_Product_Include
- Shopping_Cart
- Scheduler_Presets_20
- test_new_personal_blog_and_profile_post3_include
- test_new_personal_blog_and_profile_post2_include
- test_new_personal_blog_and_profile_post1_include
- test_new_personal_blog_and_profile_about_include
- test_new_personal_blog_and_profile_social_include
- R_demo
- Voting_System
- Test_all_tracker_field_types_profile