Object Structure

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 and the Associations Recursive Data Source. We recommend you review these previous Help Resources before continuing with this topic - the "Associations Recursive" data source.

For example, perhaps you produce Documents - and you want to pick up some details about their Authors, no matter where they are in your system, the Associations Query data source type is going to help.

In this "real world" case, you would first have to locate all of your Documents and then open them to see if they have an Author recorded against them, then note down the details you are interested in.  You would make your life easier if you had a central library of reports - 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 Documents and store them where they need them - 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 report to the system where they want it - given it has been included in the model.  XPOR lets you build your system to suit your users!  So, on face value, the task of listing out the Authors details appears very complicated - but with XPOR and the Associations Query data source, this is a fairly simple request.

The XPOR Query Designer

The Associations Query Data Source works with a QUERY path, making use of the system architecture to find the Document -> Author similar to the simple Association Data Source type.  However, this data source will look from your selected Parent Object, through its children (recursivley!) until it finds a Document Object - it will then follow the Author path (if there is one) to find the required details.  It will also continue to follow any other parent / child associations to seek out more matching cases.

So we need to describe a QUERY path to this Association Type.  This process is explained in a separate Help Resource.  In our example the Query is "Document" -"author association" -> "Contact", screenshot below;

The Data Source configuration

The Data Source is now configured to use this Query.  The attached Help video provides a step by step guide to achieve this.  The completed Data source is shown below;

Consequently, wherever you start from in your system (the Parent Object configured on your web page's Grid Form) the Query will work through the system, following the Parent Child association type, to find all matching "Document" -"author association" -> "Contact" combinations.

Let's look at our example model from first principles;

In this case we are looking for the "Document" object, which is under a "Product" object - perhaps a User Manual, or Product Data Sheet, Installation Instructions etc.

We can return this information using an Associations Query Data Source.   But this simple case doesn't really do the Associations Query Data Source justice.  So we'll make it a little more complicated;

This is a more realistic case, where the Documents will be in different locations throughout your XPOR system architecture.  In which case we want our Data source to provide access to the items marked in Red, below;

Using an Associations Query Data Source we can easily return all Contacts that are associated to a Document by type "Author" in this structure.  Having set up the Query and then the Data Source, we then create a new Grid Form - bound to this new Data Source.  A separate Help Resource is provided to explain how to set up a Grid Form, bound to a Data Source for this purpose. When the Grid Form is added to a web page XPOR enables the administrator to pick a Parent Object from the system.  In the example above we would select a Project object, to search the objects listed beneath the selected Project.

The Data source will start at the selected Project object and will follow "Children" path to look for "Report" -> "CD" by association type "child".  This will return all of the cases marked in Red above.

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 Reports and child CDs.

Our Associations recursive data source, when configured on the web page form to start from the "Site" object, will find all of the "Report" -> "CD" by type "Child", as marked in Red below.  Consequently we will see all of the CDs 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 who are authors of Documents in our system -  anywhere underneath the Site object.

Maximum Depth

The Associations Recursive data source will start 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.