Part two in this three-part series deals with constructing conditional value lists that are to be used within a portal. In part one, the conditional value lists built were for use on a single record on a layout. Portals however may contain many rows, each row being a record with it's own field values.
When a portal is setup, you have the option to specify fields to go into the portal, and the option to attach one value list to each field. This means that the value list you assign must be setup in a way so that it's values can change per portal row as opposed to per record as illustrated in part one.
Here is the relationship graph of the example file. The two table occurrences in blue are those used in part one to build the conditional value lists.
In this example, the two table occurrences in purple will be used to construct the conditional value lists for use within a portal.
Looking at the graph, you will notice these purple table occurrences are related to a table occurrence that is one-step away from the base table occurrence (home). This table occurrence is that of a portal. So the first thing to note is that the table occurrences are related to the portals context, not that of the layout as shown by the blue table occurrences.
The notion of context is important when building value lists. In part one, our context was the layout (Home). Value lists were constructed related to the context.
In this example, the value lists context will be the portal, and so our relationships must be constructed related to the portal context. The reason why will be shown next. Also note that the conditions in the relationships are no different than used in part one - still relating from Sport Category to Sport Category to produce the Sport Name value list, and to produce the Sport Equipment value list - two conditions are used - Sport Category matching Sport Category, and Sport Name matching Sport name.
Here is the setup for the Sport Name value list for use in the portal. The field chosen is "Sport Name" from the first Purple table occurrence. The important thing to pay attention to here is the "show only related values from" option. This is equivalent to the context we want the value list to operate in. For this example, our context is that of the portal, and so I have chosen the portals table occurrence as the context.
By choosing the portal as the context, each row of the portal will build it's value list independent of other rows, and so each row will have it's own value list based on the values of the other fields in the row. So in the same way that the value lists in Part one of this article were built to change on a per record basis on the layout, this value list is built to change on a per portal row basis.
The portal above shows many records, each of which contains a sport category, name and equipment item. Value lists are attached to all three fields, and values were chosen on each row using the same set of 3 value lists.
The trick to having a conditional value list change per portal row, lies within the context you define when setting up the value list. The context (ie the source/left hand side of your relationship) is no longer the layout, but rather the portal. By changing the context to the portal, the value list is generated for each individual portal row so that each row can produce it's own value list contents.
Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.