Conditional Value Lists Pt 2 - Building for Use in Portals

By Daniel Wood, 15 December 2010

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.

conditionalvl 2 1

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.

conditionalvl 2 2

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.

conditionalvl 2 3

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.

Final Thoughts:

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.

Example File:

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.

Download Example File

Something to say? Post a comment...

Comments

  • Oxford 31/01/2013 5:47am (12 years ago)

    Hi Daniel.. The example worked perfectly for my scenario. I have Academic Years with Sessions and then Classes instead of the categories, names, and equipment. I noticed however that now each individual line item in my portal is considered a separate registration event. In my home table, which I call Registrations, I have a serial number field. This field is located above the portal on my Registration Layout. It was my hope that each registration could have separate line items from the year, sessions, and classes drop down menus.... but instead, each additional line item is considered another registration. You don't actually notice this until you check the number of registrations and instead of there being only one registration with 4 classes there are four separate registrations but each one has the portal with all four classes in it.

    I considered changing the 2nd table occurrence of my Registration table[Home] to a new table called Reg. Data that included the same fields... but I don't think this will work....

    Should I create a different way of numbering each individual registration record?

  • Oxford 31/01/2013 5:08am (12 years ago)

    No questions yet and it worked like a charm. I've been struggling with this setup for two weeks now. Your example and discussion is the best on the web. Woooohoooo!

  • Oxford 30/01/2013 4:26pm (12 years ago)

    I will probably have a million questions in the morning... but thank you, thank you, thank you a million times for this example file and description...

RSS feed for comments on this page | RSS feed for all comments

Categories(show all)

Subscribe

Tags