Data Sources are Object Modeller configured collections of data. This Help Resource discusses the Association Recursive type of Data Source, following on from the basic Associations type Data Source. We recommend that you familiarise yourself with the Associations type Data before reading this Help Resource.
The object structure of XPOR means we can access data and information by creating data sources that make use of this structure. In seperate Help Resources we have looked at the simple Objects by Type Data Source and the basic Associations Data Source. We recommend you review these previous Help Resources before continuing with this topic - the "Associations Recursive" data source.
Now we won't pull the wool over your eyes here - this is a concept that many people struggle to take on board but is well worth the effort to comprehend! Its uses are significant. For example, you might need to find all the Software that has been provided as a child object of a Technical Report, no matter where they are in your system.
In the "real world" you would first have to locate all of your documents and then open them to see if they have any associated software. You would make your life easier if you had a central library - one place to go to. But this doesn't happen because people who are generating documents are doing it for their own purposes - not the librarians. Hence they write their doument and store it where they need it - wherever that might be.
Of course, the object model we create for a system matches the real world. The author of a Document CAN add that document to the system wherever they want it - given it has been included in the model. This can seem very complicated - but the need to find all software CDs is a fairly simple request.
So, instead of looking for all Documents or all CDs (software) we are looking for all "Document" -> "CD" associated by type "Parent/child";
Let's look at a simple model;
In this case we are looking for the Documents under a "Product" object - perhaps the Manuals / Assembly Instructions / production Certificates etc. that have software CD's
We can return this information using an Associations Recursive Data Source. But this simple case doesn't really do the Data Source justice. So we'll make it a little more complicated;
This is a more realistic case, where the Document objects will be in different locations in your system architecture. In which case we want our Data source to provide access to the items marked in Red, below;
Using an Associations Recursive Data Source we can easily return all CDs in this structure. We set the Source Object to be "Parent Object", so that we can subsequently configure the Grid to show the recursive data from beneath a target Project Object.
The Data Source will start at the selected Project object and will follow each path to look for "Document" -> "CD" by association type "Parent / child". This will return all of the cases marked in Red above.
The screenshot below shows the configuration of this Data Source.
Again this is a fairly simplistic view of the likely case we will be dealing with. In our experience we will have multiple projects under a Site, together with Other things associatied to the Site, that have their own Documents / software CD's.
Our Associations recursive data source, when configured on the web page form to start from the "Site" object, will find all of the "Document" -> "Contact" by type "Author", as marked in Red below. Consequently we will see all of the Contacts available from this Data Source.
Note that the associations recursive will find objects by the selected type (document). If an object type inherits "Document" it will also be returned by the query.
So, despite the complexity of our architecture, we will display a list of all contacts in our system who are associated to a document by type "Author" - anywhere underneath the Site object.
The Associations Recursive data source will stat at the parent object and traverse a "depth" to a maximum of 32 associations beneath the parent object. It won't look any further than this.