Row 1

Testing Form Access

Row 2

When using Tabs, I will frequently create multiple views of the same underlying data. This seems to be a problem with GF/GV. This page demonstrates the problem using two views:

Issues --> Assigned Person
Person --> Issue Assigned to that person

The results of this test surprised me. The Issue --> Assigned person returned an INNER JOIN, while the Person --> Issue returned an OUTER JOIN. The difference is described in THIS ARTICLE. The question now arises, how do I construct my code to force what I want (INNER vs. OUTER) join?

Row 3

Select test:

Test Strategy

Create four test data sets (one form per data set) and four views, one for each data set.
Create four pages, one for each test scenario. Link all of these off the Navitation Testing Dashboard so that it will be easy to return to this dashboard and test another scenario.
Test each strategy and identify any issues that arise.

The Four Methods:

DIVI Tabs - this method demonstrates the baseline case
Accordions - Presents menu in a vertical view
jQuery Tabs -
WordPress Menu -

Test Results

Tabs

This is the best solution if I can resolve the already known problems.

Accordions

This approach is ugly as sin because it shows the new form entry at the bottom of each accordion. It just looks awful.

jQuery Tabs

This approach shows some promise, but will require lots of work on my part to get up to speed again. I got it to show the tabs and the forms, but it is not loading any data. The interesting part is that the Cities test case shows the same problem that I have seen in a number of DIVI tabs cases: it is showing up where it wasn't invited.

Menus

Using WordPress menus is not really an option because it makes it too hard and complicated to maintain them, and I am not at all sure it would work anyway.

General Problems With This Approach

Each form can return to only a single page or URL when it completes submitting a new form entry. To address this, all forms return to the dashboard on submission.